前言

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/v1beta1kind: StatefulSetspec:  # ...  replicas: 4  reserveOrdinals:  - 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/v1alpha1kind: CloneSetspec:  # ...  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/v1alpha1kind: AdvancedCronJobspec:  template:    # Option 1: use jobTemplate, which is equivalent to original CronJob    jobTemplate:      # ...    # Option 2: use broadcastJobTemplate, which will create a BroadcastJob object when cron schedule triggers    broadcastJobTemplate:      # ...    # 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 叢集中、都將共同支撐阿里巴巴全球頂尖規模的雲原生應用場景！