1. 程式人生 > >圖解kubernetes控制器StatefulSet核心實現原理

圖解kubernetes控制器StatefulSet核心實現原理

StatefulSet是k8s中有狀態應用管理的標準實現,今天就一起來了解下其背後設計的場景與原理,從而瞭解其適用範圍與場景 # 1. 基礎概念 首先介紹有狀態應用裡面的需要考慮的一些基礎的事情,然後在下一章我們再去看statefulSet的關鍵實現 ## 1.1 有狀態與無狀態 ![image.png](https://img2020.cnblogs.com/other/1506724/202003/1506724-20200329110412252-1990045930.png) 在日常開發的應用中,通常可以分為兩大類:有狀態與無狀態,比如web服務通常都是無狀態的,web應用資料主要來自後端儲存、快取等中介軟體,而本身並不儲存數; 而諸如redis、es等其資料也是應用自身的一部分,由此可以看出有狀態應用本身會包含兩部分:應用與資料 ## 1.2 一致性與資料 ![image.png](https://img2020.cnblogs.com/other/1506724/202003/1506724-20200329110412429-1770354421.png) 一致性是分散式系統中很常見的問題,上面提到有狀態應用包含資料部分,那資料和一致性是不是一個東西呢?答案是並不一定,在諸如zookeeper等應用中,會通過zab協議保證資料寫入到叢集中的大多數節點, 而在諸如kafka之類的應用其一致性設計要求相對較低,由此可以看出有狀態應用資料的一致性,更多的是由對應場景的系統設計而決定 ## 1.3 身份標識 在一些應用中身份標識是系統本身組成的一部分,比如zookeeper其通過server的id來影響最終的zab協議的選舉,在kafka中分割槽的分配時也是按照對應的id來分配的 ## 1.4 單調有序更新 ![image.png](https://img2020.cnblogs.com/other/1506724/202003/1506724-20200329110412679-2060359698.png) 通常分散式系統中都至少要保證分割槽容忍性,以防止部分節點故障導致整個系統不可用,在k8s中的statefulset中的 Pod的管理策略則是保證儘可能安全的逐個Pod更新,而不是並行啟動或停止所有的Pod ## 1.5 擴縮容與故障轉移 在k8s中水平方向上的擴容和縮容都非常簡單,刪除和新增一個Pod的事情,但是對於有狀態應用,其實就不知這些,比如擴容後的資料如何做平衡,節點失敗後的故障轉移怎麼做,這些都是要一個有狀態應用需要自己考慮的事情 # 2. 核心實現 StatefulSet的實現機制整體流程相對簡明,接下來按照Pod管理、狀態計算、狀態管理、更新策略這幾部分來依次講解 ## 2.1 Pod的release與adopt statefulSet中的pod的名字都是按照一定規律來進行設定的, 名字本身也有含義, k8s在進行statefulset更新的時候,首先會過濾屬於當前statefulset的pod,並做如下操作 ![image.png](https://img2020.cnblogs.com/other/1506724/202003/1506724-20200329110412847-452418260.png) K8s中控制器與Pod的關聯主要通過兩個部分:controllerRef和label, statefulset在進行Pod過濾的時候,如果發現對應的pod的controllerRef都是當前的statefulset但是其label或者名字並不匹配,則就會嘗試release對應的Pod 反之如果發現對應Pod的label和名字都匹配,但是controllerRef並不是當前的statefulSet就會更新對應的controllerRef為當前的statefulset, 這個操作被稱為adopt 通過該流程可以確保當前statefulset關聯的Pod要麼與當前的物件關聯,要麼我就釋放你,這樣可以維護Pod的一致性,即時有人修改了對應的Pod則也會調整成最終一致性 ## 2.2 副本分類 ![image.png](https://img2020.cnblogs.com/other/1506724/202003/1506724-20200329110413207-1915692348.png) 在經過第一步的Pod狀態的修正之後,statefulset會遍歷所有屬於自己的Pod,同時將Pod分為兩個大類:有效副本和無效副本(condemned),前面提到過Pod的名字也是有序的即有N個副本的Pod則名字依次是{0...N-1}, 這裡區分有效和無效也是依據對應的索引順序,如果超過當前的副本即為無效副本 ## 2.3 單調更新 單調更新主要是指的當對應的Pod管理策略不是並行管理的時候,只要當前Replicas(有效副本)中任一一個Pod發生建立、終止、未就緒的時候,都會等待對應的Pod就緒,即你要想更新一個statefulset的Pod的時候,對應的Pod必須已經RunningAndReady ```go func allowsBurst(set *apps.StatefulSet) bool { return set.Spec.PodManagementPolicy == apps.ParallelPodManagement } ``` ## 2.4 基於計數器的滾動更新 ![image.png](https://img2020.cnblogs.com/other/1506724/202003/1506724-20200329110413382-1792145673.png) 滾動更新的實現相對隱晦一點,其主要是通過控制副本計數來實現,首先倒序檢查對應的Pod的版本是否是最新版本,如果發現不是,則直接刪除對應的Pod,同時將currentReplica計數減一,這樣在檢查對應的Pod的時候,就會發現對應的Pod的不存在,就需要為對應的Pod生成新的Pod資訊,此時就會使用最新的副本去更新 ```go func newVersionedStatefulSetPod(currentSet, updateSet *apps.StatefulSet, currentRevision, updateRevision string, ordinal int) *v1.Pod { // 如果發現當前的Pod的索引小於當的副本計數,則表明當前Pod還沒更新到,但實際上可能因為別的原因 // 需要重新生成Pod模板,此時仍然使用舊的副本配置 if currentSet.Spec.UpdateStrategy.Type == apps.RollingUpdateStatefulSetStrategyType && (currentSet.Spec.UpdateStrategy.RollingUpdate == nil && ordinal < int(currentSet.Status.CurrentReplicas)) || (currentSet.Spec.UpdateStrategy.RollingUpdate != nil && ordinal < int(*currentSet.Spec.UpdateStrategy.RollingUpdate.Partition)) { pod := newStatefulSetPod(currentSet, ordinal) setPodRevision(pod, currentRevision) return pod } // 使用新的配置生成新的Pod配置 pod := newStatefulSetPod(updateSet, ordinal) setPodRevision(pod, updateRevision) return pod } ``` ## 2.5 無效副本的清理 無效副本的清理應該主要是發生在對應的statefulset縮容的時候,如果發現對應的副本已經被遺棄,就會直接刪除,此處預設也需要遵循單調性原則,即每次都只更新一個副本 ## 2.6 基於刪除的單調性更新 ```go if getPodRevision(replicas[target]) != updateRevision.Name && !isTerminating(replicas[target]) { klog.V(2).Infof("StatefulSet %s/%s terminating Pod %s for update", set.Namespace, set.Name, replicas[target].Name) err := ssc.podControl.DeleteStatefulPod(set, replicas[target]) status.CurrentReplicas-- return &status, err } ``` Pod的版本檢測位於對應一致性同步的最後,當代碼走到當前位置,則證明當前的statefulSet在滿足單調性的情況下,有效副本里面的所有Pod都是RunningAndReady狀態了,此時就開始倒序進行版本檢查,如果發現版本不一致,就根據當前的partition的數量來決定允許並行更新的數量,在這裡刪除後,就會觸發對應的事件,從而觸發下一個排程事件,觸發下一輪一致性檢查 ## 2.7 OnDelete策略 ```go if set.Spec.UpdateStrategy.Type == apps.OnDeleteStatefulSetStrategyType { return &status, nil } ``` StatefulSet的更新策略除了RollingUpdate還有一種即OnDelete即必須人工刪除對應的 Pod來觸發一致性檢查,所以針對那些如果想只更新指定索引的statefulset可以嘗試該策略,每次只刪除對應的索引,這樣只有指定的索引會更新為最新的版本 ## 2.8 狀態儲存 狀態儲存其實就是我們常說的PVC,在Pod建立和更新的時候,如果發現對應的PVC的不存在則就會根據statefulset裡面的配置建立對應的PVC,並更新對應Pod的配置 # 3. 有狀態應用總結 從核心實現分析中可以看出來,有狀態應用的實現,實際上核心是基於一致性狀態、單調更新、持久化儲存的組合,通過一致性狀態、單調性更新,保證期望副本的數量的Pod處於RunningAndReady的狀態並且保證有序性,同時通過持久化儲存來進行資料的儲存 ![image.png](https://img2020.cnblogs.com/other/1506724/202003/1506724-20200329110413598-2120529199.png) 有序的重要性,在分散式系統中比較常見的兩個設計就是分割槽和副本,其中副本主要是為了保證可用性,而分割槽主要是進行資料的平均分佈,二者通常都是根據當前叢集中的節點來進行分配的,如果我們節點短暫的離線升級,資料儲存在對應的PVC中,在恢復後可以很快的進行節點的資訊的恢復並重新加入叢集,所以後面如果開發這種類似的分散式應用的時候,可以將底層的恢復和管理交給k8s,資料儲存在PVC中,則應用更多的只需要關注系統的叢集管理和資料分佈問題即,這也是雲原生帶來的改變 今天就到這裡,好久沒更新了,讀原始碼的過程不易,歡迎幫轉發分享交流,一起進步 kubernetes學習筆記地址: https://www.yuque.com/baxiaoshi/tyado3 > 微訊號:baxiaoshi2020 ![](https://img2020.cnblogs.com/other/1506724/202003/1506724-20200329110413808-5239681.png) > 關注公告號閱讀更多原始碼分析文章 ![圖解原始碼](https://img2020.cnblogs.com/other/1506724/202003/1506724-20200329110414057-835562