StatefulSet
StatefulSet 是为了解决有状态服务的问题(对应 Deployments 和 ReplicaSets 是为无状态服务而设计),其应用场景包括
稳定的持久化存储,即 Pod 重新调度后还是能访问到相同的持久化数据,基于 PVC 来实现
稳定的网络标志,即 Pod 重新调度后其 PodName 和 HostName 不变,基于 Headless Service(即没有 Cluster IP 的 Service)来实现
有序部署,有序扩展,即 Pod 是有顺序的,在部署或者扩展的时候要依据定义的顺序依次依序进行(即从 0 到 N-1,在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态),基于 init containers 来实现
有序收缩,有序删除(即从 N-1 到 0)
从上面的应用场景可以发现,StatefulSet 由以下几个部分组成:
用于定义网络标志(DNS domain)的 Headless Service
用于创建 PersistentVolumes 的 volumeClaimTemplates
定义具体应用的 StatefulSet
StatefulSet 中每个 Pod 的 DNS 格式为 statefulSetName-{0..N-1}.serviceName.namespace.svc.cluster.local,其中
serviceName为 Headless Service 的名字0..N-1为 Pod 所在的序号,从 0 开始到 N-1statefulSetName为 StatefulSet 的名字namespace为服务所在的 namespace,Headless Service 和 StatefulSet 必须在相同的 namespace.cluster.local为 Cluster Domain
API 版本对照表
v1.5-v1.6
extensions/v1beta1
v1.7-v1.15
apps/v1beta1
v1.8-v1.15
apps/v1beta2
v1.9+
apps/v1
简单示例
以一个简单的 nginx 服务 web.yaml 为例:
还可以进行其他的操作
更新 StatefulSet
v1.7 + 支持 StatefulSet 的自动更新,通过 spec.updateStrategy 设置更新策略。目前支持两种策略
OnDelete:当
.spec.template更新时,并不立即删除旧的 Pod,而是等待用户手动删除这些旧 Pod 后自动创建新 Pod。这是默认的更新策略,兼容 v1.6 版本的行为RollingUpdate:当
.spec.template更新时,自动删除旧的 Pod 并创建新 Pod 替换。在更新时,这些 Pod 是按逆序的方式进行,依次删除、创建并等待 Pod 变成 Ready 状态才进行下一个 Pod 的更新。
Partitions
RollingUpdate 还支持 Partitions,通过 .spec.updateStrategy.rollingUpdate.partition 来设置。当 partition 设置后,只有序号大于或等于 partition 的 Pod 会在 .spec.template 更新的时候滚动更新,而其余的 Pod 则保持不变(即便是删除后也是用以前的版本重新创建)。
Pod 管理策略
v1.7 + 可以通过 .spec.podManagementPolicy 设置 Pod 管理策略,支持两种方式
OrderedReady:默认的策略,按照 Pod 的次序依次创建每个 Pod 并等待 Ready 之后才创建后面的 Pod
Parallel:并行创建或删除 Pod(不等待前面的 Pod Ready 就开始创建所有的 Pod)
Parallel 示例
可以看到,所有 Pod 是并行创建的
zookeeper
另外一个更能说明 StatefulSet 强大功能的示例为 zookeeper.yaml。
详细的使用说明见 zookeeper stateful application。
StatefulSet 注意事项
推荐在 Kubernetes v1.9 或以后的版本中使用
所有 Pod 的 Volume 必须使用 PersistentVolume 或者是管理员事先创建好
为了保证数据安全,删除 StatefulSet 时不会删除 Volume
StatefulSet 需要一个 Headless Service 来定义 DNS domain,需要在 StatefulSet 之前创建好
最后更新于