![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/f37dd11b571f4c2986e1333bece8c1ff.png)

作者 | 王思宇（酒祝）
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/TEhPjTcrEE6-jjPLtu6Jkg)

# 背景

[OpenKruise](https://github.com/openkruise/kruise) 是阿里雲開源的雲原生應用自動化管理套件，也是當前託管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 專案。它來自阿里巴巴多年來容器化、雲原生的技術沉澱，是阿里內部生產環境大規模應用的基於 Kubernetes 之上的標準擴充套件元件，緊貼上游社群標準、適應網際網路規模化場景的技術理念與最佳實踐。

# 新版本概覽

Kruise 在 2021 年 3 月 4 日釋出了最新的 v0.8.0 版本（[ChangeLog](https://github.com/openkruise/kruise/blob/master/CHANGELOG.md)），本文以下對新版本做一個整體的概覽介紹。

## 1. 新增 kruise-daemon 元件

過去已經使用過 OpenKruise 的同學一定知道，Kruise 安裝之後執行的元件是 kruise-manager，它是一箇中心化部署的 Operator 元件，包含了一系列 controller 控制器以及 webhook。

而從 v0.8.0 開始，我們又增加了 kruise-daemon 這個節點元件，透過 DaemonSet 部署到每個節點上。這樣，一直以來社群小夥伴們提的類似**映象預熱**、**容器重啟**等需求，就有途徑去實現啦！

![1.png](https://ucc.alicdn.com/pic/developer-ecology/7b0c634ae75546cfa8e7200a68f7cab8.png)

Tips：

- 目前 kruise 提供的官方映象支援 Linux 的 amd64（x86）、arm64、arm/v7 架構，如果你的叢集中存在非以上架構的節點，暫時是無法正常執行 kruise-daemon 的，有這類需求的同學可以提[issue](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247502130&idx=1&sn=26975fb3abf313ec5bea540aecc68a85&chksm=fae6c2fdcd914beb2c42587878b497bc84ad794bec875fbc540772e741bd0eb3e3f6bec2823b&token=1541121403&lang=zh_CN) 說明你的需求。

- 如果你存在上述情況，或者你不希望在某些節點上安裝 kruise-daemon，可以在 helm 安裝的時候透過 `daemon.affinity` 引數來指定 kruise-daemon 部署的親和性規則。

## 2. 規模化映象預熱能力

在 Kubernetes 生態中，過去並沒有一個成熟的映象預熱開源解決方案，可能更多的是一些公司在內部會落地一些適配於本地場景的預熱，這其中也包括阿里巴巴。不過從 v0.8.0 開始，我們將阿里巴巴所做的映象預熱能力完全通用化輸出到 OpenKruise 中，並且阿里內部的映象預熱也完全統一到這套開源的實現上來了。

OpenKruise 映象預熱的具體實現原理，我們會在後續的專項文章中做詳細介紹，這裡只以一個最簡單的例子演示下如何做一個映象的預熱：

```
apiVersion: apps.kruise.io/v1alpha1
kind: ImagePullJob
metadata:
  name: job-nginx
spec:
  image: nginx:1.9.1   # [required] 完整的映象名 name:tag
  parallelism: 10      # [optional] 最大併發拉取的節點梳理, 預設為 1
  selector:            # [optional] 指定節點的 名字列表 或 標籤選擇器 (只能設定其中一種)，不設定表示全部節點
    names:
    - node-1
    - node-2
    matchLabels:
      node-type: xxx
  completionPolicy:
    type: Always                  # [optional] 預設為 Always
    activeDeadlineSeconds: 1200   # [optional] 無預設值, 只對 Alway 型別生效
    ttlSecondsAfterFinished: 300  # [optional] 無預設值, 只對 Alway 型別生效
  pullPolicy:                     # [optional] 每個節點上拉映象的側臉，預設 backoffLimit=3, timeoutSeconds=600
    backoffLimit: 3
    timeoutSeconds: 300
```

ImagePullJob 有兩種 completionPolicy 型別：

- `Always` 表示這個 job 是一次性預熱，不管成功、失敗都會結束
   - `activeDeadlineSeconds`：整個 job 的 deadline 結束時間
   - `ttlSecondsAfterFinished`：結束後超過這個時間，自動清理刪除 job
- `Never` 表示這個 job 是長期執行、不會結束，並且會每天都會在匹配的節點上重新預熱一次指定的映象

詳細資訊參考官網文件：[https://openkruise.io/zh-cn/docs/imagepulljob.html](https://openkruise.io/zh-cn/docs/imagepulljob.html)

## 3. SidecarSet 全新重構實現

SidecarSet 是一個用於管理 sidecar 容器的控制器。在使用者建立了 SidecarSet 之後，Kruise 能為後續建立的符合規定條件的 Pod 中自動注入使用者定義的 sidecar 容器，以及對已注入的 sidecar 容器做原地升級同時不影響業務容器的執行。

在過去版本中，SidecarSet 的侷限性較多，比如使用者無法宣告只對某個 namespace 生效、sidecar 原地升級時灰度能力較弱等。在 v0.8.0 中，我們全新重構了 SidecarSet 的 controller 和 webhook，並且在 CRD 定義上新增了一些更多能力的策略欄位。舉一些例子：

1. spec.namespace：指定只管理具體某個名稱空間的 sidecar 注入和升級
1. 多種注入策略：
   1. podInjectPolicy：指定 sidecar 容器注入到 Pod 原 containers 列表的前面還是後面
   1. shareVolumePolicy：與 Pod 中原容器共享卷策略
   1. transferEnv：從原 Pod 中哪些容器裡共享哪些環境變數
3. 多種原地升級策略：
   1. maxUnavailable：升級過程中最大不可用數量
   1. partition：保留舊版本的數量（灰度/分批發布）
   1. selector：只升級符合 selector 條件 Pod 中的 sidecar（金絲雀釋出）
   1. scatter：按標籤打散發布

詳細資訊參考官網文件：[https://openkruise.io/zh-cn/docs/sidecarset.html](https://openkruise.io/zh-cn/docs/sidecarset.html)

## 4. 新的 feature-gate 機制

過去 OpenKruise 中的 CRD 以及 controller/webhook 開關，主要配置在 CUSTOM_RESOURCE_ENABLE 環境變數中，而其他一些可配置開關則集中在命令列引數中，帶來的問題一來是較為分散，二來一些關聯多個 CRD 的功能開關其實很難用 CRD 開關來控制。

因此，目前新增的 feature-gate 機制已經代替了 CUSTOM_RESOURCE_ENABLE 環境變數，聚焦於功能層面。

在 v0.8.0 提供了 PodWebhook、KruiseDaemon 兩個開關，前者關閉後 kruise 不會對 pod creation 做 webhook 攔截，但同時也會關閉 SidecarSet 功能，後者關閉後不會部署 kruise-daemon 元件，但同時也會關閉映象預熱功能。後續版本中個，我們會逐漸把過去的開關引數統一到 feature-gate 中。

## 5. 其餘一些變化點

其餘部分最佳化：

- CloneSet、Advanced StatefulSet 部分邏輯最佳化。
- 在官方 DockerHub 之外新增阿里雲託管映象，國內使用者可以選擇使用阿里雲映象源來安裝/升級 Kruise。
- 呼叫 apiserver 的 user-agent 細化到控制器。
- clientset 中為支援 scale 子資源的 CRD 新增 GetScale/UpdateScale 方法。

# 總結

OpenKruise v0.8.0 新版本，可以說是 Kubernetes 社群中首個提供開源的規模化映象預熱功能的產品了。而在今年後續的版本里，我們還計劃提供利用映象預熱來加速應用釋出、應用安全防護、Controller 灰度/分片管控等能力，預計在年中將推出 v1.0 大版本。

OpenKruise 是一個成熟的 CNCF 沙箱專案，除了在阿里巴巴內大規模應用之外，在行業內也有著廣泛的使用者案例：

- 基於原地升級、灰度釋出等需求，攜程在生產環境使用 CloneSet、AdvancedStatefulSet 來分別管理無狀態、有狀態應用，單叢集 Kruise workload 數量達到萬級別。
- OPPO 公司不僅大規模使用了 OpenKruise，還在下游配合其定製化的 Kubernetes 進一步加強了原地升級，廣泛應用在多個業務的後端執行服務中，透過原地更新覆蓋了 87% 左右的升級部署需求。
- 此外，國內的使用者還有鬥魚 TV、有贊、蘇寧、比心、Boss 直聘、申通、小紅書、火花思維、VIPKID、掌門教育、杭銀消費、萬翼科技、多點 Dmall、佐疆科技、享住智慧、艾佳生活、永輝科技中心、跟誰學、Deepexi，國外的使用者有 Lyft、Bringg、Arkane Systems、Spectro Cloud 等。

我們歡迎每一位雲原生愛好者共同參與 OpenKruise 的建設，共同打造業界頂尖的雲原生應用自動化引擎！

# 最後的開源要聞

近期，阿里雲 DADI (Data Accelerator for Disaggregated Infrastructure) 產品開源了！這是一個容器映象加速器專案，已經在阿里巴巴內部有了大規模場景的應用。

它的主要原理是消除 image 的下載和解壓縮過程，代之以實現細粒度資料塊的按需拉取。這樣可以削減絕大多數的資料下載工作，同時將計算延遲與資料傳輸延遲相互隱藏，最終達到大幅削減啟動延遲的作用。

DADI 將容器 image 的分層特性與虛擬機器 image 的塊裝置介面相結合，形成全新的分層塊裝置 image，稱為 overlaybd。由於使用了塊裝置介面，DADI 可以支援原生檔案系統，如 ext4、xfs、甚至 ntfs；塊裝置介面也可以自然地支援虛擬化的安全容器，並且只暴露最小的 attack surface。此外由於塊裝置 image 簡單高效的特性，overlaybd 可以為使用者提供更好的 I/O 效能。

有興趣的同學可以參考論文看一下 Github 專案哦：

- [論文地址](https://www.usenix.org/conference/atc20/presentation/li-huiba)

- [Github 地址](https://github.com/alibaba/accelerated-container-image)

如果大家對 OpenKruise 專案感興趣，有任何希望交流的話題，歡迎大家訪問 [OpenKruise 官網](https://openkruise.io/en-us/)、[GitHub](https://github.com/openkruise/kruise)，以及釘釘搜尋群號：23330762，加入交流群！

OpenKruise v0.8.0 版本釋出：K8s 社群首個規模化映象預熱能力

相關文章