Kubernetes In Action 有状态应用编排——Statefulset

本文整理自 CNCF X 阿里巴巴云原生技术公开课 & 《Kubernetes In Action》

回顾一下Deployment的功能

• 支持定义一组pod的期望数量，Controller会为我们维持Pod的数量在期望的版本以及期望的数量。
• 支持配置Pod的发布方式，配置完成后Controler会按照我们给出的策略来更新Pod。
• 支持一键回滚

Deployment 认为管理的所有相同版本的Pod都是一模一样的副本

但以上应付的是无状态的应用，但是面临以下有状态的场景：

• Pod之间并非相同副本，每一个pod都有独立标志
• 每个pod对应一个固定网络hostname，并且在发布升级后能够继续保持
• 每个pod有一个独立的存储盘，并且在发布升级后能够继续挂载原有盘
• 应用发布的时候能够按照固定顺序升级Pod

Statefulset 有状态应用控制器

1.每个Pod都有order序号，会按照order序号创建，删除，更新pod
2.通过配置headless service，使得每个pod有一个唯一的hostname
headless service （无clusterIP，每一个pod都有一个endpoint，都有一个对应的dns域名）
3.通过配置pvc模板，就是pvc template，使得每个pod有一块或者多块pv存储盘
4.支持一定数量灰度发布

如何提供稳定的网络标识?

有时候访问有状态的Pod需要通过主机名来定位，而无状态的Pod就不需要，因为每个无状态的Pod都是一样的，路由转发随便选一个就完事。

因此一个Statefulset要求创建一个用于记录每个Pod网络标记的headless Service

通过这个Service，每个pod将拥有独立的DNS记录，这样集群里它的伙伴或者客户端可以通过主机名方便找到他。

如何为每个有状态实例提供专属的稳定存储？

在StatefulSet中也需要创建持久卷声明模板，那么在Pod创建之前，先创建这些PVC，然后再绑定到一个Pod实例上

example

通过把Service的clusterIP设置为None,即Service为headless-service，可以使得StatefulSet里面的Pod都拥有独立的网络标识。

然后在StatefulSet的配置中要指定其对应哪一个Service

版本

Deployment使用ReplicaSet来管理和维持副本数量，而StatefulSet controller直接管理下属的Pod,而Pod用一个label来标识版本

Statefulset有什么

总结StatefulSet

支持每个Pod独享PVC，每一个Pod有一个独立的hostname，升级发布后还能复用PVC和网络标识

提供At most once语义，必须保证两个拥有相同标记和绑定相同PVC的pod不会同时运行

对比Replicaset

• Replicaset的每个Pod都会共享一个PVC，对应一个PV，没有办法使得其定义的所有副本都有一个单独的PVC
• 不能为每个Pod提供稳定的标志，例如某个pod删掉，重新再起一个pod，这个新的pod会有全新的主机名和IP
• Replicaset创建的pod都是随机生成的，即常见的podName+Hash，而Statefulset创建的pod都拥有规则的名称。

ref

https://gitbook.cn/gitchat/column/undefined/topic/5de26a4537796e6b106bef40