簡介：阿里云開源的云原生應用自動化管理套件、CNCF Sandbox 項目 -- OpenKruise，今天發布 v0.10.0 新版本，這也會是 OpenKruise v1.0 之前的最后一個 minor 版本。 本文將帶你一覽 v0.10.0 的新變化，其中新增的 WorkloadSpread、PodUnavailableBudget 等大顆粒特性后續還將有轉文詳細介紹其設計實現原理。

作者 | 酒祝

背景

阿里云開源的云原生應用自動化管理套件、CNCF Sandbox 項目 -- OpenKruise，今天發布 v0.10.0 新版本，這也會是 OpenKruise v1.0 之前的最后一個 minor 版本。

本文將帶你一覽 v0.10.0 的新變化，其中新增的 WorkloadSpread、PodUnavailableBudget 等大顆粒特性后續還將有轉文詳細介紹其設計實現原理。

新功能概覽

1. ?WorkloadSpread：旁路的應用彈性拓撲管理能力

在應用部署運維的場景下，有著多種多樣的拓撲打散以及彈性的訴求。其中最常見、最基本的，就是按某種或幾種拓撲水平打散，比如：

• 應用部署需要按 node 維度打散，避免堆疊（提高容災能力）
• 應用部署需要按 AZ（available zone）維度打散（提高容災能力）

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

• 按 zone 打散時，需要指定在不同 zone 中部署的比例數，比如某個應用在 zone a、b、c 中部署的 Pod 數量比例為 1 : 1 : 2 等（由于一些現實的原因比如該應用在多個 zone 中的流量不均衡等）
  
• 存在多個 zone 或不同機型的拓撲，應用擴容時，優先部署到某個 zone 或機型上，當資源不足時再部署到另一個 zone 或機型上（往后以此類推）；應用縮容時，要按反向順序，優先縮容后面 zone 或機型上的 Pod（往前以此類推）
  
• 存在多個基礎的節點池和彈性的節點池，應用部署時需要固定數量或比例的 Pod 部署在基礎節點池，其余的都擴到彈性節點池

對于這些例子，過去一般只能將一個應用拆分為多個 Workload（比如 Deployment）來部署，才能解決應用在不同拓撲下采用不同比例數量、擴縮容優先級、資源感知、彈性選擇等場景的基本問題，但還是需要 PaaS 層深度定制化，來支持對一個應用多個 Workload 的精細化管理。

針對這些問題，在 Kruise v0.10.0 版本中新增了 WorkloadSpread 資源，目前它支持配合 Deployment、ReplicaSet、CloneSet 這些 Workload 類型，來管理它們下屬 Pod 的分區與彈性拓撲。

以下是一個簡化的例子：

apiVersion: apps.kruise.io/v1alpha1 kind: WorkloadSpread metadata: name: workloadspread-demo spec: 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

創建這個 WorkloadSpread 可以通過 targetRef 關聯到一個 Workload 對象上，然后這個 Workload 在擴容 pod 的過程中，Pod 會被 Kruise 按上述策略注入對應的拓撲規則。這是一種旁路的注入和管理方式，本身不會干涉 Workload 對 Pod 的擴縮容、發布管理。

注意：WorkloadSpread 對 Pod 縮容的優先級控制是通過 Pod Deletion Cost 來實現的：

• 如果 Workload 類型是 CloneSet，則已經支持了這個 feature，可以實現縮容優先級
• 如果 Workload 類型是 Deployment/ReplicaSet，則要求 Kubernetes version >= 1.21，且在 1.21 中要在 kube-controller-manager 上開啟 PodDeletionCost 這個 feature-gate

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

上述例子僅為最簡化配置，更多使用說明請參考 官網文檔，具體的實現原理我們將會在后續的文章中與大家分享。

2. ?PodUnavailableBudget：應用可用性防護

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

但還有很多場景中，即便有 PDB 防護依然將會導致業務中斷、服務降級，比如：

• 應用 owner 通過 Deployment 正在進行版本升級，與此同時集群管理員由于機器資源利用率過低正在進行 node 縮容
• 中間件團隊利用 SidecarSet 正在原地升級集群中的sidecar版本（例如：ServiceMesh envoy），同時HPA正在對同一批應用進行縮容
• 應用 owner 和中間件團隊利用 CloneSet、SidecarSet 原地升級的能力，正在對同一批 Pod 進行升級

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

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

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

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

• PodUnavailableBudgetDeleteGate：攔截防護 Pod 刪除、驅逐等操作
• PodUnavailableBudgetUpdateGate：攔截防護 Pod 原地升級等更新操作

更多使用說明請參考 官網文檔，具體的實現原理我們將會在后續的文章中與大家分享。

3.? CloneSet 支持按拓撲規則縮容

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

未調度 < 已調度

PodPending < PodUnknown < PodRunning

Not ready < ready

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

較大打散權重 < 較小

處于 Ready 時間較短 < 較長

容器重啟次數較多 < 較少

創建時間較短 < 較長

其中，“4” 是在 Kruise v0.9.0 中開始提供的特性，用于支持用戶指定刪除順序（WorkloadSpread 就是利用這個功能實現縮容優先級）；而 “5” 則是當前 v0.10.0 提供的特性，即在縮容的時候會參考應用的拓撲打散來排序。

• 如果應用配置了 topology spread constraints ，則 CloneSet 縮容時會按照其中的 topology 維度打散來選擇 Pod 刪除（比如盡量打平多個 zone 上部署 Pod 的數量）
• 如果應用沒有配置 topology spread constraints ，則默認情況下 CloneSet 縮容時會按照 node 節點維度打散來選擇 Pod 刪除（盡量減少同 node 上的堆疊數量）

4.? Advanced StatefulSet 支持流式擴容

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

apiVersion: apps.kruise.io/v1beta1 kind: StatefulSet spec: # ... replicas: 100 scaleStrategy: maxUnavailable: 10% # percentage or absolute number

當這個字段被設置之后，Advanced StatefulSet 會保證創建 pod 之后不可用 pod 數量不超過這個限制值。

比如說，上面這個 StatefulSet 一開始只會一次性創建 10 個 pod。在此之后，每當一個 pod 變為 running、ready 狀態后，才會再創建一個新 pod 出來。

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

5.? 其他

除了上述內容外，還有一些變動如：

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

詳見 ChangeLog 文檔。

最后

本次的 v0.10.0 會是 OpenKruise v1.0 之前的最后一個 minor 版本，在年底之前 Kruise 將會發布首個 v1.0 大版本，敬請期待！

另外，OpenKruise 社區開始組織定期的雙周會，從本周四（9月9日）晚上19:00（ GMT+8 Asia/Shanghai）首次開始，本次周會將會講解 v0.10.0 新版本的特性以及 demo 演示。參與方式：

• Zoom 會議鏈接（見文末鏈接）
• 加入 OpenKruise 社區交流群（釘釘搜群號 23330762 ），將會有群直播

更多內容

OpenKruise?

https://github.com/openkruise/kruise

topology spread constraints

https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/

Pod Deletion Cost

https://kubernetes.io/docs/reference/labels-annotations-taints/#pod-deletion-cost

官網文檔

https://openkruise.io/zh-cn/docs/workloadspread.html

ChangeLog?文檔

https://github.com/openkruise/kruise/blob/v0.10.0/CHANGELOG.md

Zoom 會議鏈接

https://us02web.zoom.us/j/87059136652?pwd=NlI4UThFWXVRZkxIU0dtR1NINncrQT09

Zoom?記錄文檔

https://shimo.im/docs/gXqmeQOYBehZ4vqo

原文鏈接：https://developer.aliyun.com/article/789805?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的OpenKruise v0.10.0 版本发布：新增应用弹性拓扑管理、应用防护等能力的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。