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}}}}'

 　　

　　可見已經都已經更新；