為更復(fù)雜的場(chǎng)景而生

Cloud Native

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

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

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

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

因此，在最初構(gòu)想到首個(gè)開源版本發(fā)布的兩個(gè)多月時(shí)間里，阿里云技術(shù)團(tuán)隊(duì)主要在解決以下兩件事：

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

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

2020 年 11 月，阿里將 OpenKruise 捐贈(zèng)給 CNCF 基金會(huì)托管，并將于 2022 年初提出 CNCF Incubation 申請(qǐng)。

為什么說是一次大升級(jí)

Cloud Native

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

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

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

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

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

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

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

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

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

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

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

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

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

除此之外，OpenKruise 還提供了原生 Pod Disruption Budget（PDB）的增強(qiáng)版本 Pod Unavailable Budget（PUB）。PDB 只是防護(hù) Pod 驅(qū)逐操作，而 PUB 防護(hù)了所有會(huì)導(dǎo)致 Pod 不可用的操作，包括了驅(qū)逐操作和更多的 Pod 刪除、原地升級(jí)等。

當(dāng)前，Kubernetes 在應(yīng)用運(yùn)維方面被“吐槽”很多的一點(diǎn)就是，將下層的容器運(yùn)行時(shí)（Container Runtime）封裝得太嚴(yán)實(shí)。

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

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

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

下一步：運(yùn)行時(shí)

Cloud Native

據(jù)王思宇介紹，不同的用戶使用 OpenKruise 的側(cè)重點(diǎn)也會(huì)不一樣。

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

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

“我們已經(jīng)不止一次收到用戶反饋，他們?cè)谑褂迷?Kubernetes 的 LivenessProbe 探針時(shí)出現(xiàn)了 probe 配置錯(cuò)誤或探測(cè)有誤，導(dǎo)致整個(gè)應(yīng)用下的所有 Pod 都發(fā)生了異常重啟，但在 Pod 中的進(jìn)程是正常的，從而使得整個(gè)應(yīng)用停止了服務(wù)，觸發(fā)了比較大的故障。”王思宇表示，OpenKruise 接下來會(huì)定義一套旁路的 LivenessProbe，并能夠讓用戶定義觸發(fā)重啟時(shí)的限流策略，從而避免對(duì)應(yīng)用的全量 Pod 造成不可用的影響。

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

“這是一個(gè)對(duì) Kubernetes controller 運(yùn)行時(shí)前所未有的強(qiáng)大擴(kuò)展，并且對(duì)于用戶 operator 自身無任何侵入。”王思宇說道。

嘉賓介紹：

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