OpenKruise 2021 规划：More than workloads
作者 | 王思宇（酒祝）
來源|阿里巴巴云原生公眾號
背景
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 來指定集群中按什么范圍來做規?；A熱。
-
通過鏡像預熱實現發布加速：在 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
- Official：https://openkruise.io/
- 釘釘交流群：釘釘搜索群號 23330762
原文鏈接：https://developer.aliyun.com/article/780875?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。 與50位技術專家面對面20年技術見證，附贈技術全景圖總結
以上是生活随笔為你收集整理的OpenKruise 2021 规划：More than workloads的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Flink Forward Asia 2
- 下一篇： 如何量化技术团队的效能？