kubernetes之StatefulSet详解

系列目录

概述

RC、Deployment、DaemonSet都是面向无状态的服务，它们所管理的Pod的IP、名字，启停顺序等都是随机的，而StatefulSet是什么？顾名思义，有状态的集合，管理全部有状态的服务，好比MySQL、MongoDB集群等。
StatefulSet本质上是Deployment的一种变体，在v1.9版本中已成为GA版本，它为了解决有状态服务的问题，它所管理的Pod拥有固定的Pod名称，启停顺序，在StatefulSet中，Pod名字称为网络标识(hostname)，还必需要用到共享存储。
在Deployment中，与之对应的服务是service，而在StatefulSet中与之对应的headless service，headless service，即无头服务，与service的区别就是它没有Cluster IP，解析它的名称时将返回该Headless Service对应的所有Pod的Endpoint列表。
除此以外，StatefulSet在Headless Service的基础上又为StatefulSet控制的每一个Pod副本建立了一个DNS域名，这个域名的格式为：

$(podname).(headless server name)
FQDN： $(podname).(headless server name).namespace.svc.cluster.local

StatefulSet示例

接下来看一些示例，演示下上面所说的特性，以加深理解

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:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"  #声明它属于哪一个Headless Service.
  replicas: 3 # by default is 1
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:   #可看做pvc的模板
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "gluster-heketi"  #存储类名，改成集群中已存在的
      resources:
        requests:
          storage: 1Gi

经过该配置文件，可看出StatefulSet的三个组成部分：

• Headless Service：名为nginx，用来定义Pod网络标识( DNS domain)。
• StatefulSet：定义具体应用，名为Nginx，有三个Pod副本，并为每一个Pod定义了一个域名。
• volumeClaimTemplates： 存储卷申请模板，建立PVC，指定pvc名称大小，将自动建立pvc，且pvc必须由存储类供应。

为何须要 headless service 无头服务？
在用Deployment时，每个Pod名称是没有顺序的，是随机字符串，所以是Pod名称是无序的，可是在statefulset中要求必须是有序 ，每个pod不能被随意取代，pod重建后pod名称仍是同样的。而pod IP是变化的，因此是以Pod名称来识别。pod名称是pod惟一性的标识符，必须持久稳定有效。这时候要用到无头服务，它能够给每一个Pod一个惟一的名称 。

为何须要volumeClaimTemplate？ 对于有状态的副本集都会用到持久存储，对于分布式系统来说，它的最大特色是数据是不同的，因此各个节点不能使用同一存储卷，每一个节点有自已的专用存储，可是若是在Deployment中的Pod template里定义的存储卷，是全部副本集共用一个存储卷，数据是相同的，由于是基于模板来的 ，而statefulset中每一个Pod都要自已的专有存储卷，因此statefulset的存储卷就不能再用Pod模板来建立了，因而statefulSet使用volumeClaimTemplate，称为卷申请模板，它会为每一个Pod生成不一样的pvc，并绑定pv， 从而实现各pod有专用存储。这就是为何要用volumeClaimTemplate的缘由。

建立：

$ kubectl create -f nginx.yaml 
service "nginx" created
statefulset "web" created

看下这三个Pod建立过程：

#第一个是建立web-0
$ kubectl get pod
web-0                     1/1       ContainerCreating   0          51s

#待web-0 running且ready时，建立web-1
$ kubectl get pod
web-0                     1/1       Running             0          51s
web-1                     0/1       ContainerCreating   0          42s

#待web-1 running且ready时，建立web-2
$ kubectl get pod
web-0                     1/1       Running             0          1m
web-1                     1/1       Running             0          45s
web-2                     1/1       ContainerCreating   0          36s

#最后三个Pod所有running且ready
$ kubectl get pod
NAME                      READY     STATUS    RESTARTS   AGE
web-0                     1/1       Running   0          4m
web-1                     1/1       Running   0          3m
web-2                     1/1       Running   0          1m

根据volumeClaimTemplates自动建立的PVC

$ kubectl get pvc
NAME              STATUS    VOLUME                                  CAPACITY   ACCESS MODES   STORAGECLASS     AGE
www-web-0         Bound     pvc-ecf003f3-828d-11e8-8815-000c29774d39   2G        RWO          gluster-heketi   7m
www-web-1         Bound     pvc-0615e33e-828e-11e8-8815-000c29774d39   2G        RWO          gluster-heketi   6m
www-web-2         Bound     pvc-43a97acf-828e-11e8-8815-000c29774d39   2G        RWO          gluster-heketi   4m

若是集群中没有StorageClass的动态供应PVC的机制，也能够提早手动建立多个PV、PVC，手动建立的PVC名称必须符合以后建立的StatefulSet命名规则：(volumeClaimTemplates.name)-(pod_name)

Statefulset名称为web 三个Pod副本: web-0，web-1,web-2，volumeClaimTemplates名称为：www，那么自动建立出来的PVC名称为www-web[0-2]，为每一个Pod建立一个PVC。

规律总结：

• 匹配Pod name(网络标识)的模式为：$(statefulset名称)-$(序号)，好比上面的示例：web-0，web-1，web-2。

• StatefulSet为每一个Pod副本建立了一个DNS域名，这个域名的格式为： $(podname).(headless server name)，也就意味着服务间是经过Pod域名来通讯而非Pod IP，由于当Pod所在Node发生故障时，Pod会被飘移到其它Node上，Pod IP会发生变化，可是Pod域名不会有变化。

• StatefulSet使用Headless服务来控制Pod的域名，这个域名的FQDN为：$(service name).$(namespace).svc.cluster.local，其中，“cluster.local”指的是集群的域名。

• 根据volumeClaimTemplates，为每一个Pod建立一个pvc，pvc的命名规则匹配模式：(volumeClaimTemplates.name)-(pod_name)，好比上面的volumeMounts.name=www， Pod name=web-[0-2]，所以建立出来的PVC是www-web-0、www-web-一、www-web-2。

• 删除Pod不会删除其pvc，手动删除pvc将自动释放pv。
  关于Cluster Domain、headless service名称、StatefulSet 名称如何影响StatefulSet的Pod的DNS域名的示例：

Cluster Domain	Service (ns/name)	StatefulSet (ns/name)	StatefulSet Domain	Pod DNS	Pod Hostname
cluster.local	default/nginx	default/web	nginx.default.svc.cluster.local	web-{0..N-1}.nginx.default.svc.cluster.local	web-{0..N-1}
cluster.local	foo/nginx	foo/web	nginx.foo.svc.cluster.local	web-{0..N-1}.nginx.foo.svc.cluster.local	web-{0..N-1}
kube.local	foo/nginx	foo/web	nginx.foo.svc.kube.local	web-{0..N-1}.nginx.foo.svc.kube.local	web-{0..N-1}

Statefulset的启停顺序：

• 有序部署：部署StatefulSet时，若是有多个Pod副本，它们会被顺序地建立（从0到N-1）而且，在下一个Pod运行以前全部以前的Pod必须都是Running和Ready状态。

• 有序删除：当Pod被删除时，它们被终止的顺序是从N-1到0。

• 有序扩展：当对Pod执行扩展操做时，与部署同样，它前面的Pod必须都处于Running和Ready状态

Statefulset Pod管理策略：

在v1.7之后，经过容许修改Pod排序策略，同时经过.spec.podManagementPolicy字段确保其身份的惟一性。

• OrderedReady：上述的启停顺序，默认设置。
• Parallel：告诉StatefulSet控制器并行启动或终止全部Pod，而且在启动或终止另外一个Pod以前不等待前一个Pod变为Running and Ready或彻底终止。

StatefulSet使用场景：

• 稳定的持久化存储，即Pod从新调度后仍是能访问到相同的持久化数据，基于PVC来实现。

• 稳定的网络标识符，即Pod从新调度后其PodName和HostName不变。

• 有序部署，有序扩展，基于init containers来实现。

• 有序收缩。

更新策略

在Kubernetes 1.7及更高版本中，经过.spec.updateStrategy字段容许配置或禁用Pod、labels、source request/limits、annotations自动滚动更新功能。

• OnDelete：经过.spec.updateStrategy.type 字段设置为OnDelete，StatefulSet控制器不会自动更新StatefulSet中的Pod。用户必须手动删除Pod，以使控制器建立新的Pod。

• RollingUpdate：经过.spec.updateStrategy.type 字段设置为RollingUpdate，实现了Pod的自动滚动更新，若是.spec.updateStrategy未指定，则此为默认策略。

StatefulSet控制器将删除并从新建立StatefulSet中的每一个Pod。它将以Pod终止（从最大序数到最小序数）的顺序进行，一次更新每一个Pod。在更新下一个Pod以前，必须等待这个Pod Running and Ready。

• Partitions：经过指定 .spec.updateStrategy.rollingUpdate.partition 来对 RollingUpdate 更新策略进行分区，若是指定了分区，则当 StatefulSet 的 .spec.template 更新时，具备大于或等于分区序数的全部 Pod 将被更新。 具备小于分区的序数的全部 Pod 将不会被更新，即便删除它们也将被从新建立。若是 StatefulSet 的 .spec.updateStrategy.rollingUpdate.partition 大于其 .spec.replicas，则其 .spec.template 的更新将不会传播到 Pod。在大多数状况下，不须要使用分区。