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

前言

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

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

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

新版本概覽

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

1. Advanced StatefulSet

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

官網(wǎng)文檔：https://openkruise.io/zh-cn/docs/advanced_statefulset.html

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

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

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

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

• 設置了 conversion 字段，其中指定通過 kruise-webhook-service 來提供 convert 服務，這個 service 后端掛載的其實就是 kruise-controller-manager 節(jié)點。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 序號保留

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

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

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

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

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

• 如果要把 Pod-3 做遷移并保留序號，則把 3 追加到 reserveOrdinals 列表中。控制器會把 Pod-3 刪除并創(chuàng)建 Pod-5（此時運行中 Pod 為 [0,2,4,5]）。

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

2. CloneSet

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

官網(wǎng)文檔：http://openkruise.io/zh-cn/docs/cloneset.html

1）partition 支持百分比

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

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

如果在發(fā)布過程中設置了 partition：

• 如果是數(shù)字，控制器會將 (replicas - partition) 數(shù)量的 Pod 更新到最新版本。

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

2）其他優(yōu)化點

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

• 不滿足 selector 匹配條件的 Pod 自動去除 owner reference。

• 解決 resourceVersionExpectation 偶發(fā)的 race condition。

• 解決使用了 gracePeriodSeconds 優(yōu)雅原地升級時連續(xù)升級的版本覆蓋問題。

3. AdvancedCronJob（新增控制器）

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

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

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 一樣創(chuàng)建 Job 執(zhí)行任務。

• broadcastJobTemplate：周期性創(chuàng)建 BroadcastJob?執(zhí)行任務。

4. Webhook 自運維控制器

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

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

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

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

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

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

總結

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

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

總結

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

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