StatefulSet控制器

StatefulSet控制器

生产中常用的副本控制器如Deployment、DaemonSet、RS都是适用于无状态服务，其所管理的Pod的启停顺序、IP、Pod名称等都是随机的，被管理的Pod被更新时，这些都会变化。

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

注意：无状态服务同样可以使用statfulset控制器

1. 有状态服务和无状态服务区别：

有状态服务与无状态服务主要区别:

是指两个来自相同发起者(客户端)的请求在服务器端是否具备上下文关系；

指服务器端保存与客户端请求的相关信息，每个请求可以默认地使用之前的请求信息；

指服务器端所能够处理的过程全部来自于客户端请求所携带的信息；每一个请求都像首次执行一样，不会依赖之前的数据。

1. StatefulSet控制器作用及特点

主要用来管理有状态应用的控制器

用来管理某Pod集合的部署和扩缩，并为这些 Pod 提供持久存储和持久标识符。

1. 提供稳定的、唯一的网络标识符。 # 通过headless服务实现

StatefulSet管理的Pod拥有固定的Pod名称

一般是pod.name-0/-1/-2顺延，启停顺序从-0开始依次重启

1. 提供稳定、持久的数据存储。   # 通过storageclass（PV动态供给）实现

1. 有序的、优雅的部署和缩放。

1. 有序的滚动更新（一般由名称编号大到小的顺序）。

回顾：Service类型：

•ClusterIP

–默认，分为普通ClusterIP和headlessCluseterIP

普通ClusterIP：分配一个集群内部可以访问的虚拟IP

Headless：不分配虚拟IP，通过

•NodePort

•LoadBalancer

•ExternalName

一个完整的StatefulSet应用由三个部分组成： 

headless service、StatefulSet controller、volumeClaimTemplate。

1. 部署statefulset应用

一个完整的StatefulSet应用由三个部分组成： 

headless service、StatefulSet controller、volumeClaimTemplate。

运行有状态的服务，前提要创建好storageclass。

具体实现参考前面章节

验证：

[root@k8s-1 ~]# kubectl get sc

    

# 为什么用 headless service 无头服务？

在用Deployment时，每一个Pod名称是没有顺序的，是随机字符串，因此是Pod名称是无序的，但是在statefulset中要求必须是有序 ，每一个pod不能被随意取代，pod重建后pod名称还是一样的。

在有状态服务中，pod名称是pod唯一性的标识符，必须持久稳定有效。无头服务可以实现每个Pod一个唯一的名称 。

对于有状态的副本集都会用到持久存储，特别是对于分布式系统来讲，它的最大特点是数据是不一样的，所以各个节点不能使用同一存储卷，每个节点有自已的专用存储，

statefulSet使用volumeClaimTemplate，称为卷申请模板，它会为每个Pod生成不同的pvc，并绑定pv，从而实现各pod有专用存储。

示例：

[root@k8s-1 ~]# vim statefulset.yaml

apiVersion: v1

kind: Service

metadata:

  name: 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:1.20

        imagePullPolicy: IfNotPresent

        volumeMounts:

        - name: test-storage

          mountPath: /usr/share/nginx/html

  volumeClaimTemplates:

  - metadata:

      name: test-storage

      annotations:          #注解

        volume.beta.kubernetes.io/storage-class: nfs-client  #关联前面存储类名字

    spec:

      accessModes:    #这几行内容，相当于把创建pvc的动作合并到这里

        - ReadWriteOnce

      resources:

        requests:

          storage: 100Mi

[root@k8s-1 ~]# kubectl apply -f statefulset.yaml

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

[root@k8s-1 statefulSet]# kubectl get pv,pvc

    

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

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

[root@k8s-1 ~]# kubectl get pod

    

[root@nfs ~]# echo 0000 > /data/nfs/default-test-storage-statefulset-0-pvc-9d68f310-b3f6-4295-9100-5822ef177514/testfile

[root@nfs ~]# echo 1111 > /data/nfs/default-test-storage-statefulset-1-pvc-a5230fda-ebde-4ffd-a129-42ac1fbf4a76/testfile

[root@nfs ~]# echo 2222 > /data/nfs/default-test-storage-statefulset-2-pvc-e24d299f-56a0-4f58-ae91-63fda0dad50c/testfile

    

    

//查看对应Pod的数据持久化目录，可以看出，每个Pod的内容都不一样。

[root@k8s-1 ~]# kubectl exec -it statefulset-0 --  cat /usr/share/nginx/html/testfile

00000

[root@k8s-1 ~]# kubectl exec -it statefulset-1 --  cat /usr/share/nginx/html/testfile

111111

[root@k8s-1 ~]# kubectl exec -it statefulset-2 --  cat /usr/share/nginx/html/testfile

2222

    

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

[root@k8s-1 ~]# kubectl delete pod statefulset-2 

pod "statefulset-2" deleted

    

    

[root@k8s-1 ~]# kubectl get pod

    

[root@k8s-1 ~]# kubectl exec statefulset-2 -- cat /usr/share/nginx/html/testfile

    

[root@k8s-1 ~]# kubectl get svc -n kube-system

    

yum -y install bind-utils

   

nameserver 10.96.0.10

   

[root@k8s-1 ~]# curl http://headless-svc.default.svc.cluster.local./testfile