一、简介

实例之间的不等关系以及实例对外数据有依赖关系的应用，就被称为”有状态应用”。
所谓实例之间的不等关系即对分布式应用来说，各实例，各应用之间往往有比较大的依赖关系，比如某个应用必须先于其他应用启动，否则其他应用将不能启动等。
对外数据有依赖关系的应用，最显著的就是数据库应用，对于数据库应用，我们是需要持久化保存其数据的，如果是无状态应用，在数据库重启数据和应用就失去了联系，这显然是违背我们的初衷，不能投入生产的。

所以，为了解决Kubernetes中有状态应用的有效支持，Kubernetes使用StatefulSet来编排管理有状态应用。
StatefulSet类似于ReplicaSet，不同之处在于它可以控制Pod的启动顺序，它为每个Pod设置唯一的标识。其具有一下功能：

  • 稳定的，唯一的网络标识符
  • 稳定的，持久化存储
  • 有序的，优雅部署和缩放
  • 有序的，自动滚动更新

StatefulSet的设计很容易理解，它把现实世界抽象为以下两种情况：
（1）、拓扑状态。这就意味着应用之间是不对等关系，应用要按某种顺序启动，即使应用重启，也必须按其规定的顺序重启，并且重启后其网络标识必须和原来的一样，这样才能保证原访问者能通过同样的方法访问新的Pod；
（2）、存储状态 。这就意味着应用绑定了存储数据，不论什么时候，不论什么情况，对应用来说，只要存储里的数据没有变化，读取到的数据应该是同一份；

所以StatefulSet的核心功能就是以某种方式记录Pod的状态，然后在Pod被重新创建时，通过某种方法恢复其状态。

二、Headless Service

在介绍StatefulSet之前先了解一下什么是Headless Service。
我们知道，在Kubernetes中，Service是为一组Pod提供外部访问的一种方式。通常，我们使用 Service访问Pod有一下两种方式：
（1）、通过Cluster IP，这个Clustre IP就相当于VIP，我们访问这个IP，就会将请求转发到后端Pod上；
（2）、通过DNS方式，通过这种方式首先得确保Kubernetes集群中有DNS服务。这个时候我们只要访问”my-service.my-namespace.svc,cluster.local”，就可以访问到名为my-service的Service所代理的后端Pod；

而对于第二种方式，有下面两种处理方法：
（1）、Normal Service，即解析域名，得到的是Cluster IP，然后再按照方式一访问；
（2）、Headless Service，即解析域名，得到的是后端某个Pod的IP地址，这样就可以直接访问；

对于第二种处理方法我们可以看到这里并不需要Cluster IP，而是通过域名直接解析后端Pod的IP地址进行访问。
下面即为一个简单的Headless Service的YAML文件定义：

  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

通过上面的YAML文件可以看出和我们普通的Service定义没有太大的区别，唯一的不同就是clusterIP设置为None，也就是不需要cluster，我们通过kubectl apply -f创建这个Service，然后查看这个Service的Cluster IP为None。
image.png

这样创建的Service就是一个Headless Service，它没有VIP，所以会以DNS记录的方式暴露它所代理的Pod。

三、使用StatefulSet

在创建StatefulSet之前先创建PV，如下：

  1. apiVersion: v1
  2. kind: PersistentVolume
  3. metadata:
  4.   name: pv01
  5.   labels:
  6.     release: stable
  7. spec:
  8.   capacity:
  9.     storage: 1Gi
  10.   accessModes:
  11.   - ReadWriteOnce
  12.   persistentVolumeReclaimPolicy: Recycle
  13.   hostPath:
  14.     path: /tmp/data
  16. ---
  17. apiVersion: v1
  18. kind: PersistentVolume
  19. metadata:
  20.   name: pv02
  21.   labels:
  22.     release: stable
  23. spec:
  24.   capacity:
  25.     storage: 1Gi
  26.   accessModes:
  27.   - ReadWriteOnce
  28.   persistentVolumeReclaimPolicy: Recycle
  29.   hostPath:
  30.     path: /tmp/data

然后执行kubectl apply -f 启动PV，如下：

  1. [root@master statefulset]# kubectl apply -f pv.yaml 
  2. persistentvolume/pv01 created
  3. persistentvolume/pv02 created
  4. [root@master statefulset]# kubectl get pv
  5. NAME   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
  6. pv01   1Gi        RWO            Recycle          Available                                   10s
  7. pv02   1Gi        RWO            Recycle          Available                                   9s

可以看到两个PV的状态都为可用状态，然后编写StatefulSet的YAML文件：

  1. apiVersion: v1
  2. kind: Service
  3. metadata:
  4.   name: nginx
  5. spec:
  6.   ports:
  7.   - port: 80
  8.     name: web
  9.   clusterIP: None
  10.   selector:
  11.     app: nginx
  12.     role: stateful
  14. ---
  15. apiVersion: apps/v1
  16. kind: StatefulSet
  17. metadata:
  18.   name: web
  19. spec:
  20.   serviceName: "nginx"
  21.   replicas: 2
  22.   selector:
  23.     matchLabels:
  24.       app: nginx
  25.   template:
  26.     metadata:
  27.       labels:
  28.         app: nginx
  29.         role: stateful
  30.     spec:
  31.       containers:
  32.       - name: nginx
  33.         image: cnych/nginx-slim:0.8
  34.         ports:
  35.         - containerPort: 80
  36.           name: web
  37.         volumeMounts:
  38.         - name: www
  39.           mountPath: /usr/share/nginx/html
  40.   volumeClaimTemplates:
  41.   - metadata:
  42.       name: www
  43.     spec:
  44.       accessModes: [ "ReadWriteOnce" ]
  45.       resources:
  46.         requests:
  47.           storage: 1Gi

注意上面的 YAML 文件中和volumeMounts进行关联的是一个新的属性：volumeClaimTemplates，该属性会自动声明一个 pvc 对象和 pv 进行管理，而serviceName: “nginx”表示在执行控制循环的时候，用nginx这个Headless Service来保存Pod的可解析身份。

然后这里我们开启两个终端窗口。在第一个终端中，使用 kubectl get 来查看 StatefulSet 的 Pods 的创建情况。

  1. $ kubectl get pods -w -l role=stateful

在另一个终端中，使用 kubectl create 来创建定义在 statefulset-demo.yaml 中的 Headless Service 和 StatefulSet。

  1. $ kubectl create -f statefulset-demo.yaml
  2. service "nginx" created
  3. statefulset.apps "web" created

然后我们观察Pod的启动顺序：

  1. [root@master ~]# kubectl get pods -w -l role=stateful
  2. web-0   0/1   Pending   0     0s
  3. web-0   0/1   Pending   0     0s
  4. web-0   0/1   ContainerCreating   0     0s
  5. web-0   1/1   Running             0     3m12s
  6. web-1   0/1   Pending             0     0s
  7. web-1   0/1   Pending             0     0s
  8. web-1   0/1   Pending             0     1s
  9. web-1   0/1   ContainerCreating   0     1s
  10. web-1   1/1   Running             0     5s

通过 上面的创建过程，我们可以看出，StatefulSet给它所管理的Pod进行了编号，其命名规则为[statefulset-name]-[index]，其index从0开始，与StatefulSet的每个Pod实例一一对应，绝不重复。更重要的是其Pod的创建过程是顺序的，如上web-0进入running状态后web-1才进入pending状态。

我们通过命令来查看其创建结果：

  1. [root@master statefulset]# kubectl get statefulset web
  2. NAME   READY   AGE
  3. web    2/2     17m
  4. [root@master statefulset]# kubectl get pods -l role=stateful
  5. NAME    READY   STATUS    RESTARTS   AGE
  6. web-0   1/1     Running   0          17m
  7. web-1   1/1     Running   0          14m
  8. [root@master statefulset]# kubectl get svc nginx
  9. NAME    TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
  10. nginx   ClusterIP   None         <none>        80/TCP    17m

当两个Pod都进入running状态后，就可以查看其各自的网络身份了，我们通过kubectl exec来查看，如下：

  1. [root@master statefulset]# kubectl exec web-0 -- sh -c 'hostname'
  2. web-0
  3. [root@master statefulset]# kubectl exec web-1 -- sh -c 'hostname'
  4. web-1

可以看到这两个pod的hostname和pod的名字是一致的，都被分配为对应的编号，接下来我们用DNS的方式来访问Headless Service。
我们先用如下命令启动一个Pod：

  1. kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh

然后在这个Pod里用nslookup解析一个Pod对应的Headless Service:

  1. kubectl run -i --tty --image centos dns-test --restart=Never --rm /bin/sh
  2. sh-4.2# yum install bind-utils -y
  3. sh-4.2# nslookup web-0.nginx
  4. Server:        10.68.0.2
  5. Address:    10.68.0.2#53
  7. Name:    web-0.nginx.default.svc.cluster.local
  8. Address: 172.20.2.63
  10. sh-4.2# nslookup web-1.nginx
  11. Server:        10.68.0.2
  12. Address:    10.68.0.2#53
  14. Name:    web-1.nginx.default.svc.cluster.local
  15. Address: 172.20.2.64

从nslookup的结果分析，在访问web-0.nginx的时候解析的是web-0这个Pod的IP，另一个亦然。
这时候如果我们把两个Pod删掉，再观察其重启Pod的过程：

  1. [root@master statefulset]# kubectl delete pod -l role=stateful
  2. pod "web-0" deleted
  3. pod "web-1" deleted

然后查看其重启顺序如下：

  1. [root@master ~]# kubectl get pods -w -l role=stateful
  2. NAME    READY   STATUS    RESTARTS   AGE
  3. web-0   0/1     ContainerCreating   0          0s
  4. web-0   1/1     Running             0          2s
  5. web-1   0/1     Pending             0          0s
  6. web-1   0/1     Pending             0          0s
  7. web-1   0/1     ContainerCreating   0          0s
  8. web-1   1/1     Running             0          2s

我们可以看到，我们把Pod删除后，其重启顺序还是按原先的编号重启，并且其网络标识和原来依然一样。
通过这种严格的对应规则，StatefulSet就保证了Pod的网络标识的稳定性，通过这个方法，就可以把Pod的拓扑状态按照Pod的名字+编号的方式固定起来。此外，Kubernetes还为每一个Pod提供了一个固定并且唯一的访问入口，即这个Pod的DNS记录。

我们还可以查看一下PV和PVC的绑定情况：

  1. [root@master statefulset]# kubectl get pv
  2. NAME   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS   REASON   AGE
  3. pv01   1Gi        RWO            Recycle          Bound    default/www-web-0                           129m
  4. pv02   1Gi        RWO            Recycle          Bound    default/www-web-1                           129m
  5. [root@master statefulset]# kubectl get pvc
  6. NAME        STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
  7. www-web-0   Bound    pv01     1Gi        RWO                           124m
  8. www-web-1   Bound    pv02     1Gi        RWO                           116m

由此，我们对StatefulSet梳理如下：
（1）、StatefulSet直接管理的是Pod。这是因为StatefulSet里的Pod实例不像ReplicaSet中的Pod实例完全一样，它们是有细微的区别，比如每个Pod的名字、hostname等是不同的，而且StatefulSet区分这些实例的方式就是为Pod加上编号；
（2）、Kubernetes通过Headless Service为这个编号的Pod在DNS服务器中生成带同样编号的记录。只要StatefulSet能保证这个Pod的编号不变，那么Service中类似于web-0.nginx.default.svc.cluster.local这样的DNS记录就不会变，而这条记录所解析的Pod IP地址会随着Pod的重新创建自动更新；
（3）、StatefulSet还可以为每个Pod分配并创建一个和Pod同样编号的PVC。这样Kubernetes就可以通过Persitent Volume机制为这个PVC绑定对应的PV，从而保证每一个Pod都拥有独立的Volume。这种情况下即使Pod被删除，它所对应的PVC和PV依然会保留下来，所以当这个Pod被重新创建出来过后，Kubernetes会为它找到同样编号的PVC，挂载这个PVC对应的Volume，从而获取到以前Volume以前的数据；

四、总结

StatefulSet这个控制器的主要作用之一，就是使用Pod模板创建Pod的时候，对它们进行编号，并且按照编号顺序完成作业，当StatefulSet的控制循环发现Pod的实际状态和期望状态不一致的时候，也会按着顺序对Pod进行操作。

当然 StatefulSet 还拥有其他特性，在实际的项目中，我们还是很少回去直接通过 StatefulSet 来部署我们的有状态服务的，除非你自己能够完全能够 hold 住，对于一些特定的服务，我们可能会使用更加高级的 Operator 来部署，比如 etcd-operator、prometheus-operator 等等，这些应用都能够很好的来管理有状态的服务，而不是单纯的使用一个 StatefulSet 来部署一个 Pod就行，因为对于有状态的应用最重要的还是数据恢复、故障转移等等。