StatefulSet

简介

实际场景中，尤其是分布式应用，多个实例之间，往往有依赖关系，比如：主从关系、主备关系。对于数据存储类应用，它的多个实例，往往都会在本地磁盘保存一份数据。导致这些实例一旦被杀掉，即便重建出来，实例与数据之间的对应关系也已经丢失，从而导致应用创建失败。

这种实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，称为“有状态应用”

StatefulSet将应用状态抽象成了两种情况：

拓扑状态。应用实例必须按照某种顺序启动。新创建的Pod必须和原来Pod的网络标识一样
存储状态。应用的多个实例分别绑定了不同存储数据。

Headless Service

Service是Kubernetes项目用来将一组Pod暴露给外界访问的一种机制。

Service被访问的方式：

Service的VIP（Virtual IP）
Service的DNS方式，只要访问“my-svc.my-namespace.svc.cluster.local”这条DNS记录，就可以访问到名为my-svc的Service所代理的某一个Pod

在第二种Service DNS的方式下，具体还可以分为两种处理方法：

第一种处理方法，是Normal Service。这种情况下，访问“my-svc.my-namespace.svc.cluster.local”解析到的，正是my-svc这个Service 的VIP，后面的流程和VIP一致

第二种处理方法，是Headless Service。这种情况下，访问“my-svc.my-namespace.svc.cluster.local”解析到的，直接就是my-svc代理的某一个Pod的IP地址。这里的区别在于，Headless Service不需要分配一个VIP，而是直接以DNS记录的方式解析出被代理Pod的IP地址。

Headless Service的作用

所谓的Headless Service仍是一个标准的Service的YAML文件，只不过spec.clusterIP的值为None，即这个Service没有一个VIP做为头。这个Service被创建后并不会分配一个VIP，而是以DNS记录的方式暴露它所代理的Pod

当按照这样的方式创建了一个Headless Service后，它所代理的所有Pod的IP地址，都会被绑定一个如下格式的DNS记录，如下：

...svc.cluster.local

这条DNS记录，是Kubernetes为Pod分配的唯一“可解析身份”

StatefulSet如何通过Headless Service维持Pod的拓扑状态

apiVersion: v1
kind: Service
metadata:
 name: nginx
 labels:
  app: nginx
spec:
 ports:
 - port: 80
   name: web
 clusterIP: None
 selector:
  app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: web
spec:
 serviceName: "nginx"
 replicas: 2
 selector:
  matchLabels:
   app: nginx
 template:
  metadata:
   labels:
    app: nginx
  spec:
   containers:
   - name: nginx
     image: nginx:1.9.1
     ports:
     - containerPort: 80
       name: web

然后我们创建这个service和statefulset

[root@host1 statefulset]# kubectl create -f nginx-statefulset.yaml 
service/nginx created
statefulset.apps/web created
[root@host1 statefulset]# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1            443/TCP   23h
nginx        ClusterIP   None                 80/TCP    9s
[root@host1 statefulset]# kubectl get statefulset
NAME   READY   AGE
web    2/2     22s
[root@host1 statefulset]# kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
web-0                   1/1     Running   0          104s
web-1                   1/1     Running   0          103s

StatefulSet给它所管理的所有的Pod的名字进行了编号，编号规则是：-；并且这些编号都是从0开始累加，与StatefulSet的每个Pod实例一一对应；这些Pod的创建也是严格按照编号顺序进行的。比如在web-0进入到running状态，并且Conditions为Ready之前，web-1一直会处于pending状态

使用kubectl exec命令进入到容器内部查看它们的hostname：

[root@host1 statefulset]# kubectl exec web-0 -- sh -c 'hostname'
web-0
[root@host1 statefulset]# kubectl exec web-1 -- sh -c 'hostname'
web-1

并且，就算Pod被删除后重建，重建Pod的网络标识也不会改变，通过这种方式，Kubernetes就可以成功地将Pod的拓扑状态按照Pod的“名字+编号”的方式固定下来，并且Kubernetes为每个Pod提供了一个固定且唯一的访问入口（这个Pod对应的DNS记录）。

StatefulSet控制器的主要作用之一，就是使用Pod模板创建Pod的时候，对它们进行编号，并且按照编号顺序逐一完成创建工作。当StatefulSet的控制循环发现Pod的实际状态和期望状态不一致的时候，需要新建或删除Pod进行调谐的时候，它会严格按照这些Pod编号的顺序，逐一完成这些操作。任何Pod的变化都会触发statefulset的滚动更新

存储管理

Kubernetes中PV和PVC的设计，类似于“接口”和“实现”的思想。PV和PVC的设计，使得StatefulSet对存储状态的管理成为了可能。

kind: StatefulSet
metadata:
 name: web
spec:
 serviceName: "nginx"
 replicas: 2
 selector:
  matchLabels:
   app: nginx
 template:
  metadata:
   labels:
    app: nginx
  spec:
   containers:
   - name: nginx
     image: nginx:1.9.1
     ports:
     - containerPort: 80
       name: web
     volumeMounts:
     - name: www
       mountPath: /usr/share/nginx/html
 volumeClaimTemplates:
  - metadata:
     name: www
    spec:
     storageClassName: rook-ceph-block
     accessModes:
     - ReadWriteOnce
     resources:
      requests:
       storage: 1Gi
---
apiVersion: v1
kind: Service
metadata:
 name: nginx
 labels:
  app: nginx
spec:
 ports:
 - port: 80
   name: web
 clusterIP: None
 selector:
  app: nginx

这里我们使用了Rook的ceph Flex Driver，关于rook的配置可以参考官方文档 https://rook.io/docs/rook/v1.1/ceph-block.html

然后我们创建这个Statefulset

[root@host1 statefulset]# kubectl create -f nginx-statefulset.yaml 
statefulset.apps/web created
service/nginx created
[root@host1 statefulset]# kubectl get statefulset
NAME   READY   AGE
web    2/2     8s
[root@host1 statefulset]# kubectl get statefulset
NAME   READY   AGE
web    2/2     10s
[root@host1 statefulset]# kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
test-projected-volume   1/1     Running   1          25h
web-0                   1/1     Running   0          13s
web-1                   1/1     Running   0          11s
[root@host1 statefulset]# kubectl get pvc
NAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
www-web-0   Bound    pvc-167033a6-f56a-11e9-9319-000c296c79f3   1Gi        RWO            rook-ceph-block   2m19s
www-web-1   Bound    pvc-17bc7e66-f56a-11e9-9319-000c296c79f3   1Gi        RWO            rook-ceph-block   2m17s

当我们进入上述创建的Pod，在/usr/share/nginx/html中写入内容，即使Pod被删除重建，Volume中的内容仍不会丢失。这是怎么做到的？

StatefulSet控制器恢复Pod的过程分析:

首先，当你把一个Pod，比如web-0删除之后，这个Pod对应的PV和PVC并不会被删除，而这个Volume中写入的数据，也依然存储在远程存储服务中。

此时，StatefulSet控制器发现，一个名叫web-0的Pod消失了。所以控制器会重新创建一个新的、名字还是叫做web-0的Pod，来进行调谐。

并且这个新Pod对象的定义中，它声明使用的PVC的名字，仍是www-web-0。所以这个新的web-0 Pod被创建出来之后，Kubernetes为它查找名叫www-web-0的PVC时，就会将旧Pod遗留的PVC，进而找到和这个PVC绑定在一起的PV

StatefulSet工作原理

首先，StatefulSet的控制器直接管理的是Pod。

其次，Kubernetes通过Headless Serrvice，为那些有编号的Pod，在DNS服务器中生成带有同样编号的DNS记录。只要StatefulSet能够保证这些Pod名字中的编号不变，那么Service中类似于web-0.nginx.default.svc.cluster.clocal这样的DNS记录也不会变，这条记录解析出来的Pod的IP地址，随着后端Pod的删除和创建而自动更新。

最后，StatefulSet还会为每一个Pod分配并创建一个同样编号的PVC。这样，kubernetes就可以通过Persistent Volume机制为这个PVC绑定对应的PV，从而保证每一个Pod都拥有一个独立的Volume

参考: 阿里云大学云原生技术公开课极客时间深入刨析Kubernetes

Kubernetes-StatefulSet