StatefulSets（有状态系统服务设计）在Kubernetes 1.7中还是beta特性，同时StatefulSets是1.4 版本中PetSets的替代品。PetSets的用户参考1.5 升级指南 。

使用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来提供稳定的存储。
  1. apiVersion: v1
  2. kind: Service
  3. metadata:
  4.   name: nginx
  5.   labels:
  6.     app: nginx
  7. spec:
  8.   ports:
  9.   - port: 80
  10.     name: web
  11.   clusterIP: None
  12.   selector:
  13.     app: nginx
  14. ---
  15. apiVersion: apps/v1beta1
  16. kind: StatefulSet
  17. metadata:
  18.   name: web
  19. spec:
  20.   serviceName: "nginx"
  21.   replicas: 3
  22.   template:
  23.     metadata:
  24.       labels:
  25.         app: nginx
  26.     spec:
  27.       terminationGracePeriodSeconds: 10
  28.       containers:
  29.       - name: nginx
  30.         image: gcr.io/google_containers/nginx-slim:0.8
  31.         ports:
  32.         - containerPort: 80
  33.           name: web
  34.         volumeMounts:
  35.         - name: www
  36.           mountPath: /usr/share/nginx/html
  37.   volumeClaimTemplates:
  38.   - metadata:
  39.       name: www
  40.     spec:
  41.       accessModes: [ "ReadWriteOnce" ]
  42.       storageClassName: my-storage-class
  43.       resources:
  44.         requests:
  45.           storage: 1Gi

部署和扩展

  • 对于具有N个副本的StatefulSet，当部署Pod时，将会顺序从{0..N-1}开始创建。
  • Pods被删除时，会从{N-1..0}的相反顺序终止。
  • 在将缩放操作应用于Pod之前，它的所有前辈必须运行和就绪。
  • 对Pod执行扩展操作时，前面的Pod必须都处于Running和Ready状态。
  • 在Pod终止之前，所有successors都须完全关闭。
    不要将StatefulSet的pod.Spec.TerminationGracePeriodSeconds值设置为0，这样设置不安全，建议不要这么使用。更多说明，请参考force deleting StatefulSet Pods.

在上面示例中，会按顺序部署三个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。

了解更多 StatefulSet: Kubernetes 中对有状态应用的运行和伸缩

K8S中文社区微信公众号

原文: http://docs.kubernetes.org.cn/443.html