基于K8s的自定義控制器Enhanced Statefulset怎么用

這期內容當中小編將會給大家帶來有關基于K8s的自定義控制器Enhanced Statefulset怎么用，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

下面要講的產品——Enhanced statefulset。

顧名思義，Enhanced statefulset就是我們在statefulset的基礎上對控制器做了進一步的擴展。它主要解決Pod綁定靜態IP問題，同時也解決了statefulset在升級過程中不允許同時升級多個實例的限制。另外，它還可以在節點故障時支持Pod和IP的遷移。

前面已經提到了靜態IP的重要場景是業務依賴的周邊組件都以IP作為實例唯一標識，所以上到Kubernetes后仍然需要Pod實例保持IP不變。相信很多用戶也面臨著類似的問題，下面就來分享一下實現原理。

我們主要是通過對Enhanced Statefulset Controller 、 Scheduler、CNI這幾個模塊擴展來支持Enhanced Statefulset的Pod綁定靜態IP。

Enhanced Statefulset Controller 對靜態IP的管理主要是維護更新Static IP CR來實現的。當Controller收到創建請求時，會首先檢查要創建的實例是否已經有對應的static IP CR記錄，若記錄不存在則會創建一個新的記錄。在稍后scheduler完成調度，CNI完成靜態IP分配后，controller會監聽Pod信息并將其更新到Static IP CR中。反之若創建實例時，對應的static IP CR記錄已經存在則表示這個Pod是刪除重建，Controller會將static IP CR中的信息更新到Pod上，scheduler和CNI根據pod上的配置進行親和性調度和IP分配。

StaticIP CRD中記錄了負載類型、負載名稱、節點、IP和Pod信息。其中IP信息在Pod實例上以annotation

• 新增緩存：原有 Node 緩存基礎上新增 staticIPNode 緩存,用于計算和緩存 staticIPPod 資源占用情況、緩存 IP 數量、Pod cpu/內存 使用量；

• 新增predicate ：

• PodFitsResourcesWithStaticIPPodPred Node 現有資源基礎上基于 staticIPPod 占用資源再次過濾,達到資源預占目的；

• CheckPodAnnotationWithStaticIPPred 檢查pod 是否包含 static ip 的指定 node annotation, 并僅保留指定 node 結果只 fit node 列表。

概括起來核心思路就是將靜態IP Pod所占用的資源作為一種特殊資源單獨標識，在調度時進行匹配調度達到資源預占目的。

CNI 在靜態IP場景下主要實現以下三個功能：

1. 按照Pod annotation上指定的IP分配，若無IP則從IP池中隨機分配一個IP并將此記錄更新到Pod中 ；

2. IP地址預留，當綁定靜態IP的Pod刪除重建時，CNI會檢查static IP CR記錄，如果記錄未刪除則IP地址不釋放，確保重建的Pod能夠拿到綁定的IP；

3. 在大規模集群場景下，為了提高SDN網絡性能，我們要求CNI必須使用IP range模式。在這種模式下，彈性網卡上綁定的是IP CIDR，例如10.0.0.0/24,而不是某一個具體IP。IP遷移，釋放和申請都是以CIDR的形式進行。

最后，我們通過一個創建流程來展示一下Enhanced statefulset對象如何綁定靜態IP：

1. 用戶創建一個enhanced statefulset對象，該請求首先發送到API server；

2. enhanced statefulset controller監聽到該請求，首先查詢是否有該Pod對應的CR記錄，若沒有則創建新的CR，若已經有CR，則將CR中的信息更新的新建的Pod中；

3. enhanced statefulset controller開始創建Pod；

4. Scheduler根據Pod的affinity信息將其調度到相應的節點上，若無affinity信息則是新建pod正常調度。同時調度時會觸發資源預留邏輯確保已有的靜態IP Pod的資源不被占用；

5. CNI查看Pod靜態IP記錄，如無記錄則隨機分配IP并將IP信息更新到Pod上，若有記錄則按記錄分配；

6. StaticIP controller監聽到Pod上靜態IP信息變更，并將此信息更新到CR中。

除了支持靜態IP這個強需求，我們考慮的第二個重點就是盡可能將Kubernetes的DevOps能力賦能給業務場景。社區原生的 StatefulSet 在升級過程中不允許同時升級多個實例，這主要是為了某些有狀態應用需要依次按序升級的需求。但這樣帶來的問題是效率太低，而集團業務對升級失敗和順序有一定容忍度，為了提升升級效率，我們定義了MaxUnavailable 參數，它允許應用實例被并行升級，且始終保持最大不可用的實例數不超過 MaxUnavailable 的限制數。

此外，為了保證升級足夠可控，Enhanced Statefulset可以通過Partitions進行分批升級。每個批次升級完成后通過再次更新Partitions觸發下一次升級，如果發現升級過程中遇到問題也可以進行Rollback回滾或Paused暫停。

通過這些優化，Enhanced Statefulset具備更好了靈活性，既可以兼容原生Statefulset規則嚴格按照實例順序升級，確保有狀態服務的可靠性。又可以兼具類似Deployment的能力，以更高效的方式并發升級。同時還可以分批手工觸發，基本覆蓋了集團業務的絕大部分場景。

下面通過一個示例來具體了解下：

用戶創建了一個Enhanced Statefulset的應用，副本數為6，應用從staticip-example-0到staticip-example-5，Partitions設置為3, MaxUnavailable設置為2。

 1apiVersion: jke.jdcloud.com/v1alpha1
 2kind: EnhancedStatefulSet
 3metadata:
 4  name: staticip-example
 5  annotations:
 6    staticip.jke.jdcloud.com/enable: "true"    #打開靜態IP功能
 7spec:
 8  serviceName: enhanced-sts-service-example
 9  replicas: 6
10  selector:
11    matchLabels:
12      apps: staticip-example
13  updateStrategy:
14    rollingUpdate:
15      maxUnavailable: 2                       #最大不可用數量，允許并行升級，并且容忍副本不可用
16      partition: 3                            #enhanced statefulset創建的Pod都有index，命名從0開始，例如pod-0 pod-1  所有index大于等于partition值的實例升級，通過變更partition值來實現分批升級
17      paused: false
18      podUpdatePolicy: ReCreate
19    type: RollingUpdate
20  template:
21    metadata:
22      labels:
23        apps: staticip-example
24    spec:
25      containers:
26        - image: nginx:v1                    # nginx:v1 變更為 nginx:v2 觸發升級




當用戶將鏡像從v1升級到v2時,升級流程如下：

1. Enhanced Statefulset Controller將staticip-example-3到staticip-example-5這3個副本并發升級到v2版本，其中staticip-example-4不可用，因為MaxUnavailable當前值為2，不影響應用繼續升級；

2. 用戶將Partitions設置為0，enhanced statefulset controller將剩余3個副本staticip-example-0到staticip-example-2并發升級到v2版本，其中staticip-example-2不可用；

3. 隨后用戶對不可用Pod進行手工修復，所有實例均恢復正常。

在執行第二步時，如果第一步升級有兩個實例不可用觸發MaxUnavailable閾值，則用戶在第二步即使將Partitions設置為0也不會觸發再次升級。

最后，再和大家聊一下故障遷移功能。靜態IP為業務上Kubernetes帶來便利的同時也帶來了問題，其中一個比較突出的問題就是故障遷移場景。故障遷移有幾個前提條件：

1. 靜態IP Pod和其所綁定的IP需要遷移到同一個目標節點上，這樣才能保證Pod遷移后IP不變；

2. 前面已經提到在大規模集群下我們要求CNI必須配置成IP Range模式，這種模式下IP CIDR不能拆分到更細粒度遷移，一個節點綁定的一個IP CIDR只能遷移到一個目標節點。這就意味著，所有綁定靜態IP的Pod也必須遷移到同一個目標。這樣就帶來了一個問題，怎樣才能保證目標節點有足夠的資源；

3. 故障遷移后，業務希望最大程度保留原來的物理拓撲，虛機配置與規格；

針對這些問題，我們當前給出的方案是node migration。基本流程如下：

1. 當節點處于失聯狀態超過容忍的時間窗口后（用戶可根據業務情況配置時間窗口閾值），node operator會將此節點禁用；

2. node operator會創建一臺與故障節點同規格同AZ的目標節點；

3. node operator將故障節點的IP和Pod 指定遷移到新節點重新創建，并更新元數據信息；

4. 將故障節點刪除。

上述就是小編為大家分享的基于K8s的自定義控制器Enhanced Statefulset怎么用了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。