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

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)碛嘘P(guān)基于K8s的自定義控制器Enhanced Statefulset怎么用，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

下面要講的產(chǎn)品——Enhanced statefulset。

顧名思義，Enhanced statefulset就是我們在statefulset的基礎(chǔ)上對(duì)控制器做了進(jìn)一步的擴(kuò)展。它主要解決Pod綁定靜態(tài)IP問題，同時(shí)也解決了statefulset在升級(jí)過程中不允許同時(shí)升級(jí)多個(gè)實(shí)例的限制。另外，它還可以在節(jié)點(diǎn)故障時(shí)支持Pod和IP的遷移。

前面已經(jīng)提到了靜態(tài)IP的重要場景是業(yè)務(wù)依賴的周邊組件都以IP作為實(shí)例唯一標(biāo)識(shí)，所以上到Kubernetes后仍然需要Pod實(shí)例保持IP不變。相信很多用戶也面臨著類似的問題，下面就來分享一下實(shí)現(xiàn)原理。

我們主要是通過對(duì)Enhanced Statefulset Controller 、 Scheduler、CNI這幾個(gè)模塊擴(kuò)展來支持Enhanced Statefulset的Pod綁定靜態(tài)IP。

Enhanced Statefulset Controller 對(duì)靜態(tài)IP的管理主要是維護(hù)更新Static IP CR來實(shí)現(xiàn)的。當(dāng)Controller收到創(chuàng)建請求時(shí)，會(huì)首先檢查要?jiǎng)?chuàng)建的實(shí)例是否已經(jīng)有對(duì)應(yīng)的static IP CR記錄，若記錄不存在則會(huì)創(chuàng)建一個(gè)新的記錄。在稍后scheduler完成調(diào)度，CNI完成靜態(tài)IP分配后，controller會(huì)監(jiān)聽Pod信息并將其更新到Static IP CR中。反之若創(chuàng)建實(shí)例時(shí)，對(duì)應(yīng)的static IP CR記錄已經(jīng)存在則表示這個(gè)Pod是刪除重建，Controller會(huì)將static IP CR中的信息更新到Pod上，scheduler和CNI根據(jù)pod上的配置進(jìn)行親和性調(diào)度和IP分配。

StaticIP CRD中記錄了負(fù)載類型、負(fù)載名稱、節(jié)點(diǎn)、IP和Pod信息。其中IP信息在Pod實(shí)例上以annotation

• 新增緩存：原有 Node 緩存基礎(chǔ)上新增 staticIPNode 緩存,用于計(jì)算和緩存 staticIPPod 資源占用情況、緩存 IP 數(shù)量、Pod cpu/內(nèi)存 使用量；

• 新增predicate ：

• PodFitsResourcesWithStaticIPPodPred Node 現(xiàn)有資源基礎(chǔ)上基于 staticIPPod 占用資源再次過濾,達(dá)到資源預(yù)占目的；

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

概括起來核心思路就是將靜態(tài)IP Pod所占用的資源作為一種特殊資源單獨(dú)標(biāo)識(shí)，在調(diào)度時(shí)進(jìn)行匹配調(diào)度達(dá)到資源預(yù)占目的。

CNI 在靜態(tài)IP場景下主要實(shí)現(xiàn)以下三個(gè)功能：

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

2. IP地址預(yù)留，當(dāng)綁定靜態(tài)IP的Pod刪除重建時(shí)，CNI會(huì)檢查static IP CR記錄，如果記錄未刪除則IP地址不釋放，確保重建的Pod能夠拿到綁定的IP；

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

最后，我們通過一個(gè)創(chuàng)建流程來展示一下Enhanced statefulset對(duì)象如何綁定靜態(tài)IP：

1. 用戶創(chuàng)建一個(gè)enhanced statefulset對(duì)象，該請求首先發(fā)送到API server；

2. enhanced statefulset controller監(jiān)聽到該請求，首先查詢是否有該P(yáng)od對(duì)應(yīng)的CR記錄，若沒有則創(chuàng)建新的CR，若已經(jīng)有CR，則將CR中的信息更新的新建的Pod中；

3. enhanced statefulset controller開始創(chuàng)建Pod；

4. Scheduler根據(jù)Pod的affinity信息將其調(diào)度到相應(yīng)的節(jié)點(diǎn)上，若無affinity信息則是新建pod正常調(diào)度。同時(shí)調(diào)度時(shí)會(huì)觸發(fā)資源預(yù)留邏輯確保已有的靜態(tài)IP Pod的資源不被占用；

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

6. StaticIP controller監(jiān)聽到Pod上靜態(tài)IP信息變更，并將此信息更新到CR中。

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

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

通過這些優(yōu)化，Enhanced Statefulset具備更好了靈活性，既可以兼容原生Statefulset規(guī)則嚴(yán)格按照實(shí)例順序升級(jí)，確保有狀態(tài)服務(wù)的可靠性。又可以兼具類似Deployment的能力，以更高效的方式并發(fā)升級(jí)。同時(shí)還可以分批手工觸發(fā)，基本覆蓋了集團(tuán)業(yè)務(wù)的絕大部分場景。

下面通過一個(gè)示例來具體了解下：

用戶創(chuàng)建了一個(gè)Enhanced Statefulset的應(yīng)用，副本數(shù)為6，應(yīng)用從staticip-example-0到staticip-example-5，Partitions設(shè)置為3, MaxUnavailable設(shè)置為2。

 1apiVersion: jke.jdcloud.com/v1alpha1
 2kind: EnhancedStatefulSet
 3metadata:
 4  name: staticip-example
 5  annotations:
 6    staticip.jke.jdcloud.com/enable: "true"    #打開靜態(tài)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                       #最大不可用數(shù)量，允許并行升級(jí)，并且容忍副本不可用
16      partition: 3                            #enhanced statefulset創(chuàng)建的Pod都有index，命名從0開始，例如pod-0 pod-1  所有index大于等于partition值的實(shí)例升級(jí)，通過變更partition值來實(shí)現(xiàn)分批升級(jí)
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 觸發(fā)升級(jí)




當(dāng)用戶將鏡像從v1升級(jí)到v2時(shí),升級(jí)流程如下：

1. Enhanced Statefulset Controller將staticip-example-3到staticip-example-5這3個(gè)副本并發(fā)升級(jí)到v2版本，其中staticip-example-4不可用，因?yàn)镸axUnavailable當(dāng)前值為2，不影響應(yīng)用繼續(xù)升級(jí)；

2. 用戶將Partitions設(shè)置為0，enhanced statefulset controller將剩余3個(gè)副本staticip-example-0到staticip-example-2并發(fā)升級(jí)到v2版本，其中staticip-example-2不可用；

3. 隨后用戶對(duì)不可用Pod進(jìn)行手工修復(fù)，所有實(shí)例均恢復(fù)正常。

在執(zhí)行第二步時(shí)，如果第一步升級(jí)有兩個(gè)實(shí)例不可用觸發(fā)MaxUnavailable閾值，則用戶在第二步即使將Partitions設(shè)置為0也不會(huì)觸發(fā)再次升級(jí)。

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

1. 靜態(tài)IP Pod和其所綁定的IP需要遷移到同一個(gè)目標(biāo)節(jié)點(diǎn)上，這樣才能保證Pod遷移后IP不變；

2. 前面已經(jīng)提到在大規(guī)模集群下我們要求CNI必須配置成IP Range模式，這種模式下IP CIDR不能拆分到更細(xì)粒度遷移，一個(gè)節(jié)點(diǎn)綁定的一個(gè)IP CIDR只能遷移到一個(gè)目標(biāo)節(jié)點(diǎn)。這就意味著，所有綁定靜態(tài)IP的Pod也必須遷移到同一個(gè)目標(biāo)。這樣就帶來了一個(gè)問題，怎樣才能保證目標(biāo)節(jié)點(diǎn)有足夠的資源；

3. 故障遷移后，業(yè)務(wù)希望最大程度保留原來的物理拓?fù)?，虛機(jī)配置與規(guī)格；

針對(duì)這些問題，我們當(dāng)前給出的方案是node migration?；玖鞒倘缦拢?/p>

1. 當(dāng)節(jié)點(diǎn)處于失聯(lián)狀態(tài)超過容忍的時(shí)間窗口后（用戶可根據(jù)業(yè)務(wù)情況配置時(shí)間窗口閾值），node operator會(huì)將此節(jié)點(diǎn)禁用；

2. node operator會(huì)創(chuàng)建一臺(tái)與故障節(jié)點(diǎn)同規(guī)格同AZ的目標(biāo)節(jié)點(diǎn)；

3. node operator將故障節(jié)點(diǎn)的IP和Pod 指定遷移到新節(jié)點(diǎn)重新創(chuàng)建，并更新元數(shù)據(jù)信息；

4. 將故障節(jié)點(diǎn)刪除。

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