Kubernetes StatefulSets
- 1 使用StatefulSets
- 2 限制
- 3 组件
- 4 部署和扩展
- 4.1 Pod管理
- 4.1.1 OrderedReady Pod Management
- 4.1.2 Parallel Pod Management
- 4.1 Pod管理
- 5 Update Strategies
- 5.1 删除
- 5.2 滚动更新
- 5.2.1 Partitions
StatefulSets(有状态系统服务设计)在Kubernetes 1.7中还是beta特性,同时StatefulSets是1.4 版本中PetSets的替代品。
使用StatefulSets
在具有以下特点时使用StatefulSets:
- 稳定性,唯一的网络标识符。
- 稳定性,持久化存储。
- 有序的部署和扩展。
- 有序的删除和终止。
- 有序的自动滚动更新。
Pod调度运行时,如果应用不需要任何稳定的标示、有序的部署、删除和扩展,则应该使用一组无状态副本的控制器来部署应用,例如 Deployment 或 ReplicaSet更适合无状态服务需求。
限制
- StatefulSet还是beta特性,在Kubernetes 1.5版本之前任何版本都不可以使用。
- 与所有alpha / beta 特性的资源一样,可以通过apiserver配置-runtime-config来禁用StatefulSet。
- Pod的存储,必须基于请求storage class的PersistentVolume Provisioner或由管理员预先配置来提供。
- 基于数据安全性设计,删除或缩放StatefulSet将不会删除与StatefulSet关联的Volume。
- StatefulSets需要Headless Service负责Pods的网络的一致性(必须创建此服务)。
组件
示例:
- name为nginx的Headless Service用于控制网络域。
- StatefulSet(name为web)有一个Spec,在一个Pod中启动具有3个副本的nginx容器。
- volumeClaimTemplates使用PersistentVolumes供应商的PersistentVolume来提供稳定的存储。
apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx --- apiVersion: apps/v1beta1 kind: StatefulSet metadata: name: web spec: serviceName: "nginx" replicas: 3 template: metadata: labels: app: nginx spec: terminationGracePeriodSeconds: 10 containers: - name: nginx image: gcr.io/google_containers/nginx-slim:0.8 ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www spec: accessModes: [ "ReadWriteOnce" ] storageClassName: my-storage-class resources: requests: storage: 1Gi
部署和扩展
- 对于具有N个副本的StatefulSet,当部署Pod时,将会顺序从{0..N-1}开始创建。
- Pods被删除时,会从{N-1..0}的相反顺序终止。
- 在将缩放操作应用于Pod之前,它的所有前辈必须运行和就绪。
- 对Pod执行扩展操作时,前面的Pod必须都处于Running和Ready状态。
- 在Pod终止之前,所有successors都须完全关闭。
不要将StatefulSet的pod.Spec.TerminationGracePeriodSeconds值设置为0,这样设置不安全,建议不要这么使用。
在上面示例中,会按顺序部署三个pod(name: web-0、web-1、web-2)。web-0在Running and Ready状态后开始部署web-1,web-1在Running and Ready状态后部署web-2,期间如果web-0运行失败,web-2是不会被运行,直到web-0重新运行,web-1、web-2才会按顺序进行运行。
如果用户通过StatefulSet来扩展修改部署pod副本数,比如修改replicas=1,那么web-2首先被终止。在web-2完全关闭和删除之前,web-1是不会被终止。如果在web-2被终止和完全关闭后,但web-1还没有被终止之前,此时web-0运行出错了,那么直到web-0再次变为Running and Ready状态之后,web-1才会被终止。
Pod管理
在Kubernetes 1.7及更高版本中,StatefulSet放宽了排序规则,同时通过.spec.podManagementPolicy字段保留其uniqueness和identity guarantees
OrderedReady Pod Management
OrderedReady Pod Management 是StatefulSets的默认行为。它实现了上述 “部署/扩展” 行为。
Parallel Pod Management
Parallel Pod Management告诉StatefulSet控制器同时启动或终止所有Pod。
Update Strategies
在Kubernetes 1.7及更高版本中,StatefulSet的.spec.updateStrategy字段允许配置和禁用StatefulSet中Pods的containers、labels、resource request/limits和annotations的滚动更新。
删除
当spec.updateStrategy未指定时的默认策略,OnDelete更新策略实现了传统(1.6和以前)的行为。当StatefulSet .spec.updateStrategy.type设置为OnDelete,StatefulSet控制器将不会自动更新StatefulSet中的Pod,用户必须手动删除Pods以使控制器创建新的Pod。
滚动更新
RollingUpdate更新策略实现了自动化,使StatefulSet中的Pod滚动更新。当StatefulSet .spec.updateStrategy.type设置为RollingUpdate,StatefulSet控制器将删除并重新创建StatefulSet中的每个Pod。它将以与Pod终止相同的顺序进行(从最大的序数到最小的顺序)来更新每个Pod。
Partitions
通过指定 .spec.updateStrategy.rollingUpdate.partition来分割RollingUpdate更新策略。如果指定了partition,则当更新StatefulSet时,将更新具有大于或等于partition的序数的所有Pods .spec.template,小于partition的序数的所有Pod将不会被更新。如果一个StatefulSet的.spec.updateStrategy.rollingUpdate.partition大于它.spec.replicas,它的更新.spec.template将不会被传Pods。在通常数情况下,不需要使用partition,但如果需要进行更新,推出金丝雀或执行分阶段推出,可以使用partition。