背景

阿里云開源的云原生應(yīng)用自動(dòng)化管理套件、CNCF Sandbox 項(xiàng)目 -- OpenKruise，今天發(fā)布 v0.10.0 新版本，這也會(huì)是 OpenKruise v1.0 之前的最后一個(gè) minor 版本。

本文將帶你一覽 v0.10.0 的新變化，其中新增的 WorkloadSpread、PodUnavailableBudget 等大顆粒特性后續(xù)還將有轉(zhuǎn)文詳細(xì)介紹其設(shè)計(jì)實(shí)現(xiàn)原理。

新功能概覽

1. WorkloadSpread：旁路的應(yīng)用彈性拓?fù)涔芾砟芰?/span>

在應(yīng)用部署運(yùn)維的場景下，有著多種多樣的拓?fù)浯蛏⒁约皬椥缘脑V求。其中最常見、最基本的，就是按某種或幾種拓?fù)渌酱蛏?，比如?/span>

應(yīng)用部署需要按 node 維度打散，避免堆疊（提高容災(zāi)能力）
應(yīng)用部署需要按 AZ（available zone）維度打散（提高容災(zāi)能力）

這些基本的訴求，通過 Kubernetes 原生提供的 pod affinity、topology spread constraints 等能力目前都能夠滿足了。但在實(shí)際的生產(chǎn)場景下，還有著太多更加復(fù)雜的分區(qū)與彈性需求，以下舉一些實(shí)際的例子：

按 zone 打散時(shí)，需要指定在不同 zone 中部署的比例數(shù)，比如某個(gè)應(yīng)用在 zone a、b、c 中部署的 Pod 數(shù)量比例為 1 : 1 : 2 等（由于一些現(xiàn)實(shí)的原因比如該應(yīng)用在多個(gè) zone 中的流量不均衡等）
存在多個(gè) zone 或不同機(jī)型的拓?fù)?，?yīng)用擴(kuò)容時(shí)，優(yōu)先部署到某個(gè) zone 或機(jī)型上，當(dāng)資源不足時(shí)再部署到另一個(gè) zone 或機(jī)型上（往后以此類推）；應(yīng)用縮容時(shí)，要按反向順序，優(yōu)先縮容后面 zone 或機(jī)型上的 Pod（往前以此類推）
存在多個(gè)基礎(chǔ)的節(jié)點(diǎn)池和彈性的節(jié)點(diǎn)池，應(yīng)用部署時(shí)需要固定數(shù)量或比例的 Pod 部署在基礎(chǔ)節(jié)點(diǎn)池，其余的都擴(kuò)到彈性節(jié)點(diǎn)池

對(duì)于這些例子，過去一般只能將一個(gè)應(yīng)用拆分為多個(gè) Workload（比如 Deployment）來部署，才能解決應(yīng)用在不同拓?fù)湎虏捎貌煌壤龜?shù)量、擴(kuò)縮容優(yōu)先級(jí)、資源感知、彈性選擇等場景的基本問題，但還是需要 PaaS 層深度定制化，來支持對(duì)一個(gè)應(yīng)用多個(gè) Workload 的精細(xì)化管理。

針對(duì)這些問題，在 Kruise v0.10.0 版本中新增了 WorkloadSpread 資源，目前它支持配合 Deployment、ReplicaSet、CloneSet 這些 Workload 類型，來管理它們下屬 Pod 的分區(qū)與彈性拓?fù)洹?/span>

以下是一個(gè)簡化的例子：

apiVersion: apps.kruise.io/v1alpha1kind: WorkloadSpreadmetadata:  name: workloadspread-demospec:  targetRef:    apiVersion: apps/v1 | apps.kruise.io/v1alpha1    kind: Deployment | CloneSet    name: workload-xxx  subsets:  - name: subset-a    requiredNodeSelectorTerm:      matchExpressions:      - key: topology.kubernetes.io/zone        operator: In        values:        - zone-a    maxReplicas: 10 | 30%  - name: subset-b    requiredNodeSelectorTerm:      matchExpressions:      - key: topology.kubernetes.io/zone        operator: In        values:        - zone-b

創(chuàng)建這個(gè) WorkloadSpread 可以通過 targetRef 關(guān)聯(lián)到一個(gè) Workload 對(duì)象上，然后這個(gè) Workload 在擴(kuò)容 pod 的過程中，Pod 會(huì)被 Kruise 按上述策略注入對(duì)應(yīng)的拓?fù)湟?guī)則。這是一種旁路的注入和管理方式，本身不會(huì)干涉 Workload 對(duì) Pod 的擴(kuò)縮容、發(fā)布管理。

注意：WorkloadSpread 對(duì) Pod 縮容的優(yōu)先級(jí)控制是通過 Pod Deletion Cost 來實(shí)現(xiàn)的：

如果 Workload 類型是 CloneSet，則已經(jīng)支持了這個(gè) feature，可以實(shí)現(xiàn)縮容優(yōu)先級(jí)
如果 Workload 類型是 Deployment/ReplicaSet，則要求 Kubernetes version >= 1.21，且在 1.21 中要在 kube-controller-manager 上開啟 PodDeletionCost 這個(gè) feature-gate

使用 WorkloadSpread 功能，需要在安裝/升級(jí) Kruise v0.10.0 的時(shí)候打開 WorkloadSpread 這個(gè) feature-gate。

上述例子僅為最簡化配置，更多使用說明請(qǐng)參考官網(wǎng)文檔，具體的實(shí)現(xiàn)原理我們將會(huì)在后續(xù)的文章中與大家分享。

2. PodUnavailableBudget：應(yīng)用可用性防護(hù)

在諸多 Voluntary Disruption 場景中 Kubernetes 原生提供的 Pod Disruption Budget（PDB）通過限制同時(shí)中斷的 Pod 數(shù)量，來保證應(yīng)用的高可用性。

但還有很多場景中，即便有 PDB 防護(hù)依然將會(huì)導(dǎo)致業(yè)務(wù)中斷、服務(wù)降級(jí)，比如：

應(yīng)用 owner 通過 Deployment 正在進(jìn)行版本升級(jí)，與此同時(shí)集群管理員由于機(jī)器資源利用率過低正在進(jìn)行 node 縮容

中間件團(tuán)隊(duì)利用 SidecarSet 正在原地升級(jí)集群中的sidecar版本（例如：ServiceMesh envoy），同時(shí)HPA正在對(duì)同一批應(yīng)用進(jìn)行縮容
應(yīng)用 owner 和中間件團(tuán)隊(duì)利用 CloneSet、SidecarSet 原地升級(jí)的能力，正在對(duì)同一批 Pod 進(jìn)行升級(jí)

這其實(shí)很好理解 -- PDB 只能防控通過 Eviction API 來觸發(fā)的 Pod 驅(qū)逐（例如 kubectl drain驅(qū)逐node上面的所有Pod），但是對(duì)于 Pod 刪除、原地升級(jí) 等很多操作是無法防護(hù)的。

在 Kruise v0.10.0 版本中新增的 PodUnavailableBudget（PUB）功能，則是對(duì)原生 PDB 的強(qiáng)化擴(kuò)展。它包含了 PDB 自身的能力，并在此基礎(chǔ)上增加了對(duì)更多 Voluntary Disruption 操作的防護(hù)，包括但不限于 Pod 刪除、原地升級(jí)等。


apiVersion: apps.kruise.io/v1alpha1kind: PodUnavailableBudgetmetadata:  name: web-server-pub  namespace: webspec:  targetRef:    apiVersion: apps/v1 | apps.kruise.io/v1alpha1    kind: Deployment | CloneSet | StatefulSet | ...    name: web-server  # selector 與 targetRef 二選一配置# selector:#   matchLabels:#     app: web-server  # 保證的最大不可用數(shù)量  maxUnavailable: 60%  # 保證的最小可用數(shù)量# minAvailable: 40%

使用 PodUnavailableBudget 功能，需要在安裝/升級(jí) Kruise v0.10.0 的時(shí)候打開feature-gate（兩個(gè)可以選擇打開一個(gè)，也可以都打開）：

PodUnavailableBudgetDeleteGate：攔截防護(hù) Pod 刪除、驅(qū)逐等操作
PodUnavailableBudgetUpdateGate：攔截防護(hù) Pod 原地升級(jí)等更新操作

更多使用說明請(qǐng)參考官網(wǎng)文檔，具體的實(shí)現(xiàn)原理我們將會(huì)在后續(xù)的文章中與大家分享。

3. CloneSet 支持按拓?fù)湟?guī)則縮容

在 CloneSet 縮容（調(diào)小 replicas 數(shù)量）的時(shí)候，選擇哪些 Pod 刪除是有一套固定算法排序的：

未調(diào)度 < 已調(diào)度
PodPending < PodUnknown < PodRunning

Not ready < ready
較小 pod-deletion cost < 較大 pod-deletion cost

較大打散權(quán)重 < 較小
處于 Ready 時(shí)間較短 < 較長

容器重啟次數(shù)較多 < 較少
創(chuàng)建時(shí)間較短 < 較長

其中，“4” 是在 Kruise v0.9.0 中開始提供的特性，用于支持用戶指定刪除順序（WorkloadSpread 就是利用這個(gè)功能實(shí)現(xiàn)縮容優(yōu)先級(jí)）；而 “5” 則是當(dāng)前 v0.10.0 提供的特性，即在縮容的時(shí)候會(huì)參考應(yīng)用的拓?fù)浯蛏砼判颉?/strong>

如果應(yīng)用配置了 topology spread constraints ，則 CloneSet 縮容時(shí)會(huì)按照其中的 topology 維度打散來選擇 Pod 刪除（比如盡量打平多個(gè) zone 上部署 Pod 的數(shù)量）
如果應(yīng)用沒有配置 topology spread constraints ，則默認(rèn)情況下 CloneSet 縮容時(shí)會(huì)按照 node 節(jié)點(diǎn)維度打散來選擇 Pod 刪除（盡量減少同 node 上的堆疊數(shù)量）

4. Advanced StatefulSet 支持流式擴(kuò)容

為了避免在一個(gè)新 Advanced StatefulSet 創(chuàng)建后有大量失敗的 pod 被創(chuàng)建出來，從 Kruise v0.10.0 版本開始引入了在 scale strategy 中的 maxUnavailable 策略：

apiVersion: apps.kruise.io/v1beta1kind: StatefulSetspec:  # ...  replicas: 100  scaleStrategy:    maxUnavailable: 10% # percentage or absolute number

當(dāng)這個(gè)字段被設(shè)置之后，Advanced StatefulSet 會(huì)保證創(chuàng)建 pod 之后不可用 pod 數(shù)量不超過這個(gè)限制值。

比如說，上面這個(gè) StatefulSet 一開始只會(huì)一次性創(chuàng)建 10 個(gè) pod。在此之后，每當(dāng)一個(gè) pod 變?yōu)?running、ready 狀態(tài)后，才會(huì)再創(chuàng)建一個(gè)新 pod 出來。

注意：這個(gè)功能只允許在 podManagementPolicy 是 `Parallel` 的 StatefulSet 中使用。

5. 其他

除了上述內(nèi)容外，還有一些變動(dòng)如：

SidecarSet 新增 imagePullSecrets、injectionStrategy.paused 等字段支持配置 sidecar 鏡像拉取 secret 以及暫停注入
Advanced StatefulSet 支持配合原地升級(jí)的鏡像提前預(yù)熱

詳見 ChangeLog 文檔。

最后

本次的 v0.10.0 會(huì)是 OpenKruise v1.0 之前的最后一個(gè) minor 版本，在年底之前 Kruise 將會(huì)發(fā)布首個(gè) v1.0 大版本，敬請(qǐng)期待！

OpenKruise v0.10.0 版本發(fā)布：新增應(yīng)用彈性拓?fù)涔芾怼?yīng)用防護(hù)等能力

背景