作者：褚杏娟
采訪嘉賓 ：王思宇（花名：酒祝）
2021 年 12 月，CNCF 開源專案 OpenKruise 正式宣布了 v1.0 大版本的發布，
OpenKruise 是一個基于 Kubernetes 的擴展套件，主要聚焦在云原生應用的自動化，例如部署、發布、運維以及可用性防護等，更新到 v1.0 版本后，OpenKruise 目前主要提供應用作業負載、Sidecar 管理、增強運維能力、磁區部署彈性策略、應用可用性防護等功能，為云原生應用提供落地能力，
目前，OpenKruise 官方登記的 Adopter 數量達到 35+，阿里巴巴、螞蟻集團、美團、攜程、網易、小米、OPPO、蘇寧等都在生產環境使用了 OpenKruise 功能，國外如北美的 Lyft、以色列的 Bringg、面向東南亞市場的 Shopee 等也都使用了 OpenKruise，
為更復雜的場景而生
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 所不具備的，
原地升級大幅加強
在 v1.0 版本中，OpenKruise 還對原地升級這一核心功能做了大幅加強，
相比現在開發者使用 Deployment 升級時洗掉、新建 Pod 的方式，原地升級可以使 Pod 物件、所在 Node、IP、Volume 掛載卷和資料等都不發生任何變化，甚至 Pod 中一個容器進行原地升級時，其他容器保持正常運行，
據了解，在超大規模集群和業務發布高峰的情況下，原地升級相比大量的 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 等云原生峰會講師，有多年超大規模容器和云原生領域的調度編排和管理經驗，
戳此處，查看 OpenKruise 專案官方主頁與檔案！！
發布云原生技術最新資訊、匯集云原生技術最全內容，定期舉辦云原生活動、直播，阿里產品及用戶最佳實踐發布，與你并肩探索云原生技術點滴，分享你需要的云原生內容，
關注【阿里巴巴云原生】公眾號，獲取更多云原生實時資訊！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/423826.html
標籤：其他