StatefulSet是k8s中有狀態(tài)應用管理的標準實現(xiàn),今天就一起來了解下其背后設計的場景與原理,從而了解其適用范圍與場景。

[[320745]]

1. 基礎概念

首先介紹有狀態(tài)應用里面的需要考慮的一些基礎的事情，然后在下一章我們再去看statefulSet的關(guān)鍵實現(xiàn)。

1.1 有狀態(tài)與無狀態(tài)

在日常開發(fā)的應用中，通常可以分為兩大類：有狀態(tài)與無狀態(tài)，比如web服務通常都是無狀態(tài)的，web應用數(shù)據(jù)主要來自后端存儲、緩存等中間件，而本身并不保存數(shù); 而諸如redis、es等其數(shù)據(jù)也是應用自身的一部分，由此可以看出有狀態(tài)應用本身會包含兩部分：應用與數(shù)據(jù)。

1.2 一致性與數(shù)據(jù)

一致性是分布式系統(tǒng)中很常見的問題，上面提到有狀態(tài)應用包含數(shù)據(jù)部分，那數(shù)據(jù)和一致性是不是一個東西呢?答案是并不一定，在諸如zookeeper等應用中，會通過zab協(xié)議保證數(shù)據(jù)寫入到集群中的大多數(shù)節(jié)點, 而在諸如kafka之類的應用其一致性設計要求相對較低，由此可以看出有狀態(tài)應用數(shù)據(jù)的一致性，更多的是由對應場景的系統(tǒng)設計而決定。

1.3 身份標識

在一些應用中身份標識是系統(tǒng)本身組成的一部分，比如zookeeper其通過server的id來影響最終的zab協(xié)議的選舉，在kafka中分區(qū)的分配時也是按照對應的id來分配的。

1.4 單調(diào)有序更新

通常分布式系統(tǒng)中都至少要保證分區(qū)容忍性，以防止部分節(jié)點故障導致整個系統(tǒng)不可用，在k8s中的statefulset中的 Pod的管理策略則是保證盡可能安全的逐個Pod更新，而不是并行啟動或停止所有的Pod。

1.5 擴縮容與故障轉(zhuǎn)移

在k8s中水平方向上的擴容和縮容都非常簡單，刪除和添加一個Pod的事情，但是對于有狀態(tài)應用，其實就不知這些，比如擴容后的數(shù)據(jù)如何做平衡，節(jié)點失敗后的故障轉(zhuǎn)移怎么做，這些都是要一個有狀態(tài)應用需要自己考慮的事情。

2. 核心實現(xiàn)

StatefulSet的實現(xiàn)機制整體流程相對簡明，接下來按照Pod管理、狀態(tài)計算、狀態(tài)管理、更新策略這幾部分來依次講解。

2.1 Pod的release與adopt

statefulSet中的pod的名字都是按照一定規(guī)律來進行設置的, 名字本身也有含義, k8s在進行statefulset更新的時候，首先會過濾屬于當前statefulset的pod，并做如下操作

K8s中控制器與Pod的關(guān)聯(lián)主要通過兩個部分：controllerRef和label, statefulset在進行Pod過濾的時候，如果發(fā)現(xiàn)對應的pod的controllerRef都是當前的statefulset但是其label或者名字并不匹配，則就會嘗試release對應的Pod。

反之如果發(fā)現(xiàn)對應Pod的label和名字都匹配，但是controllerRef并不是當前的statefulSet就會更新對應的controllerRef為當前的statefulset, 這個操作被稱為adopt。

通過該流程可以確保當前statefulset關(guān)聯(lián)的Pod要么與當前的對象關(guān)聯(lián)，要么我就釋放你，這樣可以維護Pod的一致性，即時有人修改了對應的Pod則也會調(diào)整成最終一致性。

2.2 副本分類

在經(jīng)過第一步的Pod狀態(tài)的修正之后，statefulset會遍歷所有屬于自己的Pod，同時將Pod分為兩個大類：有效副本和無效副本(condemned)，前面提到過Pod的名字也是有序的即有N個副本的Pod則名字依次是{0...N-1}, 這里區(qū)分有效和無效也是依據(jù)對應的索引順序，如果超過當前的副本即為無效副本。

2.3 單調(diào)更新

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

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

2.4 基于計數(shù)器的滾動更新

滾動更新的實現(xiàn)相對隱晦一點，其主要是通過控制副本計數(shù)來實現(xiàn)，首先倒序檢查對應的Pod的版本是否是很新版本，如果發(fā)現(xiàn)不是，則直接刪除對應的Pod，同時將currentReplica計數(shù)減一，這樣在檢查對應的Pod的時候，就會發(fā)現(xiàn)對應的Pod的不存在，就需要為對應的Pod生成新的Pod信息，此時就會使用比較新的副本去更新。

func newVersionedStatefulSetPod(currentSet, updateSet *apps.StatefulSet, currentRevision, updateRevision string, ordinal int) *v1.Pod { 
    // 如果發(fā)現(xiàn)當前的Pod的索引小于當?shù)母北居嫈?shù)，則表明當前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 無效副本的清理

無效副本的清理應該主要是發(fā)生在對應的statefulset縮容的時候，如果發(fā)現(xiàn)對應的副本已經(jīng)被遺棄，就會直接刪除，此處默認也需要遵循單調(diào)性原則，即每次都只更新一個副本。

2.6 基于刪除的單調(diào)性更新

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在滿足單調(diào)性的情況下，有效副本里面的所有Pod都是RunningAndReady狀態(tài)了，此時就開始倒序進行版本檢查，如果發(fā)現(xiàn)版本不一致，就根據(jù)當前的partition的數(shù)量來決定允許并行更新的數(shù)量，在這里刪除后，就會觸發(fā)對應的事件，從而觸發(fā)下一個調(diào)度事件，觸發(fā)下一輪一致性檢查。

2.7 OnDelete策略

if set.Spec.UpdateStrategy.Type == apps.OnDeleteStatefulSetStrategyType { 
       return &status, nil 
   } 

StatefulSet的更新策略除了RollingUpdate還有一種即OnDelete即必須人工刪除對應的 Pod來觸發(fā)一致性檢查，所以針對那些如果想只更新指定索引的statefulset可以嘗試該策略，每次只刪除對應的索引，這樣只有指定的索引會更新為很新的版本。

2.8 狀態(tài)存儲

狀態(tài)存儲其實就是我們常說的PVC，在Pod創(chuàng)建和更新的時候，如果發(fā)現(xiàn)對應的PVC的不存在則就會根據(jù)statefulset里面的配置創(chuàng)建對應的PVC，并更新對應Pod的配置。

3. 有狀態(tài)應用總結(jié)

從核心實現(xiàn)分析中可以看出來，有狀態(tài)應用的實現(xiàn)，實際上核心是基于一致性狀態(tài)、單調(diào)更新、持久化存儲的組合，通過一致性狀態(tài)、單調(diào)性更新，保證期望副本的數(shù)量的Pod處于RunningAndReady的狀態(tài)并且保證有序性，同時通過持久化存儲來進行數(shù)據(jù)的保存。

有序的重要性，在分布式系統(tǒng)中比較常見的兩個設計就是分區(qū)和副本，其中副本主要是為了保證可用性，而分區(qū)主要是進行數(shù)據(jù)的平均分布，二者通常都是根據(jù)當前集群中的節(jié)點來進行分配的，如果我們節(jié)點短暫的離線升級，數(shù)據(jù)保存在對應的PVC中，在恢復后可以很快的進行節(jié)點的信息的恢復并重新加入集群，所以后面如果開發(fā)這種類似的分布式應用的時候，可以將底層的恢復和管理交給k8s，數(shù)據(jù)保存在PVC中，則應用更多的只需要關(guān)注系統(tǒng)的集群管理和數(shù)據(jù)分布問題即，這也是云原生帶來的改變。

今天就到這里，好久沒更新了，讀源碼的過程不易，歡迎幫轉(zhuǎn)發(fā)分享交流，一起進步。