在K8s中，StatefulSets将Pod部署成有状态的应用程序。通过使用StatefulSets控制器，可以为Pod提供持久存储和持久的唯一性标识符。StatefulSets控制器与Deployment控制器不同的是，StatefulSets控制器为管理的Pod维护了一个有粘性的标识符。无论这些Pod如何被调度，每个Pod的标识符都是永久不变的。这一特点可以满足一些特殊场景的需要，例如：使用存储卷为为Kubernetes集群提供持久型存储时，可以使用StatefulSets控制器作为解决方案的一种。下表对比了无状态的控制器Deployment与有状态控的制器StatefulSets的主要异同。

视频讲解如下：

下面列举了一些StatefulSets的典型应用场景：

• 需要唯一的、稳定的网络标识符，即：Pod重新调度后其Pod名称和主机名不变。
  
• 需要持久的、稳定的持久化存储，即：Pod重新调度后还是能访问到相同的持久化数据。
  
• 需要优雅的、有序的部署应用和扩容缩容，即：Pod的部署和启动是顺序要求的，在部署或者扩展的时候要依据定义的顺序依次依次进行。
  
• 需要自动的、有序的滚动更新和回滚应用。
  

视频讲解如下：

一、【实战】StatefulSets控制器的创建

下面通过一个示例来说明如何创建StatefulSets控制器。

（1）创建“statefulsets-demo.yaml”文件，输入下面的内容：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  #StatefulSets控制器的名称
  name: statefulset-demo      
spec:
  selector:
    matchLabels:
      #通过标签与Pod关联
      app: nginx    
  #指定Service的名称
  serviceName: "nginx-service" 
  replicas: 4
  template:
    metadata:
      labels:
         #定义Pod的标签
        app: nginx  
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      #定义Pod里容器的名称
      - name: nginx   
        image: nginx:1.7.9
        ports:
        - containerPort: 80
          name: web

提示：参数“.spec.terminationGracePeriodSeconds”表示关闭或者删除Pod之前，需要等待的时间。对于StatefulSets控制器来说，不应将该参数设置为0。 这种做法是不安全的，应该强烈阻止。

（2）执行命令创建StatefulSets。

kubectl apply -f statefulsets-demo.yaml

（3）查看StatefulSets的信息，如下图所示。

kubectl get statefulset,pod -o wide

二、StatefulSets的扩容与缩容

由于StatefulSets中的所有Pod都具有唯一的网络标识符，因此在对StatefulSets进行扩容与缩容时，Kubernetes将严格按照下面的顺序进行：

• 当创建具有N个副本的StatefulSets，其中的每一个Pod将按照0...(N-1)的顺序依次创建。
  
• 当删除具有N个副本的StatefulSets，其中的每一个Pod将按照(N-1)...0的逆序依次终止。
  
• 当StatefulSets的扩容操作应用到某一个Pod时，Kubernetes将保证前面所有Pod的状态必须是Running或者Ready状态。
  
• 当StatefulSets的缩容操作应用到某一个Pod时，Kubernetes将保证前面所有Pod必须完全关闭的状态。

2.1  StatefulSets的扩容过程

以“statefulsets-demo.yaml”创建的StatefulSets为例。当“statefulset-demo”的控制器被创建后，StatefulSets控制器会按照pod/statefulset-demo-0、pod/statefulset-demo-1、pod/statefulset-demo-2和pod/statefulset-demo-3的顺序部署四个Pod。

当启动pod/statefulset-demo-1时，pod/statefulset-demo-0的状态一定是Running或者Ready。同理，在pod/statefulset-demo-1进入Running或者Ready状态前不会部署pod/statefulset-demo-2。如果pod/statefulset-demo-1已经处于Running或者Ready状态，而pod/statefulset-demo-2尚未部署，在此期间发生了pod/statefulset-demo-0运行失败，那么pod/statefulset-demo-2 将不会被部署，要等到pod/statefulset-demo-0部署完成并进入Running或者Ready状态后，才会部署pod/statefulset-demo-2。

2.2  StatefulSets的缩容过程

当用户进行缩容操作的时候，例如将参数“replicas”设置为1。首先被终止的是pod/statefulset-demo-3。在pod/statefulset-demo-3没有被完全停止和删除前，pod/statefulset-demo-2不会被终止。当pod/statefulset-demo-3已被终止和删除，但pod/statefulset-demo-2尚未被终止，如果在此期间发生pod/statefulset-demo-1运行失败， 那么就不会终止pod/statefulset-demo-2，必须等到pod/statefulset-demo-0进入Running或者Ready状态后才会终止 pod/statefulset-demo-2。

三、StatefulSets的更新与回滚

StatefulSet的更新与滚动是通过设置字段“.spec.updateStrategy”的方式来实现。通过该参数的设置允许开发人员配置和禁用掉自动滚动更新Pod的容器、标签、资源请求或限制、以及注解。该参数的取值有以下两个：

• RollingUpdate：这是默认的更新策略，该策略将对StatefulSets控制器管理的所有Pod执行自动的滚动更新。
  
• OnDelete：该策略将不会自动更新StatefulSets管理的所有Pod。要实现Pod的更新，必须手动删除旧的Pod以便让StatefulSets控制器创建新的Pod。该策略将按照与Pod终止相同的顺序进行更新，每次更新一个Pod。