5.深入k8s：StatefulSet控制器

转载请声明出处哦~，本篇文章发布于luozhiyun的博客：https://www.luozhiyun.com

在上一篇中，讲解了容器持久化存储，从中我们知道什么是PV和PVC，这一篇我们讲通过StatefulSet来使用它们。

我们在第三篇讲的Deployment控制器是应用于无状态的应用的，所有的Pod启动之间没有顺序，Deployment可以任意的kill一个Pod不会影响到业务数据，但是这到了有状态的应用中就不管用了。

而StatefulSet就是用来对有状态应用提供支持的控制器。

StatefulSet把真实世界里的应用状态，抽象为了两种情况：

1. 拓扑状态。应用的多个实例之间不是完全对等的关系。这些应用实例，必须按照某些顺序启动，比如应用的主节点 A 要先于从节点 B 启动。并且，新创建出来的 Pod，必须和原来 Pod 的网络标识一样。
2. 存储状态。应用的多个实例分别绑定了不同的存储数据，对于这些应用实例来说，Pod A 第一次读取到的数据，和隔了十分钟之后再次读取到的数据，应该是同一份，哪怕在此期间 Pod A 被重新创建过。

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

拓扑状态

在k8s中，Service是用来将一组 Pod 暴露给外界访问的一种机制。Service可以通过DNS的方式，代理到某一个Pod，然后通过DNS记录的方式解析出被代理 Pod 的 IP 地址。

如下：

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx

这个Service会通过Label Selector选择所有携带了 app=nginx 标签的 Pod，都会被这个 Service 代理起来。

它所代理的所有 Pod 的 IP 地址，都会被绑定一个这样格式的 DNS 记录，如下所示：

<pod-name>.<svc-name>.<namespace>.svc.cluster.local

所以通过这个DNS记录，StatefulSet就可以使用到DNS 记录来维持 Pod 的拓扑状态。

如下：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2  # by default is 1
  selector:
    matchLabels:
      app: nginx  # has to match .spec.template.metadata.labels
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      containers:
      - name: nginx
        image: nginx:1.9.1
        ports:
        - containerPort: 80
          name: web

这里使用了serviceName=nginx，表明StatefulSet 控制器会使用nginx 这个Service来进行网络代理。

我们可以如下创建：

$ kubectl create -f svc.yaml
$ kubectl get service nginx
NAME      TYPE         CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
nginx     ClusterIP    None         <none>        80/TCP    10s
$ kubectl create -f statefulset.yaml
$ kubectl get statefulset web
NAME      DESIRED   CURRENT   AGE
web       2         1         19s

然后我们可以观察pod的创建情况：

$ kubectl get pods -w -l app=nginx
NAME    READY   STATUS    RESTARTS   AGE
web-0   1/1     Running   0          76m
web-1   1/1     Running   0          76m

我们通过-w命令可以看到pod创建情况，StatefulSet所创建的pod编号都是从0开始累加，在 web-0 进入到 Running 状态、并且细分状态（Conditions）成为 Ready 之前，web-1 会一直处于 Pending 状态。

然后我们使用exec查看pod的hostname：

$ kubectl exec web-0 -- sh -c 'hostname'
web-0
$ kubectl exec web-1 -- sh -c 'hostname'
web-1

然后我们可以启动一个一次性的pod用 nslookup 命令，解析一下 Pod 对应的 Headless Service：

$ kubectl run -i --tty --image busybox:1.28.4 dns-test --restart=Never --rm /bin/sh
$ nslookup web-0.nginx
Server:    10.68.0.2
Address 1: 10.68.0.2 kube-dns.kube-system.svc.cluster.local
Name:      web-0.nginx
Address 1: 172.20.0.56 web-0.nginx.default.svc.cluster.local
$ nslookup web-1.nginx
Server:    10.68.0.2
Address 1: 10.68.0.2 kube-dns.kube-system.svc.cluster.local
Name:      web-1.nginx
Address 1: 172.20.0.57 web-1.nginx.default.svc.cluster.local

如果我们删除了这两个pod，然后观察pod情况：

$ kubectl delete pod -l app=nginx
$ kubectl get pod -w -l app=nginx
web-0   1/1     Terminating   0          83m
web-1   1/1     Terminating   0          83m
web-0   0/1     Pending       0          0s
web-1   0/1     Terminating   0          83m
web-0   0/1     ContainerCreating   0          0s
web-0   1/1     Running             0          1s
web-1   0/1     Pending             0          0s
web-1   0/1     ContainerCreating   0          0s
web-1   1/1     Running             0          1s

当我们把这两个 Pod 删除之后，Kubernetes 会按照原先编号的顺序，创建出了两个新的 Pod。并且，Kubernetes 依然为它们分配了与原来相同的“网络身份”：web-0.nginx 和 web-1.nginx。

但是网络结构虽然没变，但是pod对应的ip是改变了的，我们再进入到pod进行DNS解析：

$ nslookup web-0.nginx
Server:    10.68.0.2
Address 1: 10.68.0.2 kube-dns.kube-system.svc.cluster.local
Name:      web-0.nginx
Address 1: 172.20.0.59 web-0.nginx.default.svc.cluster.local
$ nslookup web-1.nginx
Server:    10.68.0.2
Address 1: 10.68.0.2 kube-dns.kube-system.svc.cluster.local
Name:      web-1.nginx
Address 1: 172.20.0.60 web-1.nginx.default.svc.cluster.local

存储状态

在讲存储状态的时候，需要大家掌握上一节有关pv和pvc的知识才好往下继续，建议大家看完再来看本节。

在上一节中，我们了解到Kubernetes 中 PVC 和 PV 的设计，实际上类似于“接口”和“实现”的思想。而 PVC、PV 的设计，也使得 StatefulSet 对存储状态的管理成为了可能。

比如我们声明一个如下的StatefulSet：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 1
  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: local-volume-a
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: local-volume-a
    spec:
      accessModes:
      - ReadWriteMany
      storageClassName: "local-volume"
      resources:
        requests:
          storage: 512Mi
      selector:
        matchLabels:
          key: local-volume-a-0

在这个StatefulSet中添加了volumeClaimTemplates字段，用来声明对应的PVC的定义；也就是说这个PVC中使用的storageClass必须是local-volume，需要的存储空间是512Mi，并且这个pvc对应的pv的标签必须是key: local-volume-a-0。

然后我们准备一个PV：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-volume-pv-0
  labels:
    key: local-volume-a-0
spec:
  capacity:
    storage: 0.5Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-volume
  local:
    path: /mnt/disks/vol1
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - node1

我把这个PV创建在node1节点上，并且将本地磁盘挂载声明为PV。

然后我们创建这个PV：

$ kubectl apply -f local-pv-web-0.yaml
$ kubectl get pv
NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM
               STORAGECLASS   REASON   AGE
local-volume-pv-0   512Mi      RWX            Retain           Available       default/local-vo

然后我们在创建这个StatefulSet的时候，会自动创建PVC：

$ kubectl apply -f statefulset2.yaml
$ kubectl get pvc
NAME                   STATUS   VOLUME              CAPACITY   ACCESS MODES   STORAGECLASS   AGE
local-volume-a-web-0   Bound    local-volume-pv-0   512Mi      RWX            local-volume   15m

创建的PVC名字都是由：<PVC 名字 >-<StatefulSet 名字 >-< 编号 >构成，编号从0开始，并且我们可以看到上面的PV已经处于Bound状态。

这个时候我们进入到Pod中，写入一个文件：

$ kubectl exec -it web-0  -- /bin/bash
$ echo helloword >/usr/share/nginx/html/index.html

这样就会在Pod 的 Volume 目录里写入一个文件，如果我们把这个Pod删除，那么在被删除之后这个Pod还是会被创建出来，并且还会再和原来的PV：local-volume-pv-0绑定起来。

也就是说当StatefulSet 控制器发现一个名叫 web-0 的 Pod 消失了的时候，控制器就会重新创建一个新的、名字还是叫作 web-0 的 Pod 来，“纠正”这个不一致的情况。并且删除Pod时并不会删除这个 Pod 对应的 PVC 和 PV。需要注意的是，在这个新的 Pod 对象的定义里，它声明使用的 PVC 的名字，还是叫作local-volume-a-web-0。

通过这种方式，Kubernetes 的 StatefulSet 就实现了对应用存储状态的管理。

更新策略

在 Kubernetes 1.7 及之后的版本中，可以为 StatefulSet 设定 .spec.updateStrategy 字段。

OnDelete

如果 StatefulSet 的 .spec.updateStrategy.type 字段被设置为 OnDelete，当您修改 .spec.template 的内容时，StatefulSet Controller 将不会自动更新其 Pod。您必须手工删除 Pod，此时 StatefulSet Controller 在重新创建 Pod 时，使用修改过的 .spec.template 的内容创建新 Pod。

例如我们执行下面的语句更新上面例子中创建的web：

$ kubectl set image statefulset web nginx=nginx:1.18.0
$ kubectl describe pod web-0
....
Containers:
  nginx:
    Container ID:   docker://7e45cd509db74a96b4f6ca4d9f7424b3c4794f56e28bfc3fbf615525cd2ecadb
    Image:          nginx:1.9.1
....

然后我们发现pod的nginx版本并没有发生改变，需要我们手动删除pod之后才能生效。

$ kubectl delete pod web-0
pod "web-0" deleted
$ kubectl describe pod web-0
...
Containers:
  nginx:
    Container ID:   docker://0f58b112601a39f3186480aa97e72767b05fdfa6f9ca02182d3fb3b75c159ec0
    Image:          nginx:1.18.0
...

Rolling Updates

.spec.updateStrategy.type 字段的默认值是 RollingUpdate，该策略为 StatefulSet 实现了 Pod 的自动滚动更新。在更新完.spec.tempalte 字段后StatefulSet Controller 将自动地删除并重建 StatefulSet 中的每一个 Pod。

删除和重建的顺序也是有讲究的：

• 删除的时候从序号最大的开始删，每删除一个会更新一个。
• 只有更新完的pod已经是ready状态了才往下继续更新。

为 RollingUpdate 进行分区

当为StatefulSet 的 RollingUpdate 字段的指定 partition 字段的时候，则所有序号大于或等于 partition 值的 Pod 都会更新。序号小于 partition 值的所有 Pod 都不会更新，即使它们被删除，在重新创建时也会使用以前的版本。

如果 partition 值大于其 replicas 数，则更新不会传播到其 Pod。这样可以实现金丝雀发布Canary Deploy或者灰度发布。

如下，因为我们的web是2个pod组成，所以可以将partition设置为1：

$ kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":1}}}}'

在这里，我使用了 kubectl patch 命令。它的意思是，以“补丁”的方式（JSON 格式的）修改一个 API 对象的指定字段。

下面我们执行更新：

$ kubectl set image statefulset  web nginx=nginx:1.19.1
statefulset.apps/web image updated

并在另一个终端中watch pod的变化：

$ kubectl get pods -l app=nginx -w
NAME    READY   STATUS    RESTARTS   AGE
web-0   1/1     Running   0          13m
web-1   1/1     Running   0          93s
web-1   0/1     Terminating   0          2m16s
web-1   0/1     Pending       0          0s
web-1   0/1     ContainerCreating   0          0s
web-1   1/1     Running             0          16s

可见上面只有一个web-1进行了版本的发布。

总结

StatefulSet把有状态的应用抽象为两种情况：拓扑状态和存储状态。

拓扑状态指的是应用的多个实例之间不是完全对等的关系，包含启动的顺序、创建之后的网络标识等必须保证。

存储状态指的是不同的实例绑定了不同的存储，如Pod A在它的生命周期中读取的数据必须是一致的，哪怕是重启之后还是需要读取到同一个存储。

然后讲解了一下StatefulSet发布更新该如何做，updateStrategy策略以及通过partition如果实现金丝雀发布等。