溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇文章給大家分享的是有關怎樣淺析Kubernetes StatefulSet，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。
“Deployment用于部署無狀態服務，StatefulSet用來部署有狀態服務”。
具體的，什么場景需要使用StatefulSet呢？官方給出的建議是，如果你部署的應用滿足以下一個或多個部署需求，則建議使用StatefulSet。
穩定的、唯一的網絡標識。
穩定的、持久的存儲。
有序的、優雅的部署和伸縮。
有序的、優雅的刪除和停止。
有序的、自動的滾動更新。
穩定的主要是針對Pod發生re-schedule后仍然要保持之前的網絡標識和持久化存儲。這里所說的網絡標識包括hostname、集群內DNS中該Pod對應的A Record，并不能保證Pod re-schedule之后IP不變。要想保持Pod IP不變，我們可以借助穩定的Pod hostname定制IPAM獲取固定的Pod IP。借助StatefulSet的
穩定的唯一的網絡標識特性，我們能比較輕松的實現Pod的固定IP需求，然后如果使用Deployment，那么將會復雜的多，你需要考慮滾動更新的過程中的參數控制(maxSurge、maxUnavailable)、每個應用的IP池預留造成的IP浪費等等問題。
因此，我想再加一個StatefulSet的使用場景：
實現固定的Pod IP方案, 可以優先考慮基于StatefulSet；
StatefulSet對應Pod的存儲最好通過StorageClass來動態創建：每個Pod都會根據StatefulSet中定義的VolumeClaimTemplate來創建一個對應的PVC，然后PVS通過StorageClass自動創建對應的PV，并掛載給Pod。所以這種方式，需要你事先創建好對應的StorageClass。當然，你也可以通過預先由管理員手動創建好對應的PV，只要能保證自動創建的PVC能和這些PV匹配上。
為了數據安全，當刪除StatefulSet中Pods或者對StatefulSet進行縮容時，Kubernetes并不會自動刪除StatefulSet對應的PV，而且這些PV默認也不能被其他PVC Bound。當你確認數據無用之后再手動去刪除PV的時候，數據是否刪除取決于PV的ReclaimPolicy配置。Reclaim Policy支持以下三種:
目前只有NFS和HostPath支持Recycle;
EBS,GCE PD, Azure Disk，Openstack Cinder支持Delete。
Retain，意味著需要你手動清理；
Recycle，等同于rm -rf /thevolume/*
Delete，默認值，依賴于后端的存儲系統自己實現。
注意：
請小心刪除StatefulSet對應的PVC，首先確保Pods已經完全Terminate，然后確定不需要Volume中的數據后，再考慮刪除PV。因為刪除PVC可能觸發對應PV的自動刪除，并根據StorageClass中的recalimPolicy配置可能造成volume中的數據丟失。
因為部署的是有狀態應用，我們需要自己創建對應的Headless Service，注意Label要和StatefulSet中Pods的Label匹配。Kubernetes會為該Headless Service創建對應SRV Records，包含所有的后端Pods，KubeDNS會通過Round Robin算法進行選擇。
在Kubernetes 1.8+中，你必須保證StatefulSet的spec.selector能匹配.spec.template.metadata.labels，否則會導致StatefulSet創建失敗。在Kubernetes 1.8之前，StatefulSet的spec.selector如果沒指定則默認會等同于.spec.template.metadata.labels。
對StatefulSet進行縮容前，你需要確認對應的Pods都是Ready的，否則即使你觸發了縮容操作，Kubernetes也不會真的進行縮容操作。
StatefulSet中反復強調的“穩定的網絡標識”，主要指Pods的hostname以及對應的DNS Records。
HostName：StatefulSet的Pods的hostname按照這種格式生成：$(statefulset name)-$(ordinal)， ordinal從0 ~ N-1(N為期望副本數)。
StatefulSet Controller在創建pods時，會給pod加上一個pod name label：statefulset.kubernetes.io/pod-name, 然后設置到Pod的pod name和hostname中。
pod name label有啥用呢？我們可以創建獨立的Service匹配到這個指定的pod，然后方便我們單獨對這個pod進行debug等處理。
DNS Records：
Headless Service的DNS解析：$(service name).$(namespace).svc.cluster.local 通過DNS RR解析到后端其中一個Pod。SRV Records只包含對應的Running and Ready的Pods，不Ready的Pods不會在對應的SRV Records中。
Pod的DNS解析：$(hostname).$(service name).$(namespace).svc.cluster.local解析到對應hostname的Pod。
每個Pod對應一個PVC，PVC的名稱是這樣組成的:$(volumeClaimTemplates.name)-$(pod's hostname),跟對應的Pod是一一對應的。
當Pod發生re-schedule（其實是recreate）后，它所對應的PVC所Bound的PV仍然會自動的掛載到新的Pod中。
Kubernetes會按照VolumeClaimTemplate創建N(N為期望副本數)個PVC，由PVCs根據指定的StorageClass自動創建PVs。
當通過級聯刪除StatefulSet時并不會自動刪除對應的PVCs，所以PVC需要手動刪除。
當通過級聯刪除StatefulSet或者直接刪除對應Pods時，對應的PVs并不會自動刪除。需要你手動的去刪除PV。
當部署有N個副本的StatefulSet應用時，嚴格按照index從0到N-1的遞增順序創建，下一個Pod創建必須是前一個Pod Ready為前提。
當刪除有N個副本的StatefulSet應用時，嚴格按照index從N-1到0的遞減順序刪除，下一個Pod刪除必須是前一個Pod shutdown并完全刪除為前提。
當擴容StatefulSet應用時，每新增一個Pod必須是前一個Pod Ready為前提。
當縮容StatefulSet應用時，沒刪除一個Pod必須是前一個Pod shutdown并成功刪除為前提。
注意StatefulSet的pod.Spec.TerminationGracePeriodSeconds不要設置為0。
正常情況下，StatefulSet Controller會保證集群內同一namespace下不會出現多個相同network identity的StatefulSet Pods。
如果集群內出現以上情況，那么有可能導致該有狀態應用不能正常工作、甚至出現數據丟失等致命問題。
那么什么情況下會導致出現同一namespace下會出現多個相同network identity的StatefulSet Pods呢？我們考慮下Node出現網絡Unreachable的情況：
如果你使用Kubernetes 1.5之前的版本，當Node Condition是NetworkUnavailable時，node controller會強制從apiserver中刪除這個Node上的這些pods對象，這時StatefulSet Controller就會自動在其他Ready Nodes上recreate同identity的Pods。這樣做其實風險是很大的，可能會導致有一段時間有多個相同network identity的StatefulSet Pods，可能會導致該有狀態應用不能正常工作。所以盡量不要在Kubernetes 1.5之前的版本中使用StatefulSet，或者你明確知道這個風險并且無視它。
如果你使用Kubernetes 1.5+的版本，當Node Condition是NetworkUnavailable時，node controller不會強制從apiserver中刪除這個Node上的這些pods對象，這些pods的state在apiserver中被標記為Terminating或者Unknown，因此StatefulSet Controller并不會在其他Node上再recreate同identity的Pods。當你確定了這個Node上的StatefulSet Pods shutdown或者無法和該StatefulSet的其他Pods網絡不同時，接下來就需要強制刪除apiserver中這些unreachable pods object，然后StatefulSet Controller就能在其他Ready Nodes上recreate同identity的Pods，使得StatefulSet繼續健康工作。
那么在Kubernetes 1.5+中，如何強制從apiserver中刪除該StatefulSet pods呢？有如下三種方法：
如果Node永久的無法連接網絡或者關機了，意味著能確定這個Node上的Pods無法與其他Pods通信了，不會對StatefulSet應用的可用性造成影響，那么建議手動從apiserver中刪除該NetworkUnavailable的Node，Kubernetes會自動從apiserver中刪除它上面的Pods object。
如果Node是因為集群網絡腦裂導致的，則建議去檢查網絡問題并成功恢復，因為Pods state已經是Terminating或者Unkown,所以kubelet從apiserver中獲取到這個信息后就會自動刪除這些Pods。
其他情況才考慮直接手動從apiserver中刪除這些Pods，因為這時你無法確定對應的Pods是否已經shutdown或者對StatefulSet應用無影響，強制刪除后就可能導致出現同一namespace下有多個相同network identity的StatefulSet Pods，所以盡量不要使用這種方法。
kubectl delete pods <pod> --grace-period=0 --force
小知識：當前Node Condition有以下6種：
| Node Condition | Description |
|---|---|
| OutOfDisk | True if there is insufficient free space on the node for adding new pods, otherwise False |
| Ready | True if the node is healthy and ready to accept pods, False if the node is not healthy and is not accepting pods, and Unknown if the node controller has not heard from the node in the last 40 seconds |
| MemoryPressure | True if pressure exists on the node memory – that is, if the node memory is low; otherwise False |
| DiskPressure | True if pressure exists on the disk size – that is, if the disk capacity is low; otherwise False |
| NetworkUnavailable | True if the network for the node is not correctly configured, otherwise False |
| ConfigOK | True if the kubelet is correctly configured, otherwise False |
Kubernetes 1.7+，StatefulSet開始支持Pod Management Policy配置，提供以下兩種配置：
OrderedReady，StatefulSet的Pod默認管理策略，就是逐個的、順序的進行部署、刪除、伸縮，也是默認的策略。
Parallel，支持并行創建或者刪除同一個StatefulSet下面的所有Pods，并不會逐個的、順序的等待前一個操作確保成功后才進行下一個Pod的處理。其實用這種管理策略的場景非常少。
StatefulSet的更新策略（由.spec.updateStrategy.type指定）支持以下兩種：
OnDelete, 含義同Deployment的OnDelete策略，大家應該很熟悉了，不多介紹。
RollingUpdate，滾動更新過程也跟Deployment大致相同，區別在于：
所有ordinal大于等于partition指定的值的Pods將會進行滾動更新。
所有ordinal小于partition指定的值得Pods將保持不變。即使這些Pods被recreate，也會按照原來的pod template創建，并不會更新到最新的版本。
特殊地，如果partition的值大于StatefulSet的期望副本數N，那么將不會觸發任何Pods的滾動更新。
相當于Deployment的maxSurge=0，maxUnavailable=1（其實StatefulSet是不存在這兩個配置的）
滾動更新的過程是有序的（逆序），index從N-1到0逐個依次進行，并且下一個Pod創建必須是前一個Pod Ready為前提，下一個Pod刪除必須是前一個Pod shutdown并完全刪除為前提。
支持部分實例滾動更新，部分不更新，通過.spec.updateStrategy.rollingUpdate.partition來指定一個index分界點。
以上就是怎樣淺析Kubernetes StatefulSet，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
