OpenKruise v0.7.0 版本發佈：新增週期任務分發控制器

做者 | 王思宇（酒祝）
來源|阿里巴巴雲原生公衆號

前言

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]。<br />但有些狀況下，用戶須要指定刪除一個序號的 Pod，並但願 StatefulSet 暫時跳過這個序號。這種需求在使用 Local PV 的場景下尤其突出：當一些節點出現故障的時候，若是隻是刪除原 Pod，那麼當重建出相同序號的 Pod 複用了原有的 PVC/PV，仍是會調度到原來的節點上。

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

apiVersion: apps.kruise.io/v1beta1
kind: StatefulSet
spec:
  # ...
  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/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 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 集羣中、都將共同支撐阿里巴巴全球頂尖規模的雲原生應用場景！