![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/c708c66deb734b78bcc6745dc6f435f9.png)

作者 | 王思宇（酒祝）
來源|[阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/-5mRxIlmNcEOyH05a45c5w)

# 背景

> OpenKruise 專案地址：[https://github.com/openkruise/kruise](https://github.com/openkruise/kruise)

OpenKruise 是什麼？它是阿里雲開源的雲原生應用自動化管理引擎，也是當前託管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 專案。它來自阿里巴巴多年來容器化、雲原生的技術沉澱，是阿里內部生產環境大規模應用的基於 Kubernetes 之上的標準擴充套件元件，一套緊貼上游社群標準、適應網際網路規模化場景的技術理念與最佳實踐。

值得一提的是，阿里內部使用的 OpenKruise 完全來自於社群版本、程式碼幾乎完全一致。此外，OpenKruise 還被提供到了阿里雲容器服務（ACK）的應用目錄中，任意雲上客戶都可以一鍵安裝和使用 OpenKruise。目前在 ACK 上使用 OpenKruise 的客戶主要包括鬥魚 TV、申通等，而開源社群中攜程、Lyft、有贊等公司也都是 OpenKruise 的使用者和貢獻者（參考：[使用者列表](https://github.com/openkruise/kruise/issues/289)）。

# 版本回顧

從 2019 年 6 月開源伊始，OpenKruise 聚焦於雲原生應用部署/釋出管理相關領域，擴充套件應用工作負載（workloads）。從最初的 Advanced StatefulSet、BroadcastJob，到“終極”的無狀態應用負載 CloneSet、應用 sidecar 容器管理“利器” SidecarSet、多可用區管理負載 UnitedDeployment 等。

- [CloneSet](https://openkruise.io/zh-cn/docs/cloneset.html)：提供了更加高效、確定可控的應用管理和部署能力，支援優雅原地升級、指定刪除、釋出順序可配置、並行/灰度釋出等豐富的策略，可以滿足更多樣化的應用場景。

- [Advanced StatefulSet](https://openkruise.io/zh-cn/docs/advanced_statefulset.html)：基於原生 [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) 之上的增強版本，預設行為與原生完全一致，在此之外提供了原地升級、並行釋出（最大不可用）、釋出暫停等功能。

- [SidecarSet](https://openkruise.io/zh-cn/docs/sidecarset.html)：對 sidecar 容器做統一管理，在滿足 selector 條件的 Pod 中注入指定的 sidecar 容器。

- [UnitedDeployment](https://openkruise.io/zh-cn/docs/uniteddeployment.html)：透過多個 subset workload 將應用部署到多個可用區。

- [BroadcastJob](https://openkruise.io/zh-cn/docs/broadcastjob.html): 配置一個 job，在叢集中所有滿足條件的 Node 上都跑一個 Pod 任務。

- [Advanced DaemonSet](https://openkruise.io/zh-cn/docs/advanced_daemonset.html)：基於原生 DaemonSet 之上的增強版本，預設行為與原生一致，在此之外提供了灰度分批、按 Node label 選擇、暫停、熱升級等釋出策略。

- [AdvancedCronJob](https://openkruise.io/zh-cn/docs/advancedcronjob.html)：一個擴充套件的 CronJob 控制器，目前 template 模板支援配置使用 Job 或 BroadcastJob。

當前 OpenKruise 豐富的 workloads 幾乎覆蓋了絕大多數通用的應用部署場景，這也是目前社群使用者對 OpenKruise 的認知。但 OpenKruise 並不僅僅侷限於此，以面向雲原生場景的應用自動化為目標，必然不止是“部署”那麼簡單（當然它並不簡單）。

# 規劃一覽

在 2021 上半年，OpenKruise 新版本會先圍繞應用風險防控、Operator 執行時擴充套件、daemon 旁路擴充套件等方面展開，而在此之後，還有增強版本的 HPA、無程式碼控制器尚在排期中。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/9c2750788d4345cb8d05787829b5c59f.png)

## 1. 風險防控

面向終態的自動化是一把 “雙刃劍”，它既為應用帶來了宣告式的部署能力，同時也潛在地會將一些誤操作行為被終態化放大。在發生操作故障時副本數維持、版本一致性、級聯刪除等機制反而很可能導致爆炸半徑擴大，例如：

- 錯誤地刪除一個（多個） CRD，所有對應的 CR 都被清理掉。

- 錯誤地刪除一個（多個） workload，其下所有 Pod 都被級聯刪除。

- 釋出時在 workload 中配置錯了策略，超過預期數量（甚至全部）的 Pod 被同時升級。

- 批次給 Node 打了一個錯誤的 taint，導致上面所有 Pod 被驅逐。

- 因為各種各樣原因引發的 Pod 批次被刪除 ......

在實際的生產叢集中存在了各種各樣的高危操作，OpenKruise 計劃透過一系列可選的風險防控機制來為應用最終的可用性做兜底：

- 定義**“禁止級聯刪除”**標籤：帶這個標籤的 CRD、Workload 被刪除時，Kruise 會校驗如果尚存在 CR 或執行中的 Pod 則拒絕刪除。

- 定義 **Pod 刪除流控策略**：使用者可以定義一個叢集中 Pod 刪除的限流值，比如 1 分鐘、10  分鐘、1 小時、1 天等時間視窗內最多允許刪除多少個 Pod，一旦超出閾值則更多的 Pod 刪除請求會被拒絕（可以放大限流值解決）。

- 新增 **PodUnavailableBudget（PUB）**自定義資源：原生 PDB 只能限制 Pod 驅逐，無法限制刪除等操作，侷限性非常大。而 PUB 將會採取統一機制，對 Pod 刪除/驅逐/原地升級 等所有會導致 Pod 變為不可用狀態的操作做校驗，一旦某個應用的不可用數量超過（或可用數量低於）策略閾值，PUB 會拒絕這個應用下更多的 Pod 操作。

- 支援**為 workload 自動生成 PUB/PDB**：一般來說使用者只會配置自身應用的 workload，不管使用的是原生 Deployment 還是 OpenKruise 的 CloneSet/Advanced StatefulSet，其實只是針對應用部署/釋出的定義。我們希望 PUB/PDB 能逐漸成為與每個 workload 配對的保護策略，透過自動匹配生成，儘量在使用者無感（或極小改動）的情況下得到完善的應用執行時保護。

## 2. kruise-daemon

過去 OpenKruise 只是作為一箇中心 kruise-controller-manager 元件執行、提供 controller/webhook 服務，因此其實對於單機側的操作無法介入。接下來，我們會引入 kruise-daemon 作為單機側元件，支援在 Kubelet 之外的旁路實現擴充套件：

- 新增**映象預熱**：透過定義 NodeImage 和 ImagePullJob 實現每臺 Node 層面需要執行預熱的列表和預熱狀態上報，以及 ImagePullJob 來指定叢集中按什麼範圍來做規模化預熱。

- 透過映象預熱實現**釋出加速**：在 CloneSet、Advanced StatefulSet 等 workload 做原地升級時，Pod 不會發生重建和飄移，仍然在原先節點上做容器重建升級。因此當使用者做灰度（partition）原地升級時，OpenKruise 可以提前在未升級 Pod 所在節點做新版本映象預熱，這樣在後續 Pod 做升級的過程中就省去了拉映象所花費的時間，可以有效提升整體應用釋出的速度和效率。

- 支援**指定容器重啟**：目前在對 Pod 中某個容器原地升級時，Kubelet 會執行容器重建操作，我們看到不少使用者也依賴於這個能力做重啟。但原地升級是必須修改 image 映象的，是否有辦法不修改映象實現重啟呢？後續 kruise-daemon 會支援此類操作，不過對於 Pod 容器啟動、停止順序等需求還是無法代替 Kubelet 實現的。

- 提供**單機排程最佳化**：透過在調整應用 Pod 的 cgroup 系統來實現單機側的資源最大化利用和應用 SLO 保障。這是一個探索性的方向，目前尚不確定是否會於 2021 在社群提供穩定版實現。

## 3. ControllerMesh

Kubernetes 能擊敗 Mesos/Swarm 等對標產品、成為容器叢集排程管理引擎的事實標準，其強大而又靈活的擴充套件能力功不可沒。Operator 既是一種特殊的應用，也是不少有狀態應用的自動化管理者。而過去社群整體 Operator 趨勢還停留在數量野蠻增長、周邊執行時機制卻無太大進步，這就導致各類 Controller/Operator 的數量和複雜性也逐漸增加，變得越來越難以理解和管理。

單主問題帶來的控制器單點執行，無法負載均衡、無法水平擴充套件；版本升級一次性切換、無法灰度，A/B 測試、金絲雀等模式都無法實現。另外控制器潛在的爆炸半徑大，也沒有系統性的防護、速率限制、熔斷機制。其他可觀測性方面的監控、追蹤、度量等也都缺乏統一的方式。

我們希望設計一個方案，能提供對整個控制器執行平面的行為洞察和操作控制的能力，以及一個完整的滿足 Controller/Operator 應用各種部署管理與執行時需求的解決方案。這套方案將實現 Operator 分片執行，從而帶來水平擴充套件、灰度升級等能力，除此之外還將會提供故障注入、更靈活的租戶隔離、安全防護、可觀測性等系統性的平臺能力。

# 總結

目前版本的 OpenKruise 已經提供了豐富的 workloads 與部署釋出策略，幾乎覆蓋了絕大多數通用的應用場景。值此 2021 “牛轉乾坤”之際，OpenKruise 打出了“More than workloads”口號，在新的一年裡 OpenKruise 將走出現有的應用負載領域，覆蓋更多雲原生場景、挖掘更深層面的應用自動化需求。我們歡迎每一位雲原生愛好者共同參與 OpenKruise 的建設，共同打造業界頂尖的雲原生應用自動化引擎！

- Github：[https://github.com/openkruise/kruise](https://github.com/openkruise/kruise)
- Official：[https://openkruise.io/](https://openkruise.io/)
- 釘釘交流群：釘釘搜尋群號 23330762

OpenKruise 2021 規劃曝光：More than workloads

相關文章