深入剖析 Kubernetes
张磊
Kubernetes 社区资深成员与项目维护者
116705 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 57 讲
再谈开源与社区 (1讲)
结束语 (1讲)
深入剖析 Kubernetes
15
15
1.0x
00:00/00:00
登录|注册

18 | 深入理解StatefulSet(一):拓扑状态

严格按照Pod编号的顺序逐一完成操作
按照编号顺序逐一完成创建工作
使用Pod模板创建Pod时对它们进行编号
Kubernetes提供的支持
应用实例之间的拓扑关系
为每个Pod创建固定且稳定的DNS记录作为访问入口
调谐操作
控制器的作用
应用的“状态”
思考题
Headless Service
保证应用实例之间“拓扑状态”的稳定性
概念
StatefulSet
如何用StatefulSet保证应用实例之间“拓扑状态”的稳定性

该思维导图由 AI 生成,仅供参考

你好,我是张磊。今天我和你分享的主题是:深入理解 StatefulSet 之拓扑状态。
在上一篇文章中,我在结尾处讨论到了 Deployment 实际上并不足以覆盖所有的应用编排问题。
造成这个问题的根本原因,在于 Deployment 对应用做了一个简单化假设。
它认为,一个应用的所有 Pod,是完全一样的。所以,它们互相之间没有顺序,也无所谓运行在哪台宿主机上。需要的时候,Deployment 就可以通过 Pod 模板创建新的 Pod;不需要的时候,Deployment 就可以“杀掉”任意一个 Pod。
但是,在实际的场景中,并不是所有的应用都可以满足这样的要求。
尤其是分布式应用,它的多个实例之间,往往有依赖关系,比如:主从关系、主备关系。
还有就是数据存储类应用,它的多个实例,往往都会在本地磁盘上保存一份数据。而这些实例一旦被杀掉,即便重建出来,实例与数据之间的对应关系也已经丢失,从而导致应用失败。
所以,这种实例之间有不对等关系,以及实例对外部数据有依赖关系的应用,就被称为“有状态应用”(Stateful Application)。
容器技术诞生后,大家很快发现,它用来封装“无状态应用”(Stateless Application),尤其是 Web 服务,非常好用。但是,一旦你想要用容器运行“有状态应用”,其困难程度就会直线上升。而且,这个问题解决起来,单纯依靠容器技术本身已经无能为力,这也就导致了很长一段时间内,“有状态应用”几乎成了容器技术圈子的“忌讳”,大家一听到这个词,就纷纷摇头。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了如何使用StatefulSet来确保Kubernetes中有状态应用实例之间的拓扑状态稳定性。通过介绍StatefulSet的设计理念和核心功能,以及Headless Service的概念及其在StatefulSet中的应用,读者可以清晰地了解StatefulSet的工作原理和创建过程。作者通过实际的YAML文件和命令演示,详细解释了StatefulSet如何使用DNS记录来维持Pod的拓扑状态。文章强调了StatefulSet通过严格的对应规则,保证了Pod网络标识的稳定性,使得对于有状态应用实例的访问必须使用DNS记录或者hostname的方式,而绝不应该直接访问Pod的IP地址。总体而言,本文对于想要深入理解Kubernetes中有状态应用编排的读者具有很高的参考价值。文章还提出了思考题,引发读者对于有拓扑状态的应用实例之间的管理方式的思考。 在本文中,作者详细介绍了StatefulSet的工作原理和创建过程,以及其在维护有状态应用实例拓扑状态稳定性方面的重要作用。通过对StatefulSet的编号和控制循环的分析,读者可以清晰地理解其与Deployment的区别和改良之处。此外,文章还提到了Headless Service的方式,以及对于有状态应用实例网络标识的重要性。通过这些内容,读者可以深入了解Kubernetes中有状态应用编排的关键概念和实践方法。 总的来说,本文对于想要深入理解Kubernetes中有状态应用编排的读者具有很高的参考价值。通过对StatefulSet的详细介绍和实际操作演示,读者可以快速了解其在维护有状态应用实例拓扑状态稳定性方面的重要作用,以及与Deployment的区别和改良之处。同时,文章还提出了思考题,引发读者对于有拓扑状态的应用实例之间的管理方式的思考。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入剖析 Kubernetes》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(100)

  • 最新
  • 精选
  • 我来也
    今天按文章中的内容来, 确实也遇到了nslookup 反馈失败的状况. ** server can't find web-0.nginx: NXDOMAIN *** Can't find web-0.nginx: No answer 但是直接ping web-0.nginx 是可以获取真实ip地址的. 确实是如楼下的同学所说, 需要用 busybox:1.28.4 的镜像. 这个是最新版busybox的问题. kubectl run -i --tty --image busybox:1.28.4 dns-test --restart=Never --rm /bin/sh 这样就可获得期待的结果了. 我也是google到了 https://github.com/kubernetes/kubernetes/issues/66924 才知道的. 再看楼下的评论,才发现有其他同学也遇到了,且在几天前已经给出了解决方案. 👍 新技术确实变化太快了,作者在写文章时用的没问题,也许隔一天因为某个默认镜像修改了,就会出现新的状况.

    作者回复: 看来这个镜像确实有问题

    2018-10-13
    5
    109
  • along2018
    创建statefulset必须要先创建一个headless的service?分两步操作?

    作者回复: 对的

    2018-10-08
    6
    63
  • Dillion
    在上面的例子中,web-0、web-1启动后,此时如果web-0挂了,那在创建web-0的过程中,web-1也会被重新创建一次么???也就是如果一个StatefulSet中只有某个Pod挂了,在重启它的时候,如何确保文中说的Pod启动顺序呢??

    作者回复: 任何一次pod的更新都会触发statefulset 滚动更新,更新一定会按编号顺序。但如果只是删除那就直接重建当前pod就够了,这并不破坏拓扑状态。当然,必要的时候,你的pod启动命令要能够区分第一次启动和重启,见下一节。

    2018-10-03
    5
    48
  • 千寻
    说dns访问不到那个童鞋,不要用latest标签的busybox,用busybox:1.28.4这个tag的就可以了,我也是这样。

    作者回复: 这咋还跟镜像有关系呢?

    2018-10-09
    2
    35
  • 巩夫建
    Headless Service中不通过vip,外部访问的时候,是轮询还是随机还是热备的方式访问到web-0和web-1,dns解析好像没有轮询随机概念吧。

    作者回复: 只能访问到固定的一个pod。所以说headless service不能替代normal service

    2018-10-06
    8
    29
  • fldhmily63319
    我也想问, "Normal Service"和"Headless Service“的应用场景是什么? 根据文章所说的,”Headless Service不需要分配一个 VIP,而是可以直接以 DNS 记录的方式解析出被代理 Pod 的 IP 地址“,同时由于其编号的严格规定,会按照编号顺序完成创建工作。 这样是不是说,如果在部署StatefulSet的时候,大部分是推荐使用"Headless Service" ,而不是"Normal Service”呢?

    作者回复: 是,必须用headless service

    2018-10-03
    5
    25
  • jssfy
    通过这种方法,Kubernetes 就成功地将 Pod 的拓扑状态(比如:哪个节点先启动,哪个节点后启动),按照 Pod 的“名字 + 编号”的方式固定了下来。 如上所述, 1. 是否可以这样理解:sts在这里只是保留了“名字 + 编号”这种网络身份,而不同网络身份对应的pod其实本质上是一样的,都是同一个模板replicate出来的? 2. 这里sts的主要意义是什么呢:仅仅是保证不同网络身份的启动顺序?

    作者回复: pod镜像是一样,但启动pod的命令和初始化流程可以完全不一样啊。可以参考后面的完整案例

    2018-11-04
    15
  • 刘欣洲
    访问不到啊 / # nslookup web-0.nginx Server: 10.96.0.10 Address: 10.96.0.10:53 ** server can't find web-0.nginx: NXDOMAIN *** Can't find web-0.nginx: No answer 是不是需要DNS插件啊, 该如何启动呢?

    作者回复: dns是默认插件。你按我前面的部署流程、也就是官方的部署流程,是必然有dns的。看看pod列表debug一下吧。

    2018-10-04
    3
    15
  • Plantegg
    首先busybox镜像的/bin/ 下几百个可执行命令的md5签名都是一样的。不能按照正常的ping、nslookup逻辑来理解了。 也就是md5sum /bin/ping 和 md5sum /bin/nslookup 签名一样,我猜测这个可执行命令都是空架子,会被拦截下来。 另外就是1.28.4和1.29.3(latest) 的 nslookup 签名也不一样了

    作者回复: busybox就是这么做出来的,正常

    2018-10-18
    10
  • IOVE.-Minn
    请教张大佬,当我跑jenkins in k8s的时候是用的statefulset部署的jenkins的master,我关联的service但是却不是无头服务啊, spec.ports 是用的nodeport 也没有用clusterIP:none这样。但是整个服务也是正常的。这不是和你讲的statefulset必须是关联headless service违背了么?

    作者回复: 这说明你不需要通过带编号的dns名字访问这个节点呗,没啥奇怪的

    2018-10-09
    2
    8
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部