圖解 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 公共號: 圖解原始碼 歡迎一起交流學習分享