OpenKruise 2021 规划：More than workloads
作者 | 王思宇（酒祝）
來源|阿里巴巴云原生公眾號
背景
OpenKruise 項(xiàng)目地址：https://github.com/openkruise/kruise
OpenKruise 是什么？它是阿里云開源的云原生應(yīng)用自動(dòng)化管理引擎，也是當(dāng)前托管在?Cloud Native Computing Foundation (CNCF) 下的 Sandbox 項(xiàng)目。它來自阿里巴巴多年來容器化、云原生的技術(shù)沉淀，是阿里內(nèi)部生產(chǎn)環(huán)境大規(guī)模應(yīng)用的基于 Kubernetes 之上的標(biāo)準(zhǔn)擴(kuò)展組件，一套緊貼上游社區(qū)標(biāo)準(zhǔn)、適應(yīng)互聯(lián)網(wǎng)規(guī)模化場景的技術(shù)理念與最佳實(shí)踐。
值得一提的是，阿里內(nèi)部使用的 OpenKruise 完全來自于社區(qū)版本、代碼幾乎完全一致。此外，OpenKruise 還被提供到了阿里云容器服務(wù)（ACK）的應(yīng)用目錄中，任意云上客戶都可以一鍵安裝和使用 OpenKruise。目前在 ACK 上使用 OpenKruise 的客戶主要包括斗魚 TV、申通等，而開源社區(qū)中攜程、Lyft、有贊等公司也都是 OpenKruise 的用戶和貢獻(xiàn)者（參考：用戶列表）。
版本回顧
從 2019 年 6 月開源伊始，OpenKruise 聚焦于云原生應(yīng)用部署/發(fā)布管理相關(guān)領(lǐng)域，擴(kuò)展應(yīng)用工作負(fù)載（workloads）。從最初的 Advanced StatefulSet、BroadcastJob，到“終極”的無狀態(tài)應(yīng)用負(fù)載 CloneSet、應(yīng)用 sidecar 容器管理“利器” SidecarSet、多可用區(qū)管理負(fù)載 UnitedDeployment 等。
-
CloneSet：提供了更加高效、確定可控的應(yīng)用管理和部署能力，支持優(yōu)雅原地升級、指定刪除、發(fā)布順序可配置、并行/灰度發(fā)布等豐富的策略，可以滿足更多樣化的應(yīng)用場景。
-
Advanced StatefulSet：基于原生 StatefulSet?之上的增強(qiáng)版本，默認(rèn)行為與原生完全一致，在此之外提供了原地升級、并行發(fā)布（最大不可用）、發(fā)布暫停等功能。
-
SidecarSet：對 sidecar 容器做統(tǒng)一管理，在滿足 selector 條件的 Pod 中注入指定的 sidecar 容器。
-
UnitedDeployment：通過多個(gè) subset workload 將應(yīng)用部署到多個(gè)可用區(qū)。
-
BroadcastJob: 配置一個(gè) job，在集群中所有滿足條件的 Node 上都跑一個(gè) Pod 任務(wù)。
-
Advanced DaemonSet：基于原生 DaemonSet 之上的增強(qiáng)版本，默認(rèn)行為與原生一致，在此之外提供了灰度分批、按 Node label 選擇、暫停、熱升級等發(fā)布策略。
-
AdvancedCronJob：一個(gè)擴(kuò)展的 CronJob 控制器，目前 template 模板支持配置使用 Job 或 BroadcastJob。
當(dāng)前 OpenKruise 豐富的 workloads 幾乎覆蓋了絕大多數(shù)通用的應(yīng)用部署場景，這也是目前社區(qū)用戶對 OpenKruise 的認(rèn)知。但 OpenKruise 并不僅僅局限于此，以面向云原生場景的應(yīng)用自動(dòng)化為目標(biāo)，必然不止是“部署”那么簡單（當(dāng)然它并不簡單）。
規(guī)劃一覽
在 2021 上半年，OpenKruise 新版本會(huì)先圍繞應(yīng)用風(fēng)險(xiǎn)防控、Operator 運(yùn)行時(shí)擴(kuò)展、daemon 旁路擴(kuò)展等方面展開，而在此之后，還有增強(qiáng)版本的 HPA、無代碼控制器尚在排期中。
1. 風(fēng)險(xiǎn)防控
面向終態(tài)的自動(dòng)化是一把 “雙刃劍”，它既為應(yīng)用帶來了聲明式的部署能力，同時(shí)也潛在地會(huì)將一些誤操作行為被終態(tài)化放大。在發(fā)生操作故障時(shí)副本數(shù)維持、版本一致性、級聯(lián)刪除等機(jī)制反而很可能導(dǎo)致爆炸半徑擴(kuò)大，例如：
-
錯(cuò)誤地刪除一個(gè)（多個(gè)） CRD，所有對應(yīng)的 CR 都被清理掉。
-
錯(cuò)誤地刪除一個(gè)（多個(gè)） workload，其下所有 Pod 都被級聯(lián)刪除。
-
發(fā)布時(shí)在 workload 中配置錯(cuò)了策略，超過預(yù)期數(shù)量（甚至全部）的 Pod 被同時(shí)升級。
-
批量給 Node 打了一個(gè)錯(cuò)誤的 taint，導(dǎo)致上面所有 Pod 被驅(qū)逐。
-
因?yàn)楦鞣N各樣原因引發(fā)的 Pod 批量被刪除 ......
在實(shí)際的生產(chǎn)集群中存在了各種各樣的高危操作，OpenKruise 計(jì)劃通過一系列可選的風(fēng)險(xiǎn)防控機(jī)制來為應(yīng)用最終的可用性做兜底：
-
定義“禁止級聯(lián)刪除”標(biāo)簽：帶這個(gè)標(biāo)簽的 CRD、Workload 被刪除時(shí)，Kruise 會(huì)校驗(yàn)如果尚存在 CR 或運(yùn)行中的 Pod 則拒絕刪除。
-
定義 Pod 刪除流控策略：用戶可以定義一個(gè)集群中 Pod 刪除的限流值，比如 1 分鐘、10? 分鐘、1 小時(shí)、1 天等時(shí)間窗口內(nèi)最多允許刪除多少個(gè) Pod，一旦超出閾值則更多的 Pod 刪除請求會(huì)被拒絕（可以放大限流值解決）。
-
新增 PodUnavailableBudget（PUB）自定義資源：原生 PDB 只能限制 Pod 驅(qū)逐，無法限制刪除等操作，局限性非常大。而 PUB 將會(huì)采取統(tǒng)一機(jī)制，對 Pod 刪除/驅(qū)逐/原地升級 等所有會(huì)導(dǎo)致 Pod 變?yōu)椴豢捎脿顟B(tài)的操作做校驗(yàn)，一旦某個(gè)應(yīng)用的不可用數(shù)量超過（或可用數(shù)量低于）策略閾值，PUB 會(huì)拒絕這個(gè)應(yīng)用下更多的 Pod 操作。
-
支持為 workload 自動(dòng)生成 PUB/PDB：一般來說用戶只會(huì)配置自身應(yīng)用的 workload，不管使用的是原生 Deployment 還是 OpenKruise 的 CloneSet/Advanced StatefulSet，其實(shí)只是針對應(yīng)用部署/發(fā)布的定義。我們希望 PUB/PDB 能逐漸成為與每個(gè) workload 配對的保護(hù)策略，通過自動(dòng)匹配生成，盡量在用戶無感（或極小改動(dòng)）的情況下得到完善的應(yīng)用運(yùn)行時(shí)保護(hù)。
2. kruise-daemon
過去 OpenKruise 只是作為一個(gè)中心 kruise-controller-manager 組件運(yùn)行、提供 controller/webhook 服務(wù)，因此其實(shí)對于單機(jī)側(cè)的操作無法介入。接下來，我們會(huì)引入 kruise-daemon 作為單機(jī)側(cè)組件，支持在 Kubelet 之外的旁路實(shí)現(xiàn)擴(kuò)展：
-
新增鏡像預(yù)熱：通過定義 NodeImage 和 ImagePullJob 實(shí)現(xiàn)每臺 Node 層面需要執(zhí)行預(yù)熱的列表和預(yù)熱狀態(tài)上報(bào)，以及 ImagePullJob 來指定集群中按什么范圍來做規(guī)模化預(yù)熱。
-
通過鏡像預(yù)熱實(shí)現(xiàn)發(fā)布加速：在 CloneSet、Advanced StatefulSet 等 workload 做原地升級時(shí)，Pod 不會(huì)發(fā)生重建和飄移，仍然在原先節(jié)點(diǎn)上做容器重建升級。因此當(dāng)用戶做灰度（partition）原地升級時(shí)，OpenKruise 可以提前在未升級 Pod 所在節(jié)點(diǎn)做新版本鏡像預(yù)熱，這樣在后續(xù) Pod 做升級的過程中就省去了拉鏡像所花費(fèi)的時(shí)間，可以有效提升整體應(yīng)用發(fā)布的速度和效率。
-
支持指定容器重啟：目前在對 Pod 中某個(gè)容器原地升級時(shí)，Kubelet 會(huì)執(zhí)行容器重建操作，我們看到不少用戶也依賴于這個(gè)能力做重啟。但原地升級是必須修改 image 鏡像的，是否有辦法不修改鏡像實(shí)現(xiàn)重啟呢？后續(xù) kruise-daemon 會(huì)支持此類操作，不過對于 Pod 容器啟動(dòng)、停止順序等需求還是無法代替 Kubelet 實(shí)現(xiàn)的。
-
提供單機(jī)調(diào)度優(yōu)化：通過在調(diào)整應(yīng)用 Pod 的 cgroup 系統(tǒng)來實(shí)現(xiàn)單機(jī)側(cè)的資源最大化利用和應(yīng)用 SLO 保障。這是一個(gè)探索性的方向，目前尚不確定是否會(huì)于 2021 在社區(qū)提供穩(wěn)定版實(shí)現(xiàn)。
3. ControllerMesh
Kubernetes 能擊敗 Mesos/Swarm 等對標(biāo)產(chǎn)品、成為容器集群調(diào)度管理引擎的事實(shí)標(biāo)準(zhǔn)，其強(qiáng)大而又靈活的擴(kuò)展能力功不可沒。Operator 既是一種特殊的應(yīng)用，也是不少有狀態(tài)應(yīng)用的自動(dòng)化管理者。而過去社區(qū)整體 Operator 趨勢還停留在數(shù)量野蠻增長、周邊運(yùn)行時(shí)機(jī)制卻無太大進(jìn)步，這就導(dǎo)致各類 Controller/Operator 的數(shù)量和復(fù)雜性也逐漸增加，變得越來越難以理解和管理。
單主問題帶來的控制器單點(diǎn)運(yùn)行，無法負(fù)載均衡、無法水平擴(kuò)展；版本升級一次性切換、無法灰度，A/B 測試、金絲雀等模式都無法實(shí)現(xiàn)。另外控制器潛在的爆炸半徑大，也沒有系統(tǒng)性的防護(hù)、速率限制、熔斷機(jī)制。其他可觀測性方面的監(jiān)控、追蹤、度量等也都缺乏統(tǒng)一的方式。
我們希望設(shè)計(jì)一個(gè)方案，能提供對整個(gè)控制器運(yùn)行平面的行為洞察和操作控制的能力，以及一個(gè)完整的滿足 Controller/Operator 應(yīng)用各種部署管理與運(yùn)行時(shí)需求的解決方案。這套方案將實(shí)現(xiàn) Operator 分片運(yùn)行，從而帶來水平擴(kuò)展、灰度升級等能力，除此之外還將會(huì)提供故障注入、更靈活的租戶隔離、安全防護(hù)、可觀測性等系統(tǒng)性的平臺能力。
總結(jié)
目前版本的 OpenKruise 已經(jīng)提供了豐富的 workloads 與部署發(fā)布策略，幾乎覆蓋了絕大多數(shù)通用的應(yīng)用場景。值此 2021 “牛轉(zhuǎn)乾坤”之際，OpenKruise 打出了“More than workloads”口號，在新的一年里 OpenKruise 將走出現(xiàn)有的應(yīng)用負(fù)載領(lǐng)域，覆蓋更多云原生場景、挖掘更深層面的應(yīng)用自動(dòng)化需求。我們歡迎每一位云原生愛好者共同參與 OpenKruise 的建設(shè)，共同打造業(yè)界頂尖的云原生應(yīng)用自動(dòng)化引擎！
- Github：https://github.com/openkruise/kruise
- Official：https://openkruise.io/
- 釘釘交流群：釘釘搜索群號 23330762
原文鏈接：https://developer.aliyun.com/article/780875?
版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。 與50位技術(shù)專家面對面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖總結(jié)
以上是生活随笔為你收集整理的OpenKruise 2021 规划：More than workloads的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Flink Forward Asia 2
- 下一篇： 如何量化技术团队的效能？