簡介：OpenKruise 是阿里云開源的大規模應用自動化管理引擎，在功能上對標了 Kubernetes 原生的 Deployment/StatefulSet 等控制器，但 OpenKruise 提供了更多的增強功能，如：優雅原地升級、發布優先級/打散策略、多可用區 workload 抽象管理、統一 sidecar 容器注入管理等，這些都是經歷了阿里巴巴超大規模應用場景打磨出的核心能力，這些 feature 幫助我們應對了更加多樣化的部署環境和需求、為集群維護者和應用開發者帶來了更加靈活的部署發布組合策略。

作者 | 王思宇（酒祝）
來源|阿里巴巴云原生公眾號

前言

OpenKruise 是阿里云開源的大規模應用自動化管理引擎，在功能上對標了 Kubernetes 原生的 Deployment/StatefulSet 等控制器，但 OpenKruise 提供了更多的增強功能，如：優雅原地升級、發布優先級/打散策略、多可用區 workload 抽象管理、統一 sidecar 容器注入管理等，這些都是經歷了阿里巴巴超大規模應用場景打磨出的核心能力，這些 feature 幫助我們應對了更加多樣化的部署環境和需求、為集群維護者和應用開發者帶來了更加靈活的部署發布組合策略。

目前在阿里巴巴內部云原生環境中，應用全部統一使用 OpenKruise 的能力做 Pod 部署、發布管理，而不少業界公司和阿里云上的客戶由于 K8s 原生 Deployment 等負載不能完全滿足需求，也轉而采用 OpenKruise 作為應用部署載體。我們希望 OpenKruise 可以讓每一位 Kubernetes 開發者和阿里云上的用戶，都能便捷地使用上阿里巴巴內部云原生應用所統一使用的部署發布能力！

附：OpenKruise 在阿里巴巴的應用參考文章

新版本概覽

Kruise 在 2020 年 11 月 16 日發布了最新的 v0.7.0 版本，包括了一些主體功能和優化迭代。以下內容將對新版本做一個整體的概覽介紹。

1. Advanced StatefulSet

Advanced StatefulSet 基于原生 StatefulSet 上增強了發布能力，比如 maxUnavailable 并行發布、原地升級等。

官網文檔：https://openkruise.io/zh-cn/docs/advanced_statefulset.html?

1）OpenKruise 中首個進入 v1beta1 版本的?CRD

過去 OpenKruise 中提供的自定義 workload 均是 v1alpha1 版本，隨著阿里巴巴內部和眾多社區用戶的大規模使用，我們會逐漸將穩定的能力升級到更高的版本。本次 Advanced StatefulSet 是首個進入 v1beta1 的 CRD，后續 CloneSet、SidecarSet 等資源也會逐漸跟進。

那么對于過去使用 v1alpha1 版本 Advanced StatefulSet 的用戶，升級到 v1beta1 版本是否會有問題呢？這里明確地告訴大家：是沒有風險的。不僅存量的 Advanced StatefulSet 對象會自動轉到 v1beta1 版本，而且用戶還可以繼續沿用 v1alpha1 的接口和客戶端來操作新版本的對象。

首先看圖中新版本 Advanced StatefulSet 的 CRD 定義：

• 設置了 conversion 字段，其中指定通過 kruise-webhook-service 來提供 convert 服務，這個 service 后端掛載的其實就是 kruise-controller-manager 節點。Kruise 的 MutatingWebhookConfiguration/ValidationWebhookConfiguration 中配置的也是這個 service。
• versions 列表中目前有 v1alpha1 和 v1beta1 兩個版本，其中后者的 storage 設置為 true，表示在 etcd 中存儲的是這個版本。

再來看圖中的 conversion 鏈路：

• 當用戶直接使用 v1beta1 接口操作 Advanced StatefulSet，不需要 conversion 轉換，apiserver 直接和 etcd 交互。

• 如果用戶使用老版本的 v1alpha1 接口操作 Advanced StatefulSet：

  • 寫操作：apiserver 會先調用 webhook 將用戶寫的 v1alpha1 對象轉為 v1beta1，并寫入 etcd。
  • 讀操作：apiserver 將來自于 etcd 的 v1beta1 對象通過 webhook 轉為 v1alpha1，再返回給用戶。

對多版本 conversion 的邏輯有興趣的同學可以閱讀源碼：https://github.com/openkruise/kruise/blob/master/apis/apps/v1alpha1/statefulset_conversion.go

2）Ordinal 序號保留

通常來說，不管是社區原生 StatefulSet 或是 Advanced StatefulSet，擴容出來的 Pod 以及 PVC 都是連續序號。比如，對于一個 replicas=4 的 StatefulSet，那么創建出來的 Pod 序號則是 [0,1,2,3]。
但有些情況下，用戶需要指定刪除一個序號的 Pod，并希望 StatefulSet 暫時跳過這個序號。這種需求在使用 Local PV 的場景下尤為突出：當一些節點出現故障的時候，如果只是刪除原 Pod，那么當重建出相同序號的 Pod 復用了原有的 PVC/PV，還是會調度到原來的節點上。

從 Advanced StatefulSet 的 v1beta1 版本開始（對應 Kruise 版本 >= v0.7.0），我們提供了序號保留功能：

apiVersion: apps.kruise.io/v1beta1 kind: StatefulSet spec:# ...replicas: 4reserveOrdinals:- 1

通過在 reserveOrdinals 字段中寫入需要保留的序號，Advanced StatefulSet 會自動跳過創建這些序號的 Pod。如果 Pod 已經存在，則會被刪除。注意，spec.replicas 是期望運行的 Pod 數量，spec.reserveOrdinals 是要跳過的序號。

因此，對于一個 replicas=4, reserveOrdinals=[1] 的 Advanced StatefulSet，實際運行的 Pod 序號為 [0,2,3,4]。

• 如果要把 Pod-3 做遷移并保留序號，則把 3 追加到 reserveOrdinals 列表中。控制器會把 Pod-3 刪除并創建 Pod-5（此時運行中 Pod 為 [0,2,4,5]）。
• 如果只想刪除 Pod-3，則把 3 追加到 reserveOrdinals 列表并同時把 replicas 減一修改為 3。控制器會把 Pod-3 刪除（此時運行中 Pod 為 [0,2,4]）。

2. CloneSet

CloneSet 控制器提供了高效管理無狀態應用的能力，它可以對標原生的 Deployment，但相比之下，CloneSet 提供了很多增強功能。

官網文檔：http://openkruise.io/zh-cn/docs/cloneset.html?

1）partition 支持百分比

CloneSet 中支持使用 partition 字段控制發布時的灰度數量，過去版本中這個字段只能設置為一個絕對值，而從 v0.7.0 開始可以設置為百分比。它的語義是：保留舊版本 Pod 的數量或百分比，默認為 0。

apiVersion: apps.kruise.io/v1alpha1 kind: CloneSet spec:# ...updateStrategy:partition: 80% # 表示只將 20% 比例的 Pod 升級為新版本；或者也可以設置為保留舊版本數量的絕對值

如果在發布過程中設置了 partition：

• 如果是數字，控制器會將 (replicas - partition) 數量的 Pod 更新到最新版本。
• 如果是百分比，控制器會將 (replicas * (100% - partition)) 數量的 Pod 更新到最新版本。

2）其他優化點

解決了過去一些邊緣場景下的 bug（其中要感謝社區同學們的反饋和貢獻）：

• 不滿足 selector 匹配條件的 Pod 自動去除 owner reference。
• 解決 resourceVersionExpectation 偶發的 race condition。
• 解決使用了 gracePeriodSeconds 優雅原地升級時連續升級的版本覆蓋問題。

3. AdvancedCronJob（新增控制器）

AdvancedCronJob 是 v0.7.0 中新增的控制器，它一個 CronJob 的擴展版本，感謝來自 Spectro Cloud 的 rishi-anand 的貢獻！

原生 CronJob 只支持創建 Job 執行任務，而 AdvancedCronJob 允許用戶設置多種不同類型的 template，即用戶可以配置 schedule 規則周期性創建 Job 或 BroadcastJob 來執行任務（后者可以分發 Job 到所有或特定 node 上執行任務）。

apiVersion: apps.kruise.io/v1alpha1 kind: AdvancedCronJob spec:template:# Option 1: use jobTemplate, which is equivalent to original CronJobjobTemplate:# ...# Option 2: use broadcastJobTemplate, which will create a BroadcastJob object when cron schedule triggersbroadcastJobTemplate:# ...# Options 3(future): ...

• jobTemplate：與原生 CronJob 一樣創建 Job 執行任務。
• broadcastJobTemplate：周期性創建 BroadcastJob?執行任務。

4. Webhook 自運維控制器

Kruise 運行的 kruise-controller-manager 組件，其中包含了多個 controller 和 webhook。

了解 webhook 的同學應該知道，它需要生成一套完整的 TLS cert 證書，webhook server 端的 HTTPS 服務啟動時使用這個證書，同時要把 ca 證書寫到 MutatingWebhookConfiguration、ValidatingWebhookConfiguration、CRD conversion 的 caBundle 中。

因此，對于如何自動生成證書、配置到上述 configuration 資源中，以及如果 configuration 被重置后如何重新寫入，都是當前寫 webhook 會遇到的運維難題。

Kruise 最新版本中實現了一個 webhook controller，這個控制器支持對 Kruise 自身的 TLS certs 以及相關配置資源做自運維。即：自動生成證書 -> 存儲到 secret -> 寫到本地供 HTTPS 服務啟動使用 -> 將 ca cert 寫入 MutatingWebhookConfiguration / ValidatingWebhookConfiguration / CRD conversion，并持續 list watch 這些資源，一旦發生變化，重新刷入 ca 證書。

有興趣的同學可以看源碼：https://github.com/openkruise/kruise/blob/master/pkg/webhook/util/controller/webhook_controller.go

后續我們也會將這部分功能抽出到一個公共倉庫中，大家在編寫 webhook 的時候可以很方便地復用這套 webhook 自運維能力。

總結

后續，OpenKruise 還會持續在應用自動化上做出更深的優化，本月底會開放 OpenKruise 下一步的 Roadmap 規劃，我們將不再局限于 workload 應用管理能力，而會擴展到更多風險防控、operator 增強等領域。

同時也歡迎每一位云原生愛好者共同參與 OpenKruise 的建設。與其他開源項目不同，OpenKruise 并不是阿里內部代碼的復刻，恰恰相反，OpenKruise Github 倉庫是阿里內部代碼庫的 upstream。因此，你貢獻的每一行代碼，都將運行在阿里內部的所有 Kubernetes 集群中、都將共同支撐阿里巴巴全球頂尖規模的云原生應用場景！釘釘搜索群號：23330762，即可加入交流群！

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

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

總結

以上是生活随笔為你收集整理的OpenKruise v0.7.0发布：增加周期任务分发控制器的全部內容，希望文章能夠幫你解決所遇到的問題。

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