來源 | [阿里巴巴雲原生公眾號](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247496496&idx=1&sn=68e4975841b7cd8387ba42bfe9c8c99f&chksm=fae6f8ffcd9171e997cece1246a8722a25b62d8b57baeabd4d7a22dd70df8ac7f8035df40e47&token=2139229535&lang=zh_CN#rd)

作者 | 王思宇（酒祝）

OpenKruise 是由阿里雲於 2019 年 6 月開源的雲原生應用自動化引擎，本質是基於 Kubernetes 標準擴充套件出來一個的應用負載專案，它可以配合原生 Kubernetes 使用，併為管理應用容器、sidecar、映象分發等方面提供更加強大和高效的能力，從而在不同維度上透過自動化的方式解決 Kubernetes 之上應用的規模化運維和規模化建站問題，包括部署、升級、彈性擴縮容、Qos 調節、健康檢查、遷移修復等等。

![1.jpeg](https://ucc.alicdn.com/pic/developer-ecology/f3abbf1074714a39bdf6c5d8713369f6.jpeg)

- **OpenKruise 官網**：[https://openkruise.io/](https://openkruise.io/)

- **GitHub 專案地址**：[https://github.com/openkruise/kruise](https://github.com/openkruise/kruise)

Kruise 是 Cruise 的諧音，'K' for Kubernetes，寓意 Kubernetes 上應用的航行和自動巡行，它滿載著阿里巴巴多年在大規模應用部署、釋出與管理最佳實踐，以及阿里雲 Kubernetes 服務數千客戶的需求沉澱。

# OpenKruise: 阿里巴巴 雙11 全鏈路應用的雲原生部署基座

在阿里巴巴經濟體的整體雲原生化過程當中，阿里的技術團隊逐漸沉澱出了一套緊貼上游社群標準、適應網際網路規模化場景的技術理念與最佳實踐。這其中，最重要的無疑是如何對應用進行自動化的釋出、執行和管理。於是，阿里雲容器團隊將這些能力透過  OpenKruise 反哺社群，以期指引業界雲原生化最佳實踐，少走彎路。

今年 雙11，阿里巴巴實現了核心系統的全面雲原生化。截至 2020 年 雙11，阿里巴巴內部已執行近十萬 OpenKruise 的 workload、管理著上百萬容器。

## 1. 內部執行的 OpenKruise 版本程式碼超 95% 來自社群倉庫

下圖展示了阿里巴巴內部執行的 OpenKruise 版本與開源版本之間的關係：

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

從上圖可以看出：Github 上的 OpenKruise 就是我們主體的上游倉庫，而內部的下游倉庫只基於公共介面實現了極少數內部耦合功能（這部分程式碼只佔據了不到 5%），也就是說阿里巴巴內部執行的 OpenKruise 其中 95% 以上的程式碼完全來自於社群倉庫。

有兩點值得說明：

- 所有通用能力，我們都會直接基於開源倉庫開發和提交，然後再同步到內部環境。

- 社群成員為 OpenKruise 貢獻的每一行程式碼，都將執行在阿里內部環境中。

## 2. 在 Kubernetes 上自動化應用程式工作負載管理

做上層業務的同學可能對 “應用負載（workload）” 缺乏概念，這裡先簡單做個介紹。不知道你是否有好奇過，每一次應用擴縮容、釋出操作的背後是如何實現的呢？在雲原生的環境下，我們都是透過面向終態的方式去描述應用的部署需求（需要的機器數、映象版本等等），見下圖：

![3.png](https://ucc.alicdn.com/pic/developer-ecology/265b624130204d43af5d1cbbf9288332.png)

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

當應用擴縮容時，PaaS（運維平臺）會修改上述 YAML 物件中的需求機器數（比如擴容 10 臺改為 110，再縮容 5 臺則改為 105），然後控制器就會按照 workload 期望的數量來調整實際執行的 Pod（容器）數量。當應用觸發釋出或回滾時，PaaS（運維平臺）則會修改上述 YAML 物件中的映象版本和釋出策略，控制器就會按照給指定的釋出策略來將所有管理的 Pod（容器）重建為期望版本（這只是一些便於理解的簡化描述，實際工作機制會複雜得多）。

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

## 3. 雙11 核心應用全面基於 OpenKruise 部署

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

![4.png](https://ucc.alicdn.com/pic/developer-ecology/31414585d72a4cac84a701a70e4e893e.png)

- CloneSet：（無狀態應用）這是規模最大的部分，絕大部分泛電商業務都是透過 CloneSet 來部署釋出。
- Advanced StatefulSet：（有狀態應用）目前主要是用於中介軟體在雲原生環境的部署。
- SidecarSet：（sidecar 生命週期管理）可以將定義好的 sidecar 容器動態注入到新建的 Pod 中，雲上的運維容器、 mesh 容器都是透過這種機制加入到業務 Pod 中。
- Advanced DaemonSet：將宿主機級別的守護程式部署到所有節點上，包括各種用於給業務容器配置網路、儲存的基礎元件。

因此，我們看到從上層電商業務到中介軟體，再到運維容器、基礎元件，整個上下游鏈路都是依賴於 OpenKruise 提供的 workload 做部署和執行。不管是應用執行時的機器數量、版本管理，還是緊急擴容、釋出等操作，都有 OpenKruise 無時無刻在維護著。

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

- 如果只是控制器掛了，則應用擴縮容、釋出操作全量失敗。
- 而如果控制器邏輯存在重大 bug，比如數量或版本號計算錯誤，甚至可能引起業務容器大規模誤刪或是升級為錯誤的版本。

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

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

## 4. 主要能力

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

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

- 應用釋出時，所有容器都要飄移重建：對於我們來說幾乎無法接受，在釋出高峰期如果阿里巴巴的大規模應用都在大規模重建，這是不管對於業務自身還是其他排程器、中介軟體、網路/儲存元件都是一種災難性的壓力。
- 無狀態應用負載（Deployment）無法灰度升級容器。
- 有狀態應用負載（StatefulSet）無法並行升級容器。
- 還有很多，這裡不一一列舉......

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

OpenKruise 首推的功能就是“原地升級”。透過這種能力，我們終於可以使應用釋出不需要將容器飄移重建，而是在原地、原 Pod 上只升級需要更新的映象。這樣帶來的好處太多了：

- 釋出效率大大提升。根據不完全統計資料，在大部分業務場景下原地升級至少比完全重建升級提升了 80% 以上的釋出速度：不僅省去了排程、分配網路、分配遠端盤的耗時，連拉取新版本映象的時候都得益於 node 上已有舊映象、只需要拉取較少的增量 layer。
- 釋出前後 IP 不變、升級過程 Pod 網路不斷，並且 Pod 中除了正在升級容器之外的其他容器都一直保持正常執行。
- Volume 不變，完全複用原容器的掛載裝置。
- 確保了叢集確定性，使全鏈路壓測透過後的叢集拓撲為大促提供保障。

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

![5.png](https://ucc.alicdn.com/pic/developer-ecology/b5b78050c04d4204b176d708519c4988.png)

# OpenKruise 已正式進入 CNCF Sandbox

2020 年 11 月 11 日，在這個特殊的時點，阿里巴巴技術人又迎來一件大事：經 CNCF 技術監督委員會全體成員投票，一致同意將阿里雲開源的 OpenKruise 正式晉級為 CNCF 託管專案。

正如開篇所說，OpenKruise 已經完成了社群開源，並且內外的版本做到幾乎完全一致。除此之外，我們還將 OpenKruise 提供到了阿里雲容器服務的應用目錄中，公有云上的任意客戶都可以一鍵安裝和使用 OpenKruise，真正實現 OpenKruise 在阿里集團內部業務、雲產品、開源社群中的“**三位一體**”。目前在 ACK 上使用 OpenKruise 的客戶主要包括鬥魚 TV、申通、有贊等，而開源社群中攜程、Lyft 等公司也都是 OpenKruise 的使用者和貢獻者。

OpenKruise 將基於阿里巴巴超大規模場景錘鍊出的雲原生應用負載能力開放出來，不僅在雲原生社群中補充了擴充套件應用負載的重要板塊，還為雲上客戶提供了阿里巴巴多年應用部署的管理經驗和雲原生化歷程的最佳實踐成果。從正式開源之日起，OpenKruise 專案已經建立多個關鍵里程碑：

- **Maintainer 5 位成員來自阿里巴巴、騰訊、Lyft **
- **44 位貢獻者**
   - **國內：阿里雲、螞蟻集團、攜程、騰訊、拼多多...**
   - **國外：微軟、Lyft、Spectro Cloud、Dsicord...**
- **1900+ GitHub Stars**
- **300+ Forks**

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

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

### 歡迎加入 OpenKruise 大家庭

如果你對 OpenKruise 的發展有任何建議，歡迎發表在下方評論區。另外，你可以透過搜尋釘釘群號：**23330762** 進入 “OpenKruise 社群交流釘釘群”，我們衷心歡迎每一位開源愛好者來參與 OpenKruise 的建設，共同打造雲原生領域最成熟、面向最大規模的應用自動化引擎。

OpenKruise：阿里巴巴雙11 全鏈路應用的雲原生部署基座

相關文章

OpenKruise：阿里巴巴 雙11 全鏈路應用的雲原生部署基座

相關文章

OpenKruise：阿里巴巴雙11 全鏈路應用的雲原生部署基座