StatefulSet-阿里云开发者社区

屏幕截图 2023-08-28 163846.png

StatefulSet

生产中常用的副本控制器如Deployment、DaemonSet、RS都是适用于无状态服务，其所管理的Pod

的启停顺序、IP、Podname等都是随机的，被管理的Pod被更新掉时，都会变化。

Kubernetes中StatefulSet是专为有状态服务如redis、kafka、consul等集群准备的集合，管理

所有有状态服务。

什么是有状态服务？有状态服务与无状态服务主要有如下区别:

1) 判断服务是否有状态，是指两个来自相同发起者(客户端)的请求在服务器端是否具备上下文关

系；

2) 有状态服务，一般服务器端都要保存与请求的相关信息，每个请求可以默认地使用之前的请求

信息；

3) 相反，无状态服务一般服务器端所能够处理的过程全部来自于请求所携带的信息或者其他服务

器端自身所保存的、并且可以被所有请求所使用的公共信息。

StatefulSet管理的Pod拥有固定的Pod名称(一般是pod.name-0/-1/-2顺延)、启停顺序(从-0开始

依次重启)；在StatefulSet中，Pod名字称为网络标识(hostname)，还必须要用到共享存储。

与Deployment对应的网络映射为service，而在StatefulSet中与之对应的headless service(无头

服务)，相较于services,headless service没有ClusterIP，解析它的名称时将返回该Headless

Service对应的全部Pod的Endpoint列表。

一个完整的StatefulSet应用由三个部分组成： headless service、StatefulSet controller、

volumeClaimTemplate。

kubernetes中选择使用statefullSet的服务所具有如下特点：

1) 稳定且唯一的网络标识符（如kfaka集群zookeeper的myid）；

2) 稳定且持久的存储(如redis cluster模式下每个节点的shard)；

3) 有序、平滑地部署扩展、终止和删除；

4) 有序的滚动更新；

------------------------------------------------

运行有状态的服务,前提：创建好storageclass。

示例：

```yaml
[root@master statefulSet]# vim statefulSet.yaml
apiVersion: v1
kind: Service
metadata:
  name: headless-svc
  labels:
    app: headless-svc
spec:
  ports:
  - name: myweb
    port: 80
  selector:
    app: headless-pod
  clusterIP: None
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: statefulset
spec:
  serviceName: headless-svc
  replicas: 3
  selector:
    matchLabels:
      app: headless-pod
  template:
    metadata:
      labels:
        app: headless-pod
    spec:
      containers:
      - name: myweb
        image: nginx
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: test-storage
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: test-storage
      annotations:
        volume.beta.kubernetes.io/storage-class: storageclass
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 100Mi

为什么用 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的原因。

//写完之后，直接运行，并且，在此之前，我们并没有创建PV，PVC，现在查看集群中的资源，是否有这两种资源？

[root@master statefulSet]# kubectl get pv,pvc
NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                STORAGECLASS   REASON   AGE
persistentvolume/pvc-582374f3-263c-403d-8811-e7043837bae9   100Mi      RWO            Delete           Bound    default/test-storage-statefulset-1   storageclass            2m47s
persistentvolume/pvc-83b7e7a4-2d57-477b-a79f-7ec6a572cd11   100Mi      RWO            Delete           Bound    default/test-storage-statefulset-0   storageclass            3m42s
persistentvolume/pvc-dc481cc2-2e28-441c-a4da-4145b7746670   100Mi      RWO            Delete           Bound    default/test-storage-statefulset-2   storageclass            113s
NAME                                               STATUS        VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/test-storage-statefulset-0   Bound         pvc-83b7e7a4-2d57-477b-a79f-7ec6a572cd11   100Mi      RWO            storageclass   3m42s
persistentvolumeclaim/test-storage-statefulset-1   Bound         pvc-582374f3-263c-403d-8811-e7043837bae9   100Mi      RWO            storageclass   2m47s
persistentvolumeclaim/test-storage-statefulset-2   Bound         pvc-dc481cc2-2e28-441c-a4da-4145b7746670   100Mi      RWO            storageclass   113s
```

//从上述结果中，我们知道，storageclass为我们自动创建了PV，volumeClaimTemplate为我们自动创建PVC，但是否能够满足我们所说的，每一个Pod都有自己独有的数据持久化目录，也就是说，每一个Pod内的数据都是不一样的。

//分别在对应的PV下，模拟创建不同的数据。

cd /nfsdata/
echo "0000000000000000" > default-test-storage-statefulset-0-pvc-4d7a43ed-bbee-48bd-86fa-a7e744613e80/index.html
echo "1111111111111111" > default-test-storage-statefulset-1-pvc-7049d6a2-949c-4ea5-97da-c655a77ad8e3/index.html
echo "2222222222222222" > default-test-storage-statefulset-2-pvc-9da968ba-8b49-4f10-bc97-ba4c79c87c6f/index.html
//查看对应Pod的数据持久化目录，可以看出，每个Pod的内容都不一样。
kubectl exec statefulset-0 cat /usr/share/nginx/html/index.html
000000000000000
kubectl exec statefulset-1 cat /usr/share/nginx/html/index.html
111111111111111
kubectl exec statefulset-2 cat /usr/share/nginx/html/index.html
222222222222222

//即使删除Pod,然后statefulSet这个Pod控制器会生成一个新的Pod，这里不看Pod的IP,名称肯定和之前的一致，而且，最主要是持久化的数据仍然存在。

[root@master ~]# kubectl delete pod statefulset-2 
pod "statefulset-2" deleted
[root@master ~]# kubectl get pod
NAME                     READY   STATUS              RESTARTS   AGE
mysql-6fccccd487-5q2dt   1/1     Running             0          45h
statefulset-0            1/1     Running             0          12m
statefulset-1            1/1     Running             0          11m
statefulset-2            0/1     ContainerCreating   0          5s
[root@master ~]# kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
mysql-6fccccd487-5q2dt   1/1     Running   0          45h
statefulset-0            1/1     Running   0          12m
statefulset-1            1/1     Running   0          11m
statefulset-2            1/1     Running   0          11s
kubectl exec statefulset-2 cat /usr/share/nginx/html/index.html
222222222222222

规律总结

匹配Pod name(网络标识)的模式为：名称 (statefulset名称)−(statefulset名称)-(序号)

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

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