k8s-StatefulSet控制器-十四

1、StatefulSet概述

RC、Deployment、DaemonSet都是面向无状态的服务，它们所管理的Pod的IP、名字，启停顺序等都是随机的，而StatefulSet管理全部有状态的服务，好比MySQL、MongoDB集群等。
StatefulSet所管理的Pod拥有固定的Pod名称，启停顺序，在StatefulSet中，Pod名字称为网络标识(hostname)，还必需要用到共享存储。
在Deployment中，与之对应的服务是service，而在StatefulSet中与之对应的headless service，headless service，即无头服务，与service的区别就是它没有Cluster IP，解析它的名称时将返回该Headless Service对应的所有Pod的Endpoint列表。

　　StatefulSet其应用场景包括：

• 稳定的持久化存储，即Pod从新调度后仍是能访问到相同的持久化数据，基于PVC来实现；
• 稳定的网络标志，即Pod从新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现；
• 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行以前全部以前的Pod必须都是Running和Ready状态），基于init containers来实现；
• 有序收缩，有序删除（即从N-1到0）；

从上面的应用场景能够发现，StatefulSet由如下几个部分组成：

• 用于定义网络标志（DNS domain）的Headless Service
• 用于建立PersistentVolumes的volumeClaimTemplates
• 定义具体应用的StatefulSet

2、组件

　　三个组件：headless service、StatefulSet、volumeClaimTemplate

　　(1)headless service

在deployment中，每个pod是没有名称，是无序的；而statefulset中要求是必须有序的，每个pod的名称必须是固定的。当节点挂了、删了，重建以后的标识符是不变的，每个节点的节点名称是不能改变的。pod名称是做为识别pod的惟一标识符，必须保证其标识符的稳定持久有效；

为了实现标识符的稳定惟一，就须要一个headless service 解析直达后端pod的ip地址，它还会还给每一个pod配置一个惟一的名称。

　　(2)volumeClaimTemplate

大部分有状态副本集都会用到持久存储，可是由于数据是不同的，每一个节点都须要本身专用的存储。在deployment中pod模板中建立的存储卷是一个共享的存储卷，多个pod使用同一个存储卷，而statefulset做为面向有状态的服务，定义中的每个pod都不能使用同一个存储卷，由此基于pod模板建立pod是不适用的，这就须要引入volumeClainTemplate，当在使用statefulset建立pod时，会自动生成一个PVC，从而请求绑定一个PV，从而有本身专用的存储卷。

实验环境：四台主机　　

　　　　192.168.3.100 　　master
　　　　192.168.3.101 　　 node01
　　　　192.168.3.102 　　 node02
　　　　192.168.3.103 　　 store

 

　　

3、statefulSet使用

 　　查看资源定义清单字段：

　　[root@master ~]# kubectl explain statefulset

　　[root@master ~]# kubectl explain statefulset.spec
　　KIND: StatefulSet
　　VERSION: apps/v1

　　RESOURCE: spec <Object>

　　DESCRIPTION:
　　　　Spec defines the desired identities of pods in this set.

　　　　A StatefulSetSpec is the specification of a StatefulSet.

　　FIELDS:

　　　　podManagementPolicy <string> 　　　　#Pod管理策略
　　　　replicas <integer>　　　　　　　　　　 #副本数量
　　　　revisionHistoryLimit <integer> 　　　　   #历史版本限制
　　　　selector <Object> -required- 　　　　     #选择器，必选项
　　　　serviceName <string> -required- 　　　  #服务名称，必选项
　　　　template <Object> -required-　　　　     #模板，必选项
　　　　updateStrategy <Object> 　　　　　　   #更新策略
　　　　volumeClaimTemplates <[]Object> 　　   #存储卷申请模板，列表对象形式

　　一、建立pv

　　先清除以前的pvc、pv、deploy、pod、svc...

　　(1)pv资源定义清单：

　　[root@master volumes]# vim pv-demo.yaml

　　

　　

　　

　　(2)建立

　　[root@master volumes]# kubectl apply -f pv-demo.yaml

 　　

 　　(2)建立stateful

　　(1)资源定义清单

　　[root@master statefulset]# vim stateful-demo.yaml

　　

　　

　　(2)建立

　　[root@master statefulset]# kubectl apply -f stateful-demo.yaml

 　　

　　查看：

　　

　　

　　(3)删除

　　　如今有3个pod,删除的时候是从myapp-2开始进行删除的(2-1-0)，关闭是逆向关闭(0-1-2)；

　　　如今开两个链接，一个删pod，另外一个监控pod状态；

 　　

　　

　　而后，如今开两个链接，一个建立pod，另外一个监控pod状态；

 　　

　　

　　此时PVC不会删除，仍然是存在的，只要仍是同一个statefulset，再从新建立pod时，依旧会从新去绑定原来的pvc；

 　　

　　(3)滚动更新、扩展伸缩、版本升级

　　(1)

 　　这里每个pod的名称都是能够解析的；

　　 解析格式：

　　　　pod_name.service_name.ns_name.cluster.local

　　

　　(2)pod的规模扩展、缩容

　　扩展：顺序；

 　　[root@master statefulset]# kubectl scale sts myapp --replicas=5　　#扩容至5个

 　　[root@master ~]# kubectl get pods -w　　#动态监控pod，可见先建立myapp-3，再建立myapp-4

　　

　　

　　缩容：逆序；

 　　[root@master statefulset]# kubectl patch sts myapp -p '{"spec":{"replicas":2}}'　　#向配置文件打补丁的方式缩容,缩容至2个；

 　　

 　　

　　(3)更新策略和版本升级

　　查看资源定义清单字段：

　　[root@master statefulset]# kubectl explain sts.spec.updateStrategy.rollingUpdate.partition

　　以partition方式进行更新，若是更新值为2，只有myapp编号大于等于2的才会进行更新，实现相似于金丝雀部署方式，partition默认为0；

　　更新时逆序进行；

　　a、从新扩容至5个

　　[root@master statefulset]# kubectl patch sts myapp -p '{"spec":{"replicas":5}}'

　　

　　b、修改更新策略

　　[root@master ~]# kubectl patch sts myapp -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":4}}}}'　　#更新partition大于等于4的；

 　　c、更新版本

　　[root@master ~]# kubectl set image sts/myapp myapp=ikubernetes/myapp:v2

 　　查看：

　　

　　

　　可见，编号大于等于4的已经更新了，小于4的没有更新；

 　　(4)将剩余的其余Pod也更新版本

　　　 只须要将更新策略的partition值改成0便可；

 　　[root@master ~]# kubectl patch sts myapp -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":0}}}}'

 　　

　　可见已经都已经更新；