OpenKruise：雙十一全鍊路應用的雲原生部署基座

【恭喜 OpenKruise 開源項目 在雙十一這個阿裡人的節日裡成為了 CNCF Sandbox 的一員！！】

一、基本介紹

OpenKruise（

https://github.com/openkruise/kruise

 ）是阿裡雲開源的 Kubernetes 擴充應用負載項目，同時也是阿裡巴巴經濟體上雲全面使用的部署基座。

基于目前“某些”開源項目的現狀，一定有人會問：阿裡内部大規模使用的真的是 Github 上這個項目嗎？

從圖中可以看出：Github 上的 OpenKruise 就是我們主體的上遊倉庫，而内部的下遊倉庫隻基于公共接口實作了極少數内部耦合功能（這部分代碼隻占據了不到 5%），也就是說阿裡巴巴内部運作的 OpenKruise 其中 95% 以上的代碼完全來自于社群倉庫。

有兩點值得說明：

1. 所有通用能力，我們都會直接基于開源倉庫開發和送出，然後再同步到内部環境；
2. 社群成員給 OpenKruise 貢獻的每一行代碼，都将運作在阿裡内部環境中；

截止 2020 年雙十一，阿裡巴巴内部已經運作着近十萬 OpenKruise 的 workload、管理着上百萬的容器。

二、什麼是應用負載

做上層業務的同學可能對 “應用負載（workload）” 缺乏概念，這裡先簡單做個介紹。

不知道你是否有好奇過，每一次應用擴縮容、釋出操作的背後是如何實作的呢？在雲原生的環境下，我們都是通過面向終态的方式去描述應用的部署需求（需要的機器數、鏡像版本等等），見下圖：

應用負載（workload）主要指的就是這個 YAML 定義和對應的控制器：

• 當應用擴縮容時，PaaS（運維平台）會修改上述 YAML 對象中的需求機器數（比如擴容 10 台改為 110，再縮容 5 台則改為 105），然後控制器就會按照 workload 期望的數量來調整實際運作的 Pod（容器）數量。
• 當應用觸發釋出或復原時，PaaS（運維平台）則會修改上述 YAML 對象中的鏡像版本和釋出政策，控制器就會按照給指定的釋出政策來将所有管理的 Pod（容器）重建為期望版本。

（這隻是一些便于了解的簡化描述，實際工作機制會複雜得多）

也就是說，應用負載（workload）管理着應用所有容器的生命周期。不僅應用擴容、縮容、釋出都依賴于 workload 的工作，workload 還負責持續維持應用運作時的 Pod（容器）數量，來保證持續有符合期望數量的執行個體在跑着。如果有主控端發生故障、上面的應用執行個體被驅逐，那麼 workload 會立即再為應用擴出新的容器。

三、為什麼說是全鍊路的部署基座

随着阿裡巴巴經濟體上雲，雙十一主體相關的電商類業務、以及中間件等應用都遷移到了雲原生環境下，統一使用 OpenKruise 的應用負載能力做部署。OpenKruise 提供了多種不同類型的 workload 來支援不同的部署方式：

• CloneSet：（無狀态應用）這是規模最大的部分，絕大部分泛電商業務都是通過 CloneSet 來部署釋出。
• Advanced StatefulSet：（有狀态應用）目前主要是用于中間件在雲原生環境的部署。
• SidecarSet：（sidecar 生命周期管理）可以将定義好的 sidecar 容器動态注入到建立的 Pod 中，雲上的運維容器、 mesh 容器都是通過這種機制加入到業務 Pod 中。
• Advanced DaemonSet：将主控端級别的守護程序部署到所有節點上，包括各種用于給業務容器配置網絡、存儲的基礎元件。

是以，我們看到從上層電商業務到中間件，再到運維容器、基礎元件，整個上下遊鍊路都是依賴于 OpenKruise 提供的 workload 做部署和運作。不管是應用運作時的機器數量、版本管理，還是緊急擴容、釋出等操作，都有 OpenKruise 無時無刻在維護着。

可以想象，如果 OpenKruise 出現了故障會發生什麼？

• 如果隻是控制器挂了，則應用擴縮容、釋出操作全量失敗
• 而如果控制器邏輯存在重大bug，比如數量或版本号計算錯誤，甚至可能引起業務容器大規模誤删或是更新為錯誤的版本

（當然，針對這類高危情況，我們做了很多重的防護措施，務必保障業務的穩定可用）

這就是阿裡巴巴的雲上部署基座，OpenKruise 承載了幾乎全量雙十一業務的部署管理與運維職責。

四、解決了什麼問題

OpenKruise 從何而來呢，或者說什麼問題或需求促使了 OpenKruise 的誕生呢？

當上雲成為大勢、當雲原生逐漸成為标準，我們卻發現 Kubernetes 原生提供的 workload 能力根本無法滿足阿裡巴巴超大規模業務場景的需求：

• 應用釋出時，所有容器都要飄移重建：對于我們來說幾乎無法接受，在釋出高峰期如果阿裡巴巴的大規模應用都在大規模重建，這是不管對于業務自身還是其他排程器、中間件、網絡/存儲元件都是一種災難性的壓力
• 無狀态應用負載（Deployment）無法灰階更新容器
• 有狀态應用負載（StatefulSet）無法并行更新容器
• 還有很多，不一一列舉......

在這種背景下，OpenKruise 出現了。我們通過或是全新開發（CloneSet、SidecarSet），或是相容性增強（Advanced StatefulSet、Advanced DaemonSet），來使得上層業務終于可以順利落地雲原生。

OpenKruise 首推的功能就是“原地更新”。通過這種能力，我們終于可以使應用釋出不需要将容器飄移重建，而是在原地、原 Pod 上隻更新需要更新的鏡像。這樣帶來的好處太多了：

1. 釋出效率大大提升。根據不完全統計資料，在大部分業務場景下原地更新至少比完全重建更新提升了 80% 以上的釋出速度：不僅省去了排程、配置設定網絡、配置設定遠端盤的耗時，連拉取新版本鏡像的時候都得益于node上已有舊鏡像、隻需要拉取較少的增量layer
2. 釋出前後 IP 不變、更新過程 Pod 網絡不斷，并且 Pod 中除了正在更新容器之外的其他容器都一直保持正常運作
3. Volume 不變，完全複用原容器的挂載裝置
4. 確定了叢集确定性，使全鍊路壓測通過後的叢集拓撲為大促提供保障

當然，除此之外我們還增強了許多其他的進階能力，滿足了許多種面向大規模場景下的業務訴求，本文不做一一介紹，但下圖可以看到 OpenKruise 與 Kubernetes 原生應用負載針對無狀态、有狀态應用的功能對比：

五、三位一體與展望

三位一體是哪三位？即支援 阿裡集團内部業務、雲産品、開源 應該互為一體。

正如開篇所說，OpenKruise 已經完成了社群開源，并且内外的版本做到幾乎完全一緻。除此之外，我們還将 OpenKruise 提供到了阿裡雲容器服務的應用目錄中，公有雲上的任意客戶都可以一鍵安裝和使用 OpenKruise。目前 ACK 上有不少已經在使用 OpenKruise 的客戶，包括鬥魚TV、申通、有贊等，而開源社群中攜程、Lyft等公司也都是 OpenKruise 的重度使用者和貢獻者。

OpenKruise 将基于阿裡巴巴超大規模場景錘煉出的雲原生應用負載能力開放出來，不僅在雲原生社群中補充了擴充應用負載的重要闆塊，還為雲上客戶提供了阿裡巴巴多年應用部署的管理經驗和雲原生化曆程的最佳實踐成果。

後續，OpenKruise 的重點包括但不限于以下幾個目标：

• 繼續将阿裡巴巴内部沉澱的通用雲原生應用自動化能力輸出，走可持續的三位一體發展戰略
• 深度挖掘細分領域的應用負載需求，比如我們正在探索針對 FaaS 場景的池化能力
•  與其他相關領域的開源産品做更緊密的結合，如 OAM、kubevela 等，打造更完整的雲原生應用體系

如果你對 OpenKruise 的發展有任何建議，可以在下方評論。另外，我們衷心歡迎每一位開源愛好者來參與 OpenKruise 的建設，共同打造雲原生領域最成熟、面向最大規模的應用自動化引擎。