為更復雜的場景而生

Cloud Native

OpenKruise 源于阿里巴巴經濟體應用過去多年的大規(guī)模應用部署、發(fā)布與管理的最佳實踐。阿里擁有超大規(guī)模的互聯(lián)網應用場景，而如此豐富的業(yè)務線和龐大數(shù)量的應用實例絕大部分都是以容器的方式運行在阿里云云原生平臺維護的容器集群中。

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

隨著越來越多樣化的業(yè)務遷移到了 ASI 云原生集群中，阿里開始考慮將這些組件功能開放給全球的 Kubernetes 用戶，于是便有了 OpenKruise 開源項目。2019 年 6 月，OpenKruise 的第一個預覽版本發(fā)布，并在 KubeCon 云原生技術峰會上宣布開源。

在阿里云技術團隊看來，開源絕不是僅僅將代碼拷貝后開放出來。“我們曾經看到一些開源項目，僅僅是每隔幾個月甚至更久的時間將內部代碼選擇性地拿出一部分更新到 GitHub 上。這絕不是一種健康、可持續(xù)的開源方式，無法形成社區(qū)凝聚力?！卑⒗镌萍夹g專家王思宇說道。

因此，在最初構想到首個開源版本發(fā)布的兩個多月時間里，阿里云技術團隊主要在解決以下兩件事：

• 設計開放的開源與內部協(xié)作流程。經過反復斟酌，團隊最終決定將 OpenKruise 的基礎倉庫完全托管在社區(qū)，內部僅維護一個 fork 倉庫，并不斷從 GitHub 上游同步代碼進來。因此，OpenKruise 所有功能的開發(fā)都是基于 GitHub 協(xié)作、提交和評審，所有過程對社區(qū)開放，任何人都可以參與。阿里內部的 fork 倉庫只保留了少量適配接口，并將內外代碼的一致率維持在 95% 以上。

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

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

為什么說是一次大升級

Cloud Native

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

但阿里云技術團隊認為，OpenKruise 作為一個面向 Kubernetes 應用自動化管理的項目，不應該僅僅局限在應用“部署”上。因此，團隊在 2021 年提出了“More than Workloads”的規(guī)劃，從 v0.8.0 到 v1.0 大版本，OpenKruise 應用管理的支持范圍不斷擴大。

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

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

下表是 CloneSet 和 Deployment 在擴縮容彈性和發(fā)布能力上的差異對比?？梢钥吹?，CloneSet 滿足了很多真實生產場景下的業(yè)務訴求，而這些是 Deployment 所不具備的。

據了解，在超大規(guī)模集群和業(yè)務發(fā)布高峰的情況下，原地升級相比大量的 Pod 重建升級，不僅保證了發(fā)布的穩(wěn)定性，還優(yōu)化了 60%~80% 的發(fā)布效率。目前有兩種主流的原地升級方式：

• 對于容器鏡像的原地升級。由 Kruise controller 修改 Pod 中的 image 字段，修改后，kubelet 會感知到 Pod 中對應容器的 hash 值發(fā)生了變化，隨后把舊的容器停掉，然后用 Pod 中的新容器（鏡像）再次執(zhí)行拉取、創(chuàng)建、啟動等操作。

• 對于通過 Downward API 定義的容器環(huán)境變量等字段的原地升級。每個節(jié)點上的 kruise-daemon 組件將 Downward API 帶入容器計算真實的 hash 值。當 hash 值發(fā)生變化，也就是 Downward API 引用的 labels/annotations 值被更新，kruise-daemon 就會通過 CRI 接口停掉當前運行的容器，kubelet 發(fā)現(xiàn)容器停止后再根據 Pod 將新容器重建出來，從而生效了新的環(huán)境變量等配置。

據王思宇介紹，考慮到對企業(yè)架構和設計的改動，Kubernetes 社區(qū)目前只有針對 VPA，即資源原地升級的提案，而更多的如鏡像原地升級等在云原生社區(qū)只有 OpenKruise 在做。截至 v1.0 版本，OpenKruise 通過 Downward API 方式，提供了針對容器 image 和 env/command/args 等字段的原地升級。

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

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

任何一家企業(yè)的生產環(huán)境中發(fā)生大規(guī)模誤刪除都是不可承受的，因此不少社區(qū) Kubernetes 用戶和開發(fā)者都在抱怨類似 “級聯(lián)刪除” 帶來的問題。因此，OpenKruise 開源的首個防護功能，就是對“級聯(lián)刪除”機制的兜底保護。

簡單來說，用戶在給 CRD、namespace、Workloads 打上防級聯(lián)刪除的標簽后，這些資源被調用刪除時，Kruise 會幫助用戶校驗本次刪除是否存在級聯(lián)風險，比如一個 namespace 下還有正在運行和服務的 Pod，那么 Kruise 會禁止直接刪除該 namespace，避免誤刪業(yè)務 Pod。

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

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

Runtime 層的容器創(chuàng)建只有一個 Pod 資源，此外沒有任何接口可以讓用戶能夠通過 Kubernetes API 層面來執(zhí)行一些 Runtime 相關操作，比如拉取鏡像、重啟容器等，但這些都是來自業(yè)務場景的現(xiàn)實訴求。

由于 kubelet 缺乏類似于 plugin 的擴展機制，OpenKruise 便創(chuàng)建了一個名為 kruise-daemon 的節(jié)點組件。kruise-daemon 可以理解 OpenKruise 定義的一些 CRD 和擴展協(xié)議，并與自己所在節(jié)點上的 CRI（Container Runtime Interface）通信，傳遞對節(jié)點容器的操作。通過這種方式，OpenKruise 提供了鏡像預熱、容器重啟等 CRD，用戶可以通過提交 YAML 來指定需要下發(fā)預熱的 image 鏡像，或指定 Pod 中的一個或多個容器執(zhí)行重啟。

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

下一步：運行時

Cloud Native

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

阿里巴巴、攜程等公司實際上已經把 OpenKruise 作為業(yè)務部署的統(tǒng)一應用負載。比如阿里巴巴的電商、生活服務等多數(shù)業(yè)務都是通過 CloneSet 部署和發(fā)布管理，而 Nacos 等中間件則是通過 Advanced StatefulSet 部署。有的公司按需使用了部分 OpenKruise 提供的功能，如有的使用 SidecarSet 獨立管理、注入和升級 sidecar 容器，也有的只依賴了一些增強運維能力，如鏡像預熱、容器重啟等。

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

“我們已經不止一次收到用戶反饋，他們在使用原生 Kubernetes 的 LivenessProbe 探針時出現(xiàn)了 probe 配置錯誤或探測有誤，導致整個應用下的所有 Pod 都發(fā)生了異常重啟，但在 Pod 中的進程是正常的，從而使得整個應用停止了服務，觸發(fā)了比較大的故障?！蓖跛加畋硎?，OpenKruise 接下來會定義一套旁路的 LivenessProbe，并能夠讓用戶定義觸發(fā)重啟時的限流策略，從而避免對應用的全量 Pod 造成不可用的影響。

王思宇透露，OpenKruise 正在研發(fā)一個探索性項目——ControllerMesh。該項目使用一個代理容器攔截用戶的 operator（controller）與 kube-apiserver 的通信，通過在 Proxy 層對請求 / 返回數(shù)據修改和轉發(fā)，從而實現(xiàn) operator 的多租部署、動態(tài)隔離、灰度升級、故障注入、客戶端側的限流熔斷等策略。

“這是一個對 Kubernetes controller 運行時前所未有的強大擴展，并且對于用戶 operator 自身無任何侵入?！蓖跛加钫f道。

嘉賓介紹：

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