一.系统环境
本文主要基于Kubernetes1.21.9和Linux操作系统CentOS7.4。
| 服务器版本 | docker软件版本 | Kubernetes(k8s)集群版本 | CPU架构 |
|---|---|---|---|
| CentOS Linux release 7.4.1708 (Core) | Docker version 20.10.12 | v1.21.9 | x86_64 |
Kubernetes集群架构：k8scloude1作为master节点，k8scloude2，k8scloude3作为worker节点。
| 服务器 | 操作系统版本 | CPU架构 | 进程 | 功能描述 |
|---|---|---|---|---|
| k8scloude1/192.168.110.130 | CentOS Linux release 7.4.1708 (Core) | x86_64 | docker，kube-apiserver，etcd，kube-scheduler，kube-controller-manager，kubelet，kube-proxy，coredns，calico | k8s master节点 |
| k8scloude2/192.168.110.129 | CentOS Linux release 7.4.1708 (Core) | x86_64 | docker，kubelet，kube-proxy，calico | k8s worker节点 |
| k8scloude3/192.168.110.128 | CentOS Linux release 7.4.1708 (Core) | x86_64 | docker，kubelet，kube-proxy，calico | k8s worker节点 |
二.前言
在Kubernetes集群中部署和管理有状态应用是一项复杂的任务。有状态应用(Stateful Applications)通常要求持久化存储、唯一网络标识和有序的启动顺序。为了解决这些需求，Kubernetes提供了一个强大的控制器——StatefulSet。
使用StatefulSet的前提是已经有一套可以正常运行的Kubernetes集群，关于Kubernetes(k8s)集群的安装部署，可以查看博客《Centos7 安装部署Kubernetes(k8s)集群》https://www.cnblogs.com/renshengdezheli/p/16686769.html。
三.StatefulSet简介
StatefulSet是Kubernetes的一个核心控制器，用于管理有状态应用的部署和伸缩。它为每个Pod分配一个唯一的标识符，确保有状态应用的稳定性和可扩展性。StatefulSet还可以自动处理Pod的创建、删除和更新，确保有状态应用的高可用性。
相比于Deployment等控制器，StatefulSet提供了以下特性：
- 稳定的网络标识符：每个Pod都会被分配一个稳定的主机名和网络标识符，使得有状态应用能够方便地进行服务发现和通信。
- 有序的部署和扩展：StatefulSet确保有状态应用的Pod按照指定的顺序进行部署和扩展，保证有序启动和关闭。
- 持久化存储：StatefulSet支持将持久化存储卷(Persistent Volume)与Pod绑定，使得有状态应用能够保留数据。
StatefulSet简写为sts，deployment控制器创建出来的pod都是一样的，更适合用于对外提供服务的pod，但是有一些应用，只适用于公
司内部，并不想对外提供服务，比如一个数据库有1个master节点和3个slave节点，master提供写，slave提供读，master通过日志把数
据拷贝给slave，slave节点有自己的存储，slave1读slave1的存储，slave2读slave2的存储，以此类推，slave节点不共享存储，这种情况
不适合使用deployment来创建pod，这种情况就需要使用statefulset控制器。
StatefulSet常用的属性包括：
- serviceName：指定与StatefulSet关联的Service的名称。这个Service将用于提供稳定的网络标识符，供其他应用访问StatefulSet中的Pod。
- volumeClaimTemplates：定义了每个Pod所需的持久化存储卷(Claim)模板。可以在这里指定存储类、存储大小等参数，以满足有状态应用对持久化存储的需求。
- podManagementPolicy：指定Pod管理策略，可以是OrderedReady或Parallel。OrderedReady表示按顺序启动和终止Pod，保证有序性和稳定性；Parallel表示可以并行启动和终止Pod，适用于无依赖关系的应用场景。
四.有状态应用和无状态应用区别
在Kubernetes中，应用可以分为有状态应用和无状态应用。有状态应用是指需要保留数据或状态的应用，而无状态应用则不需要。
有状态应用与无状态应用之间的主要区别如下：
- 网络标识符：有状态应用需要稳定的网络标识符，使得其他服务能够准确地访问它们。而无状态应用通常使用Service来提供负载均衡和服务发现，不直接依赖于特定的网络标识符。
- 数据持久化：有状态应用需要将数据保存在持久化存储中，并且能够在Pod重新启动时恢复数据。无状态应用通常将数据保存在外部数据库或缓存中，不依赖于Pod的生命周期。
- 有序启动和关闭：有状态应用通常需要按照特定的顺序启动和关闭，以确保数据的一致性。无状态应用则可以并行启动和关闭，不需要保证顺序。
五.StatefulSet
5.1 创建StatefulSet
创建存放yaml文件的目录。
[root@k8scloude1 ~]# mkdir statefulset [root@k8scloude1 ~]# cd statefulset/ 创建命名空间。
[root@k8scloude1 statefulset]# kubectl create ns statefulset namespace/statefulset created 切换命名空间。
[root@k8scloude1 statefulset]# kubens statefulset Context "kubernetes-admin@kubernetes" modified. Active namespace is "statefulset". 现在还没有pod。
[root@k8scloude1 statefulset]# kubectl get pod No resources found in statefulset namespace. 查看存储类storageclass，managed-nfs-storage是我们前面章节创建的storageclass，关于存储类storageclass的详细信息，请查看博客《Kubernetes(k8s)存储管理之数据卷volumes(五)：动态制备-存储类StorageClass》。
[root@k8scloude1 statefulset]# cd sts/ [root@k8scloude1 sts]# kubectl get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE managed-nfs-storage fuseim.pri/ifs Delete Immediate false 71d 查看managed-nfs-storage 的描述信息。
[root@k8scloude1 sts]# kubectl describe sc managed-nfs-storage Name: managed-nfs-storage IsDefaultClass: No Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{},"name":"managed-nfs-storage"},"parameters":{"archiveOnDelete":"false"},"provisioner":"fuseim.pri/ifs"} Provisioner: fuseim.pri/ifs Parameters: archiveOnDelete=false AllowVolumeExpansion: <unset> MountOptions: <none> ReclaimPolicy: Delete VolumeBindingMode: Immediate Events: <none> StatefulSet的yaml文件如下，功能为：创建一个StatefulSet，其中包含一个Pod运行着Nginx容器，并且有一个挂载了持久化存储卷的文件系统。这个StatefulSet通过Service提供稳定的网络标识符，可以被其他应用访问。
[root@k8scloude1 sts]# vim sts.yaml [root@k8scloude1 sts]# cat sts.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: selector: #matchLabels：设置了一个标签选择器，选择具有app: nginx标签的Pod。 matchLabels: app: nginx #serviceName: "nginx"：指定了与StatefulSet关联的Service的名称为"nginx"。该Service将提供稳定的网络标识符供其他应用访问StatefulSet中的Pod。 serviceName: "nginx" #replicas: 1：定义了StatefulSet的副本数量为1，即只创建一个Pod。 replicas: 1 template: metadata: labels: app: nginx spec: #当需要关闭容器时，立即杀死容器而不等待默认的30秒优雅停机时长。 terminationGracePeriodSeconds: 0 containers: - name: nginx image: nginx #imagePullPolicy: IfNotPresent：表示如果本地已经存在该镜像，则不重新下载；否则从远程 Docker Hub 下载该镜像 imagePullPolicy: IfNotPresent #把www卷挂载到容器内的路径为"/usr/share/nginx/html" volumeMounts: - name: www mountPath: /usr/share/nginx/html #volumeClaimTemplates：定义了持久化存储卷(Claim)模板，用于创建Pod所需的持久化存储。 volumeClaimTemplates: - metadata: #name: www：指定了卷模板的名称为"www"。 name: www spec: #accessModes: [ "ReadWriteOnce" ]：设置了卷的访问模式为"ReadWriteOnce"，即可以被一个节点以读写方式挂载。 accessModes: [ "ReadWriteOnce" ] #storageClassName: "managed-nfs-storage"：指定了存储类的名称为"managed-nfs-storage"，用于创建持久化存储卷。 storageClassName: "managed-nfs-storage" resources: requests: #requests：设置了卷的请求资源，即要求1Gi的存储空间。 storage: 1Gi 现在还没有PVC。关于PV，PVC的详细内容，请查看博客《Kubernetes(k8s)存储管理之数据卷volumes(四)：持久卷Persistent Volume 》。
[root@k8scloude1 sts]# kubectl get pvc No resources found in statefulset namespace. 创建statefulset。
[root@k8scloude1 sts]# kubectl apply -f sts.yaml statefulset.apps/web created 创建statefulset之后，pod和PVC都有了。
[root@k8scloude1 sts]# kubectl get pod NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 8s [root@k8scloude1 sts]# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE www-web-0 Bound pvc-3b58a17b-acbd-4eb6-a1e4-a2bd2cf331ac 1Gi RWO managed-nfs-storage 37s 查看statefulset。
[root@k8scloude1 sts]# kubectl get statefulset -o wide NAME READY AGE CONTAINERS IMAGES web 1/1 111s nginx nginx [root@k8scloude1 sts]# kubectl get sts -o wide NAME READY AGE CONTAINERS IMAGES web 1/1 2m11s nginx nginx 5.2 scale扩展副本数
把statefulset的副本数扩展为2。
[root@k8scloude1 sts]# kubectl scale sts web --replicas=2 statefulset.apps/web scaled 查看statefulset。
[root@k8scloude1 sts]# kubectl get sts -o wide NAME READY AGE CONTAINERS IMAGES web 2/2 3m nginx nginx pod变为2个了。
[root@k8scloude1 sts]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES web-0 1/1 Running 0 3m27s 10.244.251.230 k8scloude3 <none> <none> web-1 1/1 Running 0 37s 10.244.251.219 k8scloude3 <none> <none> 把statefulset的副本数扩展为3。
[root@k8scloude1 sts]# kubectl scale sts web --replicas=3 statefulset.apps/web scaled pod变为3个了。
[root@k8scloude1 sts]# kubectl get pod NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 4m43s web-1 1/1 Running 0 113s web-2 1/1 Running 0 13s 查看statefulset。
[root@k8scloude1 sts]# kubectl get sts NAME READY AGE web 3/3 5m9s pvc也变为了3个。
[root@k8scloude1 sts]# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE www-web-0 Bound pvc-3b58a17b-acbd-4eb6-a1e4-a2bd2cf331ac 1Gi RWO managed-nfs-storage 5m54s www-web-1 Bound pvc-689e6b63-9ca8-413b-b240-5e2fae467a12 1Gi RWO managed-nfs-storage 3m4s www-web-2 Bound pvc-565f137f-9e4b-44a1-8953-2b71e393a409 1Gi RWO managed-nfs-storage 84s 在每个pod里写入不同的内容。
[root@k8scloude1 sts]# kubectl exec -it web-0 -- sh -c "echo web-0 > /usr/share/nginx/html/index.html" [root@k8scloude1 sts]# kubectl exec -it web-1 -- sh -c "echo web-1 > /usr/share/nginx/html/index.html" [root@k8scloude1 sts]# kubectl exec -it web-2 -- sh -c "echo web-2 > /usr/share/nginx/html/index.html" 把statefulset的副本数扩展为0，所有pod都被删除了。
[root@k8scloude1 sts]# kubectl scale sts web --replicas=0 statefulset.apps/web scaled [root@k8scloude1 sts]# kubectl get pod No resources found in statefulset namespace. 把statefulset的副本数扩展为3。
[root@k8scloude1 sts]# kubectl scale sts web --replicas=3 statefulset.apps/web scaled pod变为3个了。
[root@k8scloude1 sts]# kubectl get pod NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 3s web-1 0/1 ContainerCreating 0 1s [root@k8scloude1 sts]# kubectl get pod NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 8s web-1 1/1 Running 0 6s web-2 1/1 Running 0 4s 可以发现，把pod删除之后，又创建3个pod，新的3个pod名字没变，并且web-0的存储还是www-web-0，web-1的存储还是www-web-1，web-2的存储还是www-web-2，pod对应的存储不会错乱，每个pod里面的内容也没有变化。
[root@k8scloude1 sts]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES web-0 1/1 Running 0 5m41s 10.244.251.225 k8scloude3 <none> <none> web-1 1/1 Running 0 5m39s 10.244.251.226 k8scloude3 <none> <none> web-2 1/1 Running 0 5m37s 10.244.251.218 k8scloude3 <none> <none> [root@k8scloude1 sts]# kubectl exec -it web-0 -- sh -c "cat /usr/share/nginx/html/index.html" web-0 [root@k8scloude1 sts]# kubectl exec -it web-1 -- sh -c "cat /usr/share/nginx/html/index.html" web-1 [root@k8scloude1 sts]# kubectl exec -it web-2 -- sh -c "cat /usr/share/nginx/html/index.html" web-2 手动删除web-1这个pod。
[root@k8scloude1 sts]# kubectl delete pod web-1 pod "web-1" deleted statefulset自动创建了一个一模一样的web-1。
[root@k8scloude1 sts]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES web-0 1/1 Running 0 3h7m 10.244.251.225 k8scloude3 <none> <none> web-1 1/1 Running 0 3s 10.244.251.221 k8scloude3 <none> <none> web-2 1/1 Running 0 3h7m 10.244.251.218 k8scloude3 <none> <none> 5.3 创建无头服务headless service
删除其中一个pod，statefulset很快又会生成一个同名的pod，但是IP地址发生变化，不适合直接使用pod的IP地址访问，使用svc访问更
好，但是创建svc有一定问题，svc具有负载均衡的作用，你访问svc，可能给你后端转发到web-0，也可能后端转发到web-1，后端pod又
都有自己专属的存储，所以svc也不合适，这时就需要无头服务(headless service)了。关于svc的详细内容，请查看博客《Kubernetes(k8s)服务service：service的发现和service的发布》。
现在没有svc。
[root@k8scloude1 sts]# kubectl get svc No resources found in statefulset namespace. 如下是无头服务headless service的yaml文件，功能为：创建一个名为"nginx"的Service，它与具有app: nginx标签的Pod关联。该Service通过暴露在80端口上，并且没有Cluster IP地址。
无头服务headless service和service的区别是：无头服务headless service的 clusterIP为None。
[root@k8scloude1 sts]# cat svc.yaml apiVersion: v1 kind: Service metadata: name: nginx #设置了一个标签app: nginx，与其他相关资源进行关联。 labels: app: nginx spec: ports: #port: 80：将Service的端口设置为80。 - port: 80 #name: web：为该端口指定名称为"web"。 name: web #clusterIP: None：将Service的Cluster IP设置为"None"，表示该Service是一个Headless Service，没有集群内部的虚拟IP地址。 clusterIP: None selector: #app: nginx：设置了一个标签选择器，选择具有app: nginx标签的Pod。 app: nginx 创建无头服务headless service。
[root@k8scloude1 sts]# kubectl apply -f svc.yaml service/nginx created 查看无头服务headless service，CLUSTER-IP为None。
[root@k8scloude1 sts]# kubectl get svc -o wide NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR nginx ClusterIP None <none> 80/TCP 12s app=nginx 5.4 通过无头服务headless service访问StatefulSet
查看pod的标签。
[root@k8scloude1 sts]# kubectl get pod -o wide --show-labels NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS web-0 1/1 Running 0 3h20m 10.244.251.225 k8scloude3 <none> <none> app=nginx,controller-revision-hash=web-748c7c878b,statefulset.kubernetes.io/pod-name=web-0 web-1 1/1 Running 0 13m 10.244.251.221 k8scloude3 <none> <none> app=nginx,controller-revision-hash=web-748c7c878b,statefulset.kubernetes.io/pod-name=web-1 web-2 1/1 Running 0 3h20m 10.244.251.218 k8scloude3 <none> <none> app=nginx,controller-revision-hash=web-748c7c878b,statefulset.kubernetes.io/pod-name=web-2 因为无头服务headless service的CLUSTER-IP为None，所以访问方式为：pod名.svc名 来访问pod，statefulset创建的pod，pod名字是不变的。
[root@k8scloude1 sts]# curl web-0.nginx curl: (6) Could not resolve host: web-0.nginx; 未知的名称或服务 容器外无法访问。
[root@k8scloude1 sts]# curl http://web-0.nginx curl: (6) Could not resolve host: web-0.nginx; 未知的名称或服务 创建一个临时容器podclient作为客户端，来访问pod，--rm表示创建临时容器。
[root@k8scloude1 sts]# kubectl run -it podclient --image=yauritux/busybox-curl:latest --rm --image-pull-policy=IfNotPresent -- sh If you don't see a command prompt, try pressing enter. #访问成功 /home # curl web-0.nginx web-0 /home # curl web-1.nginx web-1 /home # curl web-2.nginx web-2 /home # exit Session ended, resume using 'kubectl attach podclient -c podclient -i -t' command when the pod is running pod "podclient" deleted 可以发现，StatefulSet只适合内部访问，不适合外部访问。
[root@k8scloude1 sts]# kubectl get sts NAME READY AGE web 3/3 3h43m 删除StatefulSet。
[root@k8scloude1 sts]# kubectl delete sts web statefulset.apps "web" deleted [root@k8scloude1 sts]# kubectl get sts No resources found in statefulset namespace. [root@k8scloude1 sts]# kubectl get pod No resources found in statefulset namespace. 六.总结
本文介绍了Kubernetes中的一个重要控制器——StatefulSet，用于管理有状态应用的部署和伸缩。通过为每个Pod分配唯一的标识符和稳定的网络标识，StatefulSet确保了有状态应用的稳定性、可扩展性和数据持久性。相比于无状态应用，有状态应用需要更多的关注持久化存储和有序性启动等问题。
使用StatefulSet可以轻松地部署和管理有状态应用，使其能够充分发挥Kubernetes的优势。通过深入理解StatefulSet的概念和特性，我们可以更好地构建和管理复杂的有状态应用。
