18 | 深入理解StatefulSet(一):拓扑状态
该思维导图由 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-135109 - along2018创建statefulset必须要先创建一个headless的service?分两步操作?
作者回复: 对的
2018-10-08663 - Dillion在上面的例子中,web-0、web-1启动后,此时如果web-0挂了,那在创建web-0的过程中,web-1也会被重新创建一次么???也就是如果一个StatefulSet中只有某个Pod挂了,在重启它的时候,如何确保文中说的Pod启动顺序呢??
作者回复: 任何一次pod的更新都会触发statefulset 滚动更新,更新一定会按编号顺序。但如果只是删除那就直接重建当前pod就够了,这并不破坏拓扑状态。当然,必要的时候,你的pod启动命令要能够区分第一次启动和重启,见下一节。
2018-10-03548 - 千寻说dns访问不到那个童鞋,不要用latest标签的busybox,用busybox:1.28.4这个tag的就可以了,我也是这样。
作者回复: 这咋还跟镜像有关系呢?
2018-10-09235 - 巩夫建Headless Service中不通过vip,外部访问的时候,是轮询还是随机还是热备的方式访问到web-0和web-1,dns解析好像没有轮询随机概念吧。
作者回复: 只能访问到固定的一个pod。所以说headless service不能替代normal service
2018-10-06829 - fldhmily63319我也想问, "Normal Service"和"Headless Service“的应用场景是什么? 根据文章所说的,”Headless Service不需要分配一个 VIP,而是可以直接以 DNS 记录的方式解析出被代理 Pod 的 IP 地址“,同时由于其编号的严格规定,会按照编号顺序完成创建工作。 这样是不是说,如果在部署StatefulSet的时候,大部分是推荐使用"Headless Service" ,而不是"Normal Service”呢?
作者回复: 是,必须用headless service
2018-10-03525 - jssfy通过这种方法,Kubernetes 就成功地将 Pod 的拓扑状态(比如:哪个节点先启动,哪个节点后启动),按照 Pod 的“名字 + 编号”的方式固定了下来。 如上所述, 1. 是否可以这样理解:sts在这里只是保留了“名字 + 编号”这种网络身份,而不同网络身份对应的pod其实本质上是一样的,都是同一个模板replicate出来的? 2. 这里sts的主要意义是什么呢:仅仅是保证不同网络身份的启动顺序?
作者回复: pod镜像是一样,但启动pod的命令和初始化流程可以完全不一样啊。可以参考后面的完整案例
2018-11-0415 - 刘欣洲访问不到啊 / # 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-04315 - Plantegg首先busybox镜像的/bin/ 下几百个可执行命令的md5签名都是一样的。不能按照正常的ping、nslookup逻辑来理解了。 也就是md5sum /bin/ping 和 md5sum /bin/nslookup 签名一样,我猜测这个可执行命令都是空架子,会被拦截下来。 另外就是1.28.4和1.29.3(latest) 的 nslookup 签名也不一样了
作者回复: busybox就是这么做出来的,正常
2018-10-1810 - IOVE.-Minn请教张大佬,当我跑jenkins in k8s的时候是用的statefulset部署的jenkins的master,我关联的service但是却不是无头服务啊, spec.ports 是用的nodeport 也没有用clusterIP:none这样。但是整个服务也是正常的。这不是和你讲的statefulset必须是关联headless service违背了么?
作者回复: 这说明你不需要通过带编号的dns名字访问这个节点呗,没啥奇怪的
2018-10-0928