作者 | 王思宇（酒祝）
來源|
阿裡巴巴雲原生公衆号背景
OpenKruise 項目位址： https://github.com/openkruise/kruise
OpenKruise 是什麼？它是阿裡雲開源的雲原生應用自動化管理引擎，也是目前托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 項目。它來自阿裡巴巴多年來容器化、雲原生的技術沉澱，是阿裡内部生産環境大規模應用的基于 Kubernetes 之上的标準擴充元件，一套緊貼上遊社群标準、适應網際網路規模化場景的技術理念與最佳實踐。
值得一提的是，阿裡内部使用的 OpenKruise 完全來自于社群版本、代碼幾乎完全一緻。此外，OpenKruise 還被提供到了阿裡雲容器服務（ACK）的應用目錄中，任意雲上客戶都可以一鍵安裝和使用 OpenKruise。目前在 ACK 上使用 OpenKruise 的客戶主要包括鬥魚 TV、申通等，而開源社群中攜程、Lyft、有贊等公司也都是 OpenKruise 的使用者和貢獻者（參考：
使用者清單）。
版本回顧
從 2019 年 6 月開源伊始，OpenKruise 聚焦于雲原生應用部署/釋出管理相關領域，擴充應用工作負載（workloads）。從最初的 Advanced StatefulSet、BroadcastJob，到“終極”的無狀态應用負載 CloneSet、應用 sidecar 容器管理“利器” SidecarSet、多可用區管理負載 UnitedDeployment 等。
- CloneSet ：提供了更加高效、确定可控的應用管理和部署能力，支援優雅原地更新、指定删除、釋出順序可配置、并行/灰階釋出等豐富的政策，可以滿足更多樣化的應用場景。
- Advanced StatefulSet ：基于原生 StatefulSet 之上的增強版本，預設行為與原生完全一緻，在此之外提供了原地更新、并行釋出（最大不可用）、釋出暫停等功能。
- SidecarSet ：對 sidecar 容器做統一管理，在滿足 selector 條件的 Pod 中注入指定的 sidecar 容器。
- UnitedDeployment ：通過多個 subset workload 将應用部署到多個可用區。
- BroadcastJob : 配置一個 job，在叢集中所有滿足條件的 Node 上都跑一個 Pod 任務。
- Advanced DaemonSet ：基于原生 DaemonSet 之上的增強版本，預設行為與原生一緻，在此之外提供了灰階分批、按 Node label 選擇、暫停、熱更新等釋出政策。
- AdvancedCronJob ：一個擴充的 CronJob 控制器，目前 template 模闆支援配置使用 Job 或 BroadcastJob。
目前 OpenKruise 豐富的 workloads 幾乎覆寫了絕大多數通用的應用部署場景，這也是目前社群使用者對 OpenKruise 的認知。但 OpenKruise 并不僅僅局限于此，以面向雲原生場景的應用自動化為目标，必然不止是“部署”那麼簡單（當然它并不簡單）。
規劃一覽
在 2021 上半年，OpenKruise 新版本會先圍繞應用風險防控、Operator 運作時擴充、daemon 旁路擴充等方面展開，而在此之後，還有增強版本的 HPA、無代碼控制器尚在排期中。
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：
- Official： https://openkruise.io/
- 釘釘交流群：釘釘搜尋群号 23330762