Kubernetes ---- Pod控制器之StatefulSet
StatefulSet
cattle: 关注群体
pet: 关注个体
特性:
1. 稳定且需要有唯一的网络标识符;
2. 稳定且持久的存储设备;
3. 有序、平滑的部署和扩展;
4. 有序、平滑的终止和删除;
5. 有序的滚动更新;
StatefulSet必备的三个组件：
1. headless Service
2. StatefulSet
3. volumeClaimTemplate
StatefulSet中的headless Service的作用:
StatefulSet控制的服务集群中,启动服务，顺序启动，停止服务，逆序启动;当集群中有Pod要重新启动时,Pod的名称必须要与第一次启动时的Pod的名称一致,Pod名称是作为识别Pod唯一性的标识符(必须稳定、持久、有效)
使用headless Service确保解析的名称是直达后端Pod IP地址的,并确保给每个Pod配置一个唯一的名称;
StatefulSet中的volumeClaimTemplate:
在分布式系统当中,数据分别存储的数据是不一致的,每个节点应该有自己专用的存储卷,创建每一个Pod时会自动生成一个pvc,从而请求绑定一个pv,然后拥有自己单独的存储卷;
创建StatefulSet:
1. 创建pv,pv与pvc内容见博客另一篇文章;
$ vim pv-demo.yaml apiVersion: v1 kind: PersistentVolume metadata: name: pv001 labels: name: pv0001 spec: accessModes: ["ReadWriteOnce","ReadWriteMany"] capacity: storage: 5Gi nfs: path: /data/volumes/v1 server: 192.168.222.103 --- apiVersion: v1 kind: PersistentVolume metadata: name: pv002 labels: name: pv0002 spec: accessModes: ["ReadWriteOnce"] capacity: storage: 5Gi nfs: path: /data/volumes/v2 server: 192.168.222.103 --- apiVersion: v1 kind: PersistentVolume metadata: name: pv003 labels: name: pv0003 spec: accessModes: ["ReadWriteOnce","ReadWriteMany"] capacity: storage: 5Gi nfs: path: /data/volumes/v3 server: 192.168.222.103 --- apiVersion: v1 kind: PersistentVolume metadata: name: pv004 labels: name: pv0004 spec: accessModes: ["ReadWriteOnce","ReadWriteMany"] capacity: storage: 10Gi nfs: path: /data/volumes/v4 server: 192.168.222.103 --- apiVersion: v1 kind: PersistentVolume metadata: name: pv005 labels: name: pv0005 spec: accessModes: ["ReadWriteOnce","ReadWriteMany"] capacity: storage: 10Gi nfs: path: /data/volumes/v5 server: 192.168.222.103
$ kubectl apply -f pv-demo.yaml $ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pv001 5Gi RWO,RWX Retain Available 78m pv002 5Gi RWO Retain Available 78m pv003 5Gi RWO,RWX Retain Available 78m pv004 10Gi RWO,RWX Retain Available 78m pv005 10Gi RWO,RWX Retain Available 78m
2. 创建statefulSet应用
$ vim state-demo.yaml apiVersion: v1 kind: Service metadata: name: myapp namespace: default labels: app: myapp spec: clusterIP: None ports: - name: web port: 80 selector: app: myapp --- apiVersion: apps/v1 kind: StatefulSet metadata: name: myapp namespace: myapp spec: serviceName: myapp replicas: 3 selector: matchLabels: app: myapp-pod template: metadata: labels: app: myapp-pod spec: containers: - name: myapp image: ikubernetes/myapp:v5 imagePullPolicy: IfNotPresent ports: - name: web containerPort: 80 volumeMounts: - name: myappdata mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: myappdata spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: 5Gi $ kubectl apply -f state-demo.yaml
3. 成果
## 下面的三个Pods的名称有规律性的,不像deployment控制器创建出来的随机名称,因为当我们删除其中一个Pod之后,K8s还会创建出来之前那个一样名称的Pod;
$ kubectl get pods NAME READY STATUS RESTARTS AGE myapp-0 1/1 Running 0 44m myapp-1 1/1 Running 0 44m myapp-2 1/1 Running 0 44m
## 下面的myapp就是我们创建的statefulSet类型的控制器
$ kubectl get sts NAME READY AGE myapp 3/3 45m
## 我们发现,当创建Pod的时候,Pod会自动拥有一个pvc,然后这个pvc再去系统上找寻与之规则匹配的pv进行绑定,从而使每个Pod都能单独挂载在某个pvc上,且pvc的名字都隐含了Pod的名字,所以就使得他们能够
持续的为同一个Pod而使用,这就是VolumeClaimTemplates的功能;
$ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE myappdata-myapp-0 Bound pv002 5Gi RWO 51m myappdata-myapp-1 Bound pv003 5Gi RWO,RWX 49m myappdata-myapp-2 Bound pv004 10Gi RWO,RWX 49m
注:
当我们手动删除Pod时,pvc并不会被删除,且Pod的删除顺序是倒序删除的,从2 --> 0逐一删除;
创建时则是正序创建,从0 --> 2;
每一个Pod的名称都可以被解析为IP地址;
pod_name.service_name.ns_name.svc.cluster.local
myapp-0.myapp.default.svc.cluster.local
myapp-1.myapp.default.svc.cluster.local
myapp-2.myapp.default.svc.cluster.local
扩展副本：
# 将副本扩展至5个,k8s会先扩展4,再扩展5. $ kubectl patch -f state-demo.yaml -p '{"spec":{"replicas":5}}' # 查看一下pvc,发现所有pvc都已经被绑定了; $ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE myappdata-myapp-0 Bound pv002 5Gi RWO 69m myappdata-myapp-1 Bound pv003 5Gi RWO,RWX 67m myappdata-myapp-2 Bound pv004 10Gi RWO,RWX 67m myappdata-myapp-3 Bound pv005 10Gi RWO,RWX 2m50s myappdata-myapp-4 Bound pv001 5Gi RWO,RWX 2m36s
缩减副本:
# 将副本再次缩减至3个,监控Pod变化顺序,会先删除4,再删除3,直至副本数量满足要求;
$ kubectl get pods -o wide -w
$ kubectl patch -f state-demo.yaml -p '{"spec":{"replicas":3}}'
myapp-4 1/1 Terminating 0 5m21s 10.244.1.127 node3 <none> <none>
myapp-4 0/1 Terminating 0 5m22s 10.244.1.127 node3 <none> <none>
myapp-4 0/1 Terminating 0 5m28s 10.244.1.127 node3 <none> <none>
myapp-4 0/1 Terminating 0 5m28s 10.244.1.127 node3 <none> <none>
myapp-3 1/1 Terminating 0 5m41s 10.244.2.160 node2 <none> <none>
myapp-3 0/1 Terminating 0 5m44s 10.244.2.160 node2 <none> <none>
myapp-3 0/1 Terminating 0 5m45s 10.244.2.160 node2 <none> <none>
myapp-3 0/1 Terminating 0 5m45s 10.244.2.160 node2 <none> <none>
滚动升级:
金丝雀升级:
自定义更新策略:
sts.spec.updateStrategy.rollingUpdate
partition: N
意味着>=N的Pod会被更新
partition: 2
myapp-0 不会更新
myapp-1 不会更新
myapp-2 会更新
演示:
# 将partition设为4,那么Pod中大于等于4的Pod才会更新;
$ kubectl patch sts/myapp -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":4}}}}'
# 更换镜像
$ kubectl set image sts/myapp myapp=ikubernetes/myapp:v2
# 验证,发现只有myapp-4的镜像变化了;
$ kubectl describe pod myapp-4
....
10.244.1.129
....
$ kubectl describe pod myapp-0
....
Image: ikubernetes/myapp:v5
....
正式升级:
当发现金丝雀升级后的其中一个Pod运行没有任何异常的状况,可以将所有Pod都升级,监控升级过程,发现是从大到小进行升级的;
$ kubectl get pods -o wide -w $ kubectl patch sts/myapp -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":0}}}}' # 所有的Pod的镜像都已经改变了 $ kubectl describe pod myapp-0 ....
Image: ikubernetes/myapp:v2
....
