k8s负载资源StatefulSet工作解析

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

在k8s中工作负载资源StatefulSet用于管理有状态应用。

什么是无状态？

组成一个应用的pod是对等的，它们之前没有关联和依赖关系，不依赖外部存储。

即我们上篇小作文中deployment创建的nginx pod ，他们是完全一样的，任何一个pod 被移除后依然可以正常工作。由于不依赖外部存储，它们可以被轻易的调度到任何 node 上。

什么是有状态？

显然无状态的反面就是有状态了，pod之间可能包含主从、主备的相互依赖关系，甚至对启动顺序也有要求。更关键的是这些pod 需要外部存储，一旦pod被清除或调度后，怎么把pod 和原来的外部数据联系起来？这就是StatefulSet厉害的地方。

StatefulSet将这些状态应用进行记录，在需要的时候恢复。

StatefulSet如何展开这些工作?

一、维护应用拓扑状态

通过dns记录为 pod 分配集群内唯一、稳定的网络标识。即只要保证pod 的名称不变，pod被调度到任何节点或者ip如何变更都能被找到。

在 k8s 中Service用来来将一组 Pod 暴露给外界访问的一种机制。当创建的service 中clusterIP为None 时（headless 无头服务），不会进行负载均衡，也不会为该服务分配集群 IP。仅自动配置 DNS。

这样我们集群中的一个pod 将被绑定到一条DNS记录：

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

通过解析这个地址就能找到pod的IP 。

下面我们创建一个headless service，将clusterIP配置为 None：

#headless-service.yml apiVersion: v1 kind: Service metadata: name: nginx-headless spec: ports: - name: nginx-service-port port: 80 targetPort: 9376 clusterIP: None selector: app: nginx

这个service将会绑定 app=nginx标签的pod，我们通过kubectl apply -f headless-service.yml应用service 并通过get 查看：

$ kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 18d nginx-headless ClusterIP None <none> 80/TCP 4h48m

nginx-headless 这个headless service创建成功了。接着我们创建一个StatefulSet：

nginx-statefulset 将会绑定我们前面的service nginx-headless并创建三个nginx pod。

我们查看创建的pod ,StatefulSet 中的每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。同时statefulset创建出来的pod 名称以$(StatefulSet name)-$(order)开始编号。

$ kubectl get pod NAME READY STATUS RESTARTS AGE nginx-statefulset-0 1/1 Running 0 18s nginx-statefulset-1 1/1 Running 0 15s nginx-statefulset-2 1/1 Running 0 12s$ kubectl exec nginx-statefulset-0 -- sh -c hostname nginx-statefulset-0

其实他们的创建顺序也是从0-2，当我们删除这些pod时，statefulset 马上重建出相同名称的Pod 。

我们通过statefulset 的event可以观测到这个过程：

$ kubectl describe nginx-statefulset Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 7m43s statefulset-controller create Pod nginx-statefulset-0 in StatefulSet nginx-statefulset successful Normal SuccessfulCreate 7m40s statefulset-controller create Pod nginx-statefulset-1 in StatefulSet nginx-statefulset successful Normal SuccessfulCreate 7m37s statefulset-controller create Pod nginx-statefulset-2 in StatefulSet nginx-statefulset successful

现在我们来看一下 pod 是否存在于 DNS 记录中：

kubectl run -it --image busybox busybox --rm /bin/sh

运行一个一次性 pod busybox ，接着使用 ping 命令查询之前提到的规则构建名称nginx-statefulset-0.nginx-headless.default.svc.cluster.local

解析的IP与如下nginx-statefulset-0相符。

这样我们使用pod名称通过DNS就可以找到这个pod 再加上StatefulSet可以按顺序创建出不变名称的 pod ，即一个应用通过StatefulSet准确维护其拓扑状态

二、维护应用存储状态

k8s为应对应用的数据存储需求提供了卷的概念（volume）以及提供持久化存储的PVC（ PersistentVolumeClaim）PV（ PersistentVolume）当一个pod 和 PVC绑定后，即使pod 被移除，PVC和PV仍然保留在集群中，pod 再次被创建后会自动绑定到之前的PVC。他们看起来是这样的：

这里我们以讨论statefulset持久化存储为主，对于k8s存储本身不了解的同学可以参考k8s官方文档存储章节storage

首先我们创建存储目录 /data/volumes/ 以及一个本地的local类型（使用节点上的文件或目录来模拟网络附加存储）的PV：

#pv-local.ymlapiVersion: v1 kind: PersistentVolume metadata: name: pv-local spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Delete storageClassName: local-storage local: path: /data/volumes/ nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - minikube

PV是集群中的一块存储，它声明了后端使用的真实存储，通常会由K8S管理员创建。我们在pv-local中声明了后端存储类型为local挂载到目录 /data/volumes/ , 存储卷类名为local-storage，1Gb容量，访问模式ReadWriteMany -- 卷可以被多个个节点以读写方式挂载。亲和的节点为minikube

我们通过get来查看这个PV：

$ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pv-local 5Gi RWX Delete Available local-storage 25m

此时PV的状态为available，还未与任何PVC绑定。我们通过创建PV使集群得到了一块存储资源，但此时还不属于你的应用，我们需要通过PVC去构建一个使用它的”通道“。

#app1-pvc.ymlapiVersion: v1 kind: PersistentVolumeClaim metadata: name: app1-pvc spec: storageClassName: local-storage accessModes: - ReadWriteMany resources: requests: storage: 1Gi

现在我们开辟好一个5Gb容量的存储通道（PVC），此时PV和PVC已通过 storageClassName自动形成绑定。这样PV和PVC的status 皆为Bound

$ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pv-local 5Gi RWX Delete Bound default/app-pvc local-storage 25m$ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE app-pvc Bound pv-local 5Gi RWX local-storage 27m

上面我们创建好通道，接下来要在我们statefuset中绑定这个通道，才能顺利使用存储。

# nginx-statefulset.ymlapiVersion: apps/v1 kind: StatefulSet metadata: name: nginx-statefulset spec: serviceName: "nginx-headless" replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: nodeName: minikube volumes: - name: app-storage persistentVolumeClaim: claimName: app-pvc containers: - name: nginx-web image: nginx:1.17 ports: - containerPort: 80 name: nginx-port volumeMounts: - mountPath: /usr/share/nginx/html name: app-storage

与之前的statefulset相比我们在pod 模板中添加了volume 已经 volumeMounts，这样使用这个statefulset 所创建的pod都将挂载我们前面定义的PVC app-pvc，应用nginx-statefulset.yml后我们进入到pod 检验一下目录是否被正确挂载。

$ kubectl exec -it nginx-statefulset-0 -- /bin/bashroot@nginx-statefulset-0:/# cat /usr/share/nginx/html/index.html hello pv

查看本地目录文件：

root@minikube:/# cat /data/volumes/index.html hello pv

接着我们在pod 中修改index.html内容为并将pod删除，检验重载后的 pod 存储数据是否能被找回。

root@nginx-statefulset-0:/# echo "pod data" > /usr/share/nginx/html/index.html

删除带有标签app=nginx的pod ,由于statefulset的控制器使pod按顺序被重建：

$ kubectl delete pod -l app=nginx pod "nginx-statefulset-0" deleted pod "nginx-statefulset-1" deleted pod "nginx-statefulset-2" deleted$ kubectl get pod NAME READY STATUS RESTARTS AGE nginx-statefulset-0 1/1 Running 0 9s nginx-statefulset-1 1/1 Running 0 6s nginx-statefulset-2 0/1 ContainerCreating 0 3s

毫无疑问，pod 数据完好无损：

$ kubectl exec -it nginx-statefulset-0 -- /bin/bash root@nginx-statefulset-0:/# cat /usr/share/nginx/html/index.html pod data

也就是说虽然我们的pod被删除了，但是PV已经PV依然保留在集群中，当pod 被重建后，它依然会去找定义的claimName: app-pvc这个PVC，接着挂载到容器中。

这里我们一个PVC 绑定了多个节点，其实可以为每一个 statefulset中的pod 创建PVC，可以自行了解。

k8s存储可操作性非常强，这里只在statefulset下做了简单的演示。后续我们会对k8s存储做更深入的了解。

三、总结

这篇小作文我们一起学习了k8s中工作负载资源StatefulSet是如何管理有状态应用的，主要从维护应用拓扑状态和存储状态两个方面做了简单介绍。这样我们对statefulset这个工作资源有了大体了解：StatefulSet 与 Deployment 相比，它为每个管理的 Pod 都进行了编号，使Pod有一个稳定的启动顺序，并且是集群中唯一的网络标识。有了标识后使用PV、PVC对存储状态进行维护。

希望小作文对你有些许帮助，如果内容有误请指正。

您可以随意转载、修改、发布本文，无需经过本人同意。 通过博客阅读：iqsing.github.io