31 K8S 之 StatefulSet 控制器

无状态应用进程客户端的每次连接均可独立地处理，一次请求和响应即构成一个完整的事务，它们不受已完成的连接或现有其他连接的影响，且意外中断或关闭时仅需要重新建立连接即可，因而，无状态应用的 Pod 对象可随时由其他由同一模板创建的 Pod 平滑替代，这也正是 Deployment 控制器编排应用的方式。

在云原生应用的体系里有两组常用的近义词：第一组是无状态（stateless）、牲畜（cattle）、无名（nameless）和可丢弃（disposable），它们都可用于表述无状态应用；另一组是有状态（stateful）、宠物（pet）、具名（having name）和不可丢弃（non-disposable），它们都可用于表示有状态应用。

Kubernetes 系统使用专用的 StatefulSet 控制器编排有状态应用。StatefulSet 表示一组具有唯一持久身份和稳定主机名的 Pod 对象，任何指定该类型 Pod 的状态信息和其他弹性数据都存放在与该 StatefulSet 相关联的永久性磁盘存储空间中。StatefulSet 旨在部署有状态应用和集群化应用，这些应用会将数据保存到永久性存储空间，它适合部署 Kafka、MySQL、Redis、ZooKeeper 以及其他需要唯一持久身份和稳定主机名的应用。

一个典型的、完整可用的 StatefulSet 资源通常由两个组件构成：Headless Service 和 StatefulSet 资源。Headless Service 用于为各 Pod 资源固定、唯一的标识符生成可解析的 DNS 资源记录，StatefulSet 用于编排 Pod 对象，并借助 volumeClaimTemplate 以静态或动态的 PV 供给方式为各 Pod 资源提供专有且固定的存储资源。

与 Deployment 略有不同的是，StatefulSet 对应用规模的扩容意味着按索引顺序增加更多的 Pod 资源，而缩容则表示按逆序依次删除索引号最大的 Pod 资源，直到规模数量满足目标设定值为止。需要特别说明的，多数有状态应用都不支持规模性安全、快速的缩减操作，因此 StatefulSet 控制器不支持并行缩容机制，而是要严格遵守一次仅能终止一个 Pod 资源的法则，以免导致数据讹误。这通常也意味着，存在错误且未恢复的 Pod 资源时，StatefulSet 资源会拒绝启动缩容操作。

StatefulSet 资源的滚动更新还支持分区（partition）机制，用户可基于某个用于分区的索引号对 Pod 资源进行分区，所有大于等于此索引号的 Pod 对象会被滚动更新，而小于此索引号的则不会被更新，而且，即便在此期间该范围内的某 Pod 对象被删除，它也一样会被基于旧版本的 Pod 模板重建。若给定的分区号大于副本数量，意味着不存在大于此分区号的 Pod 资源索引号，因此，所有的 Pod 对象均不会被更新，这对于期望暂存发布、金丝雀发布或分段发布来说是有用的设定。

Operator 就是一个开发规范和 SDK，它合理地利用 Kubernetes API 的 CRD 功能扩展出二级抽象，又巧妙地回归到 Kubernetes 的“控制器”逻辑，从而提供了一个有状态应用的实现接口，用户可利用它开发专用于管理某个特定有状态应用的运维控制器，并按需回馈给社区。