*作者：褚杏娟*

*採訪嘉賓 ：王思宇（花名：酒祝）*

2021 年 12 月，CNCF 開源專案 OpenKruise 正式宣佈了 v1.0 大版本的釋出。

OpenKruise 是一個基於 Kubernetes 的擴充套件套件，主要聚焦在雲原生應用的自動化，例如部署、釋出、運維以及可用性防護等。更新到 v1.0 版本後，OpenKruise 目前主要提供應用工作負載、Sidecar 管理、增強運維能力、分割槽部署彈性策略、應用可用性防護等功能，為雲原生應用提供落地能力。

目前，OpenKruise 官方登記的 Adopter 數量達到 35+，阿里巴巴、螞蟻集團、美團、攜程、網易、小米、OPPO、蘇寧等都在生產環境使用了 OpenKruise 功能，國外如北美的 Lyft、以色列的 Bringg、面向東南亞市場的 Shopee 等也都使用了 OpenKruise。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/ded913fe0fb04067a14c7d1f06108df4.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

## 為更復雜的場景而生

OpenKruise 源於阿里巴巴經濟體應用過去多年的大規模應用部署、釋出與管理的最佳實踐。阿里擁有超大規模的網際網路應用場景，而如此豐富的業務線和龐大數量的應用例項絕大部分都是以容器的方式執行在阿里云云原生平臺維護的容器叢集中。

在 2011 年，阿里就開始發展基於 LXC 的容器技術，隨後逐漸完成了集團業務部署的全面容器化。近幾年，隨著雲技術發展和雲原生的興起，阿里將過去的 T4 容器遷移到了新的架構系統 --ASI（Alibaba Serverless Infrastructure）。ASI 在原生 Kubernetes 的基礎上，透過標準化擴充套件的方式提供了更多增強功能和適配阿里集團場景的落地能力，支撐了各種各樣的複雜場景和需求。

隨著越來越多樣化的業務遷移到了 ASI 雲原生叢集中，阿里開始考慮將這些元件功能開放給全球的 Kubernetes 使用者，於是便有了 OpenKruise 開源專案。2019 年 6 月，OpenKruise 的第一個預覽版本釋出，並在 KubeCon 雲原生技術峰會上宣佈開源。

在阿里雲技術團隊看來，開源絕不是僅僅將程式碼複製後開放出來。“我們曾經看到一些開源專案，僅僅是每隔幾個月甚至更久的時間將內部程式碼選擇性地拿出一部分更新到 GitHub 上。這絕不是一種健康、可持續的開源方式，無法形成社群凝聚力。”阿里雲技術專家王思宇說道。

因此，在最初構想到首個開源版本釋出的兩個多月時間裡，阿里雲技術團隊主要在解決以下兩件事：

- 設計開放的開源與內部協作流程。經過反覆斟酌，團隊最終決定將 OpenKruise 的基礎倉庫完全託管在社群，內部僅維護一個 fork 倉庫，並不斷從 GitHub 上游同步程式碼進來。因此，OpenKruise 所有功能的開發都是基於 GitHub 協作、提交和評審，所有過程對社群開放，任何人都可以參與。阿里內部的 fork 倉庫只保留了少量適配介面，並將內外程式碼的一致率維持在 95% 以上。

- 制定合理的功能開源路徑。ASI 中的擴充套件功能非常豐富，但並非所有功能都適配任意的原生 Kubernetes，此外很多功能也不夠完善，可能存在更好的設計與實現方式。因此，阿里選擇先從一些既足夠成熟、易用，又能保證足夠通用性和向後相容性的特性開始，逐步將其開放到社群。

2020 年 11 月，阿里將 OpenKruise 捐贈給 CNCF 基金會託管，並將於 2022 年初提出 CNCF Incubation 申請。

## 為什麼說是一次大升級

2021 年 3 月，OpenKruise 釋出了 v0.8.0 版本。在這個版本之前，OpenKruise 更多地專注在工作負載（Workload）領域，CloneSet、Advanced StatefulSet、SidecarSet 等功能滿足了各種各樣業務和容器的部署場景。

但阿里雲技術團隊認為，OpenKruise 作為一個面向 Kubernetes 應用自動化管理的專案，不應該僅僅侷限在應用“部署”上。因此，團隊在 2021 年提出了“More than Workloads”的規劃，從 v0.8.0 到 v1.0 大版本，OpenKruise 應用管理的支援範圍不斷擴大。

### 多種增強的 Workload 型別

首先，在最新的 v1.0 大版本中，OpenKruise 提供了多種增強的 Workload 型別。

王思宇介紹，Kubernetes 原生的 Workload 在真實的生產環境下只能滿足 40%~60% 較為簡單和通用的場景，但這些不包括來自阿里巴巴等網際網路公司的許多超大規模和複雜業務場景。因此，OpenKruise 針對這些場景做了很多改進，比如有對標 Deployment 的無狀態應用管理負載 CloneSet 。

下表是 CloneSet 和 Deployment 在擴縮容彈性和釋出能力上的差異對比。可以看到，CloneSet 滿足了很多真實生產場景下的業務訴求，而這些是 Deployment 所不具備的。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/a0ee928076bd4835818ddef0acca67b7.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

### 原地升級大幅加強

在 v1.0 版本中，OpenKruise 還對原地升級這一核心功能做了大幅加強。

相比現在開發者使用 Deployment 升級時刪除、新建 Pod 的方式，原地升級可以使 Pod 物件、所在 Node、IP、Volume 掛載卷和資料等都不發生任何變化，甚至 Pod 中一個容器進行原地升級時，其他容器保持正常執行。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/74157e10dc0445db8941b1322411eed3.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

據瞭解，在超大規模叢集和業務釋出高峰的情況下，原地升級相比大量的 Pod 重建升級，不僅保證了釋出的穩定性，還最佳化了 60%~80% 的釋出效率。目前有兩種主流的原地升級方式：

- 對於容器映象的原地升級。由 Kruise controller 修改 Pod 中的 image 欄位，修改後，kubelet 會感知到 Pod 中對應容器的 hash 值發生了變化，隨後把舊的容器停掉，然後用 Pod 中的新容器（映象）再次執行拉取、建立、啟動等操作。

- 對於透過 Downward API 定義的容器環境變數等欄位的原地升級。每個節點上的 kruise-daemon 元件將 Downward API 帶入容器計算真實的 hash 值。當 hash 值發生變化，也就是 Downward API 引用的 labels/annotations 值被更新，kruise-daemon 就會透過 CRI 介面停掉當前執行的容器，kubelet 發現容器停止後再根據 Pod 將新容器重建出來，從而生效了新的環境變數等配置。

據王思宇介紹，考慮到對企業架構和設計的改動，Kubernetes 社群目前只有針對 VPA，即資源原地升級的提案，而更多的如映象原地升級等在雲原生社群只有 OpenKruise 在做。截至 v1.0 版本，OpenKruise 透過 Downward API 方式，提供了針對容器 image 和 env/command/args 等欄位的原地升級。

### 高可用性防護提升

眾所周知，Kubernetes 的面向終態自動化是一把 “雙刃劍”，它既為應用帶來了宣告式的部署能力，同時也潛在地會將一些誤操作行為被終態化放大。例如“級聯刪除”機制，正常情況（非 orphan 刪除）下，一旦父類資源被刪除，那麼所有子類資源都會被關聯刪除：

*刪除一個 CRD，其所有對應的 CR 都被清理掉；
刪除一個 namespace，這個名稱空間下包括 Pod 在內所有資源都被一起刪除；
刪除一個 Workload（Deployment/StatefulSet/...），則下屬所有 Pod 被刪除。*

任何一家企業的生產環境中發生大規模誤刪除都是不可承受的，因此不少社群 Kubernetes 使用者和開發者都在抱怨類似 “級聯刪除” 帶來的問題。因此，OpenKruise 開源的首個防護功能，就是對“級聯刪除”機制的兜底保護。

簡單來說，使用者在給 CRD、namespace、Workloads 打上防級聯刪除的標籤後，這些資源被呼叫刪除時，Kruise 會幫助使用者校驗本次刪除是否存在級聯風險，比如一個 namespace 下還有正在執行和服務的 Pod，那麼 Kruise 會禁止直接刪除該 namespace，避免誤刪業務 Pod。

除此之外，OpenKruise 還提供了原生 Pod Disruption Budget（PDB）的增強版本 Pod Unavailable Budget（PUB）。PDB 只是防護 Pod 驅逐操作，而 PUB 防護了所有會導致 Pod 不可用的操作，包括了驅逐操作和更多的 Pod 刪除、原地升級等。

###  運維升級

當前，Kubernetes 在應用運維方面被“吐槽”很多的一點就是，將下層的容器執行時（Container Runtime）封裝得太嚴實。

Runtime 層的容器建立只有一個 Pod 資源，此外沒有任何介面可以讓使用者能夠透過 Kubernetes API 層面來執行一些 Runtime 相關操作，比如拉取映象、重啟容器等，但這些都是來自業務場景的現實訴求。

由於 kubelet 缺乏類似於 plugin 的擴充套件機制，OpenKruise 便建立了一個名為 kruise-daemon 的節點元件。kruise-daemon 可以理解 OpenKruise 定義的一些 CRD 和擴充套件協議，並與自己所在節點上的 CRI（Container Runtime Interface）通訊，傳遞對節點容器的操作。透過這種方式，OpenKruise 提供了映象預熱、容器重啟等 CRD，使用者可以透過提交 YAML 來指定需要下發預熱的 image 映象，或指定 Pod 中的一個或多個容器執行重啟。

除此之外，OpenKruise 的最新版本還支援資源跨 namespace 分發、容器啟動順序控制等運維功能。前者支援將一份 ConfigMap、Secret 配置分發到一批 namespace 之下，後者則能夠幫助使用者控制 Pod 中有強依賴關係的多個容器的啟動順序。

## 下一步：執行時

據王思宇介紹，不同的使用者使用 OpenKruise 的側重點也會不一樣。

阿里巴巴、攜程等公司實際上已經把 OpenKruise 作為業務部署的統一應用負載。比如阿里巴巴的電商、生活服務等多數業務都是透過 CloneSet 部署和釋出管理，而 Nacos 等中介軟體則是透過 Advanced StatefulSet 部署。有的公司按需使用了部分 OpenKruise 提供的功能，如有的使用 SidecarSet 獨立管理、注入和升級 sidecar 容器，也有的只依賴了一些增強運維能力，如映象預熱、容器重啟等。

在王思宇看來，目前 OpenKruise 在 Workload 領域已經趨向成熟，可以滿足大部分較通用的應用部署釋出場景，但圍繞 Kubernetes 執行時方面的問題，還有不少值得提升和完善的地方。

“我們已經不止一次收到使用者反饋，他們在使用原生 Kubernetes 的 LivenessProbe 探針時出現了 probe 配置錯誤或探測有誤，導致整個應用下的所有 Pod 都發生了異常重啟，但在 Pod 中的程式是正常的，從而使得整個應用停止了服務，觸發了比較大的故障。”王思宇表示，OpenKruise 接下來會定義一套旁路的 LivenessProbe，並能夠讓使用者定義觸發重啟時的限流策略，從而避免對應用的全量 Pod 造成不可用的影響。

王思宇透露，OpenKruise 正在研發一個探索性專案——ControllerMesh。該專案使用一個代理容器攔截使用者的 operator（controller）與 kube-apiserver 的通訊，透過在 Proxy 層對請求 / 返回資料修改和轉發，從而實現 operator 的多租部署、動態隔離、灰度升級、故障注入、客戶端側的限流熔斷等策略。

“這是一個對 Kubernetes controller 執行時前所未有的強大擴充套件，並且對於使用者 operator 自身無任何侵入。”王思宇說道。

*嘉賓介紹：*

*王思宇（花名：酒祝），阿里雲技術專家，OpenKruise maintainer，Kubernetes member，多屆 KubeCon 等雲原生峰會講師，有多年超大規模容器和雲原生領域的排程編排和管理經驗。*

戳[此處](https://openkruise.io/)，檢視 OpenKruise 專案官方主頁與文件！！

專訪 OpenKruise 負責人：現在的雲原生應用自動化發展到什麼程度了？

相關文章