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

StatefulSet是k8s中有狀態應用管理的標準實現,今天就一塊兒來了解下其背後設計的場景與原理,從而瞭解其適用範圍與場景

1. 基礎概念

首先介紹有狀態應用裏面的須要考慮的一些基礎的事情，而後在下一章咱們再去看statefulSet的關鍵實現

1.1 有狀態與無狀態

在平常開發的應用中，一般能夠分爲兩大類：有狀態與無狀態，好比web服務一般都是無狀態的，web應用數據主要來自後端存儲、緩存等中間件，而自己並不保存數; 而諸如redis、es等其數據也是應用自身的一部分，由此能夠看出有狀態應用自己會包含兩部分：應用與數據

1.2 一致性與數據

一致性是分佈式系統中很常見的問題，上面提到有狀態應用包含數據部分，那數據和一致性是否是一個東西呢？答案是並不必定，在諸如zookeeper等應用中，會經過zab協議保證數據寫入到集羣中的大多數節點, 而在諸如kafka之類的應用其一致性設計要求相對較低，由此能夠看出有狀態應用數據的一致性，更多的是由對應場景的系統設計而決定

1.3 身份標識

在一些應用中身份標識是系統自己組成的一部分，好比zookeeper其經過server的id來影響最終的zab協議的選舉，在kafka中分區的分配時也是按照對應的id來分配的

1.4 單調有序更新

一般分佈式系統中都至少要保證分區容忍性，以防止部分節點故障致使整個系統不可用，在k8s中的statefulset中的 Pod的管理策略則是保證儘量安全的逐個Pod更新，而不是並行啓動或中止全部的Pod

1.5 擴縮容與故障轉移

在k8s中水平方向上的擴容和縮容都很是簡單，刪除和添加一個Pod的事情，可是對於有狀態應用，其實就不知這些，好比擴容後的數據如何作平衡，節點失敗後的故障轉移怎麼作，這些都是要一個有狀態應用須要本身考慮的事情

2. 核心實現

StatefulSet的實現機制總體流程相對簡明，接下來按照Pod管理、狀態計算、狀態管理、更新策略這幾部分來依次講解

2.1 Pod的release與adopt

statefulSet中的pod的名字都是按照必定規律來進行設置的, 名字自己也有含義, k8s在進行statefulset更新的時候，首先會過濾屬於當前statefulset的pod，並作以下操做

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 副本分類

在通過第一步的Pod狀態的修正以後，statefulset會遍歷全部屬於本身的Pod，同時將Pod分爲兩個大類：有效副本和無效副本(condemned)，前面提到過Pod的名字也是有序的即有N個副本的Pod則名字依次是{0...N-1}, 這裏區分有效和無效也是依據對應的索引順序，若是超過當前的副本即爲無效副本

2.3 單調更新

單調更新主要是指的當對應的Pod管理策略不是並行管理的時候，只要當前Replicas(有效副本)中任一一個Pod發生建立、終止、未就緒的時候，都會等待對應的Pod就緒，即你要想更新一個statefulset的Pod的時候，對應的Pod必須已經RunningAndReady

func allowsBurst(set *apps.StatefulSet) bool {
    return set.Spec.PodManagementPolicy == apps.ParallelPodManagement
}

2.4 基於計數器的滾動更新

滾動更新的實現相對隱晦一點，其主要是經過控制副本計數來實現，首先倒序檢查對應的Pod的版本是不是最新版本，若是發現不是，則直接刪除對應的Pod，同時將currentReplica計數減一，這樣在檢查對應的Pod的時候，就會發現對應的Pod的不存在，就須要爲對應的Pod生成新的Pod信息，此時就會使用最新的副本去更新

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 基於刪除的單調性更新

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策略

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的狀態而且保證有序性，同時經過持久化存儲來進行數據的保存

有序的重要性，在分佈式系統中比較常見的兩個設計就是分區和副本，其中副本主要是爲了保證可用性，而分區主要是進行數據的平均分佈，兩者一般都是根據當前集羣中的節點來進行分配的，若是咱們節點短暫的離線升級，數據保存在對應的PVC中，在恢復後能夠很快的進行節點的信息的恢復並從新加入集羣，因此後面若是開發這種相似的分佈式應用的時候，能夠將底層的恢復和管理交給k8s，數據保存在PVC中，則應用更多的只須要關注系統的集羣管理和數據分佈問題即，這也是雲原生帶來的改變

今天就到這裏，很久沒更新了，讀源碼的過程不易，歡迎幫轉發分享交流，一塊兒進步

kubernetes學習筆記地址: https://www.yuque.com/baxiaoshi/tyado3

微信號：baxiaoshi2020 關注公告號閱讀更多源碼分析文章 更多文章關注 www.sreguide.com