怎么在Kubernetes中管理有狀態(tài)應(yīng)用

本篇內(nèi)容主要講解“怎么在Kubernetes中管理有狀態(tài)應(yīng)用”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“怎么在Kubernetes中管理有狀態(tài)應(yīng)用”吧!

在Kubernetes中，StatefulSet被用來管理有狀態(tài)應(yīng)用的API對象。StatefulSets在Kubernetes 1.9版本才穩(wěn)定。StatefulSet管理Pod部署和擴(kuò)容，并為這些Pod提供順序和唯一性的保證。與Deployment相似的地方是，StatefulSet基于spec規(guī)格管理Pod；與Deployment不同的地方是，StatefulSet需要維護(hù)每一個(gè)Pod的唯一身份標(biāo)識。這些Pod基于同樣的spec創(chuàng)建，但互相之間不能替換，每一個(gè)Pod都保留自己的持久化標(biāo)識。

1、使用StatefulSet的場景

對于下面的應(yīng)用場景，StatefulSets是有價(jià)值的：

• 穩(wěn)定、唯一的網(wǎng)絡(luò)標(biāo)識

• 穩(wěn)定、持久的存儲(chǔ)

• 按照順序、優(yōu)雅的部署和擴(kuò)容

• 按照順序、優(yōu)雅的刪除和終止

• 按照順序、自動(dòng)滾動(dòng)更新

上述的穩(wěn)定是持久的同義詞，如果應(yīng)用不需要穩(wěn)定的標(biāo)識或者順序的部署、刪除、擴(kuò)容，則應(yīng)該使用無狀態(tài)的副本集。Deployment或者ReplicaSet的控制器更加適合無狀態(tài)業(yè)務(wù)場景。

2、StatefulSet的限制

• 在Kubernetes 1.9版本之前是beta版本，在Kubernetes 1.5版本之前是不提供的。

• Pod存儲(chǔ)由PersistentVolume（storage類或者管理員預(yù)先創(chuàng)建）提供。

• 刪除或者縮容StatefulSet不會(huì)刪除與StatefulSet關(guān)聯(lián)的數(shù)據(jù)卷，這樣能夠保證數(shù)據(jù)的安全性。

• 當(dāng)前的StatefulSets需要一個(gè)Headless服務(wù)來為Pod提供網(wǎng)絡(luò)標(biāo)識，此Headless服務(wù)需要通過手工創(chuàng)建。

3、組件

下面是一個(gè)StatefuleSet組成的示例：

• 一個(gè)名稱為nginx的Headless服務(wù)，用來控制網(wǎng)絡(luò)域。

• 一個(gè)名稱為web的statefulSet，它擁有nginx容器（在唯一的Pod啟動(dòng)）的3個(gè)副本集。

• 使用PersistenVolumes（由PersistentVolume Provisioner提供）提供穩(wěn)定存儲(chǔ)的volumeClaimTemplates。

apiVersion:v1

kind:Service

metadata:

  name:nginx

  labels:

     app:nginx

spec:

  ports:

  -port:80

     name:web

  clusterIP:None //Headless服務(wù)

  selector:

     app:nginx

---

apiVersion:apps/v1

kind:StatefulSet

metadata:

  name:web

spec:

  selector:

     matchLabels:

       app:nginx# has to match .spec.template.metadata.labels

  serviceName:"nginx"

  replicas:3 # by default is 1

  template:

     metadata:

       labels:

         app:nginx # has to match .spec.selector.matchLabels

     spec:

       terminationGracePeriodSeconds:10

       containers:

       -name:nginx

         image:k8s.gcr.io/nginx-slim:0.8

         ports:

         -containerPort:80

           name:web

         volumeMounts: #掛接數(shù)據(jù)卷

         -name:www

           mountPath:/usr/share/nginx/html #掛接路徑為容器的/usr/share/nginx/html

  volumeClaimTemplates: #數(shù)據(jù)卷生命模板

  -metadata:

       name:www

     spec:

       accessModes:["ReadWriteOnce"]

       storageClassName:my-storage-class

       resources:

         requests:

           storage:1Gi

4、Pod選擇器

必須設(shè)置StatefulSet的sepc.selector，以匹配.spec.template.metadata.labels。在Kubernetes 1.8之前，spec.selector是可以忽略的，它被設(shè)置一個(gè)默認(rèn)值。在1.8或者后續(xù)的版本，如果不設(shè)置sepc.selector，則會(huì)導(dǎo)致創(chuàng)建StatefulSet失敗。

5、Pod身份標(biāo)識

StatfuleSet Pod擁有一個(gè)唯一的身份標(biāo)識，它由順序、穩(wěn)定的網(wǎng)絡(luò)標(biāo)識和穩(wěn)定的存儲(chǔ)所組成。此身份標(biāo)識一直跟隨著Pod，不過它被調(diào)度到那個(gè)Node上。

5.1 序數(shù)索引（Ordinal Index）

對于擁有N個(gè)副本集的StatefulSet，在StatefulSet中的每一個(gè)Pod都會(huì)被指派一個(gè)整型的序數(shù)，此序數(shù)在0和N之間，在整個(gè)集合中是唯一的。

5.2 網(wǎng)絡(luò)ID(Stable Network ID)

在StatefulSet中，每一個(gè)Pod的主機(jī)名稱都由StatefulSet的名稱和序數(shù)所組成。Pod的主機(jī)名稱的格式：$(statefulset name)-$(ordinal)。如果創(chuàng)建了三個(gè)Pod，這他們的主機(jī)名稱為web-0，web-1，web-2。StatefulSet能夠使用Headless服務(wù)來控制Pod的域。Service管理的域的格式為：$(service name).$(namespace).svc.cluster.local，cluster.local是集群域。對于每一個(gè)被創(chuàng)建的Pod，它將得到一個(gè)DNS子域，格式為： $(podname).$(governing service domain)，這里的管理服務(wù)在StatefulSet中，通過serviceName設(shè)置。

下面是StatefulSet中Pod在DNS中的名稱：

5.3 穩(wěn)定的存儲(chǔ)

kubernetes為每一個(gè)VolumeClaimTemplate創(chuàng)建一個(gè)對應(yīng)的PersistentVolume。在前面的nginx實(shí)例中，每一個(gè)Pod將會(huì)my-storage-class存儲(chǔ)類型的PersistenVolume單一實(shí)例和1Gib的存儲(chǔ)空間。

如果沒有指定存儲(chǔ)類，則會(huì)使用默認(rèn)的存儲(chǔ)。但一個(gè)Pod被調(diào)度到Node上，它的volumeMounts將會(huì)掛接PersistentVolumes，并將其與PersistentVolumeClaims進(jìn)行關(guān)聯(lián)。需要注意的是，即使在Pod被刪除，PersistentVolumes與PersistentVolumeClaims之間的關(guān)聯(lián)關(guān)系也不會(huì)被刪除。

5.4 Pod命名標(biāo)簽

當(dāng)StatefulSet控制器創(chuàng)建了Pod，它將會(huì)添加一個(gè)標(biāo)簽，為此Pod名稱的集合。此標(biāo)簽將能夠管理服務(wù)到指定的Pod。

6、部署和擴(kuò)容保證

• 對于一個(gè)帶有N個(gè)副本集的StatefulSet，當(dāng)Pod被部署，它們將按0到N-1的順序被創(chuàng)建。

• 當(dāng)一Pod被刪除時(shí)，它們將按照N-1到0的倒序被終止。

• 在進(jìn)行Pod擴(kuò)容前，所有依賴的Pod應(yīng)該都已在運(yùn)行和準(zhǔn)備好。

• 在Pod被終止前，所有的依賴它的Pod都必須完全停止。

在前文創(chuàng)建的nginx例子中，將按照順序部署web-0,web-1和web-2。web-1只能在web-0運(yùn)行和準(zhǔn)備好以后才能夠被部署，web-2只能在web-1運(yùn)行和準(zhǔn)備好以后才能夠被部署。如果web-0失敗，就算web-1正在運(yùn)行，web-2也是不能正常啟動(dòng)的，除非web-0被重啟，并正常運(yùn)行。

如果縮容上述例子，設(shè)置replicas=1，則web-2首先被終止，接著是web-1。如果在web-2被終止后，但在web-1被終止前，web-0失敗了，web-1將不能被終止，除非web-0處于正常運(yùn)行狀態(tài)。

6.1 Pod管理策略

在Kubernetes 1.7以后，StatefulSet的唯一性標(biāo)識可以通過.spec.podManagementPolicy的值進(jìn)行保證。

6.1.1 OrderedReady Pod管理

OrderedReady pod管理是StatefulSets默認(rèn)的管理模式，此模式安裝順序啟動(dòng)或者終止Pod。

6.1.2 并行Pod管理

并行Pod管理告訴StatefulSet控制器以并行的方式啟動(dòng)或者終止所有的Pod。

7、更新策略

在Kubernetes 1.7之后，運(yùn)行通過配置StatefulSet的.spec.updateStrategy，實(shí)現(xiàn)Pod的容器、標(biāo)簽、資源請求/限制和注釋自動(dòng)更新。

7.1 On Delete策略

OnDelete更新策略是1.6之前版本的行為。當(dāng)StatefulSet的.spec.updateStrategy.type被設(shè)置為OnDelete，則StatefulSet控制器將不會(huì)知道更新Pod。

7.2 Rolling Updates策略

RollingUpdate更新策略將實(shí)現(xiàn)StatefulSet中Pod的自動(dòng)滾動(dòng)更新，這是StatefulSet的默認(rèn)更新模式。如果.spec.updateStrategy.type設(shè)置為 RollingUpdate，則StatefulSet控制器將會(huì)刪除和重建StatefulSet中的每一Pod。它將會(huì)按照從最大到最小的序數(shù)終止Pod，并按照從小到大順序重建Pod。

7.3 Partitions

RollingUpdate更新策略能夠通過指定.spec.updateStrategy.rollingUpdate.partition進(jìn)行分隔。當(dāng)分隔被指定，所有序數(shù)大于或等于分隔的Pod將會(huì)被更新，其它的Pod將被不會(huì)進(jìn)行更新。在大部分的情況下，不會(huì)使用分隔；當(dāng)希望進(jìn)行金絲雀發(fā)布，或者執(zhí)行階段發(fā)布時(shí)，分隔是很有用的。

到此，相信大家對“怎么在Kubernetes中管理有狀態(tài)應(yīng)用”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！