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

作者 | 酒祝  阿里雲技術專家

> **導讀**：[OpenKruise](https://github.com/openkruise/kruise) 是阿里雲開源的大規模應用自動化管理引擎，在功能上對標了 Kubernetes 原生的 Deployment/StatefulSet 等控制器，但 OpenKruise 提供了更多的增強功能如 優雅原地升級、釋出優先順序/打散策略、多可用區 workload 抽象管理、統一 sidecar 容器注入管理等，都是經歷了阿里巴巴超大規模應用場景打磨出的核心能力。這些 feature 幫助我們應對更加多樣化的部署環境和需求、為叢集維護者和應用開發者帶來更加靈活的部署釋出組合策略。

目前在阿里巴巴內部雲原生環境中，絕大部分應用都統一使用 OpenKruise 的能力做 Pod 部署、釋出管理，而不少業界公司和阿里雲上客戶由於 K8s 原生 Deployment 等負載不能完全滿足需求，也轉而採用 OpenKruise 作為應用部署載體。

# 背景問題

在介紹 OpenKruise 新增能力之前，我們先來看一下原生 K8s workload 所提供的釋出能力：

- Deployment 目前支援 maxUnavailable 和 maxSurge：

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

- StatefulSet 目前支援 partition：

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

- 其餘 workload 如 DaemonSet，也只支援了 maxUnavailable。

以上這些策略在測試環境或是小場景下尚且可行，但其實無法完全滿足大規模的應用場景。比方說：

- 首先，Deployment 不支援灰度分批發布，你想只灰度升級其中 20% 的 Pod 做驗證？抱歉做不到啊，使用者只能設定小一些的 maxUnavailable 等著它全部發完，或者釋出出現問題緊急 pause 暫停；
- StatefulSet 確實支援灰度分批（partition），但目前是隻能一個一個 Pod 來升級。如果 replicas 總數有個幾百上千的量，那麼一次釋出可能要等到天黑。

# v0.5.0 新增功能

這裡我們只針對 v0.5.0 版本 CloneSet 和 SidecarSet 的兩個主要功能改動來介紹，有興趣的同學可以在 Github changelog 上看到版本改動明細：[https://github.com/openkruise/kruise/blob/master/CHANGELOG.md](https://github.com/openkruise/kruise/blob/master/CHANGELOG.md) 。

### CloneSet 支援 maxSurge 策略

在阿里巴巴內部的雲原生環境下，絕大部分無狀態應用都使用 CloneSet 管理。為了應對超大規模應用的極致部署需求，我們在其中支援：

- 原地升級（釋出前後 Pod 物件不變、IP 不變、volume 不變，只升級容器的映象）
- 縮小 replicas 指定 Pod 刪除
- 豐富的釋出策略（流式、灰度分批、優先順序、打散等）

而在今年 2 月份的 Kruise v0.4.0 版本中，我們將 CloneSet 推出到開源。CloneSet 一經發布就廣受關注，目前已經有多家知名網際網路公司在調研使用。

最初版本的 CloneSet 並未支援 maxSurge（先擴後縮釋出），只支援了 maxUnavailable、partition 等策略。這對阿里巴巴內部的大體量應用來說不是問題，但是很多社群使用者的平臺上都有小規模的應用，如果不能配置先擴後縮，那麼在釋出階段可能會影響到應用的可用性。

在收到社群的 issue [#250](https://github.com/openkruise/kruise/issues/250) [#260](https://github.com/openkruise/kruise/issues/260) 反饋後，我們在 CloneSet 中新增了 maxSurge 策略的支援並於 v0.5.0 版本中提供，在此也感謝社群 [fatedier](https://github.com/fatedier) [shiyan2016](https://github.com/shiyan2016) 等成員的參與貢獻和寶貴建議。至此，CloneSet 已經覆蓋了 K8s 原生 workload 的所有釋出策略，下圖構建了 CloneSet 目前提供的釋出功能：

![3.png](https://ucc.alicdn.com/pic/developer-ecology/8f87104e18af4c47b2548e192dcb265e.png)

這裡暫時不對 CloneSet 的釋出策略做詳細說明，我們後續會有專項文章來介紹。我們只看一下新增的 maxSurge 是如何配合流式、分批發布來實現的呢？接下來我們用幾個簡單的例子來看一下：

1. **設定 maxSurge + maxUnavailable + partition 釋出**：

```yaml
apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
# ...
spec:
	replicas: 5          # Pod 總數為 5
  updateStrategy:
    maxSurge: 20%      # 多擴出來 5 * 20% = 1 個 Pod (rounding up)
    maxUnavailable: 0  # 保證釋出過程 5 - 0 = 5 個 Pod 可用
    partition: 3       # 保留 3 箇舊版本 Pod （只發布 5 - 3 = 2 個 Pod）
```

當開始釋出時，CloneSet 會先根據 maxSurge 多擴出來一個 Pod，此時 Pod 總數為 6（5 箇舊版，1 個新版）：

```bash
$ kubectl get clone demo
NAME    DESIRED   UPDATED   UPDATED_READY   READY   TOTAL   AGE
demo    5         1         0               5       6       17m
```

隨後，CloneSet 會在保證 maxUnavailable 的前提下逐漸把 Pod 刪除、新建的方式更新，直到滿足 partition=3 即剩餘 3 箇舊版本 Pod。此時，因為已經達到了期望的終態，CloneSet 會把新版本 Pod 刪除一個，此時 Pod 總數為 5（3 箇舊版，2 個新版）：

```bash
$ kubectl get clone demo
NAME    DESIRED   UPDATED   UPDATED_READY   READY   TOTAL   AGE
demo    5         2         2               5       5       17m
```

這裡可以觀察一段時間，當需要繼續往下發布時，再次修改 partition 為 0。然後，CloneSet 會再次根據 maxSurge 多擴出來一個 Pod，此時 Pod 總數為 6（3 箇舊版，3 個新版）：

```bash
$ kubectl get clone demo
NAME    DESIRED   UPDATED   UPDATED_READY   READY   TOTAL   AGE
demo    5         3         2               5       6       17m
```

隨後，CloneSet 會在保證 maxUnavailable 的前提下逐漸把 Pod 刪除、新建的方式更新，直到滿足 partition=0 即所有 Pod 都升級到新版本。最後，CloneSet 會把新版本 Pod 刪除一個，此時 Pod 總數為 5（5 個新版）：

```bash
$ kubectl get clone demo
NAME    DESIRED   UPDATED   UPDATED_READY   READY   TOTAL   AGE
demo    5         5         5               5       5       17m
```

2. ** maxSurge 配合原地升級**：

CloneSet 提供了 Pod 原地升級和重建升級兩種升級方式，都可以配合 maxSurge / maxUnavailable / partition 等策略來發布。

```yaml
apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
# ...
spec:
  updateStrategy:
  	type: InPlaceIfPossible
    maxSurge: 20%
```

如果在原地升級方式下配置了 maxSurge，CloneSet 會先擴出來 maxSurge 數量的 Pod，然後對舊版本 Pod 採用 in-place 的方式來升級（更新 Pod spec 中的 image 映象），最後在滿足 partition 終態之後再清理刪掉 maxSurge 數量的 Pod。

透過這種方式，既保證了釋出過程的業務可用性，也儘量使 Pod 釋出過程中 IP、volume 等資訊不變。

### SidecarSet 支援 volume 注入合併

SidecarSet 是 Kruise 提供的另一個重磅功能，不同於 CloneSet/StatefulSet 這些管理業務 Pod 的 workload，SidecarSet 是負責統一管理叢集中的 sidecar 容器版本和注入。

而 v0.5.0 版本中新增的功能，就是在 sidecar 容器注入的時候，解決了 SidecarSet 和 Pod 中 volume 重複定義的衝突問題。這也是來自於一個社群 issue [#254](https://github.com/openkruise/kruise/issues/254) 反饋，他們使用 SidecarSet 做日誌採集 sidecar 的管理，並期望以旁路的方式注入到所有 Pod 中。

舉個例子，我們需要往叢集中每個 Pod 都注入一個日誌採集 sidecar 容器。但是一來我們無法讓每個應用開發者都在自己的 CloneSet/Deployment 中增加這個容器的定義，二來即使在所有應用的 workload 中都加了，如果我們想要升級這個日誌採集容器的映象版本，還得更新所有應用的 workload，這樣做的成本實在太高了！

而 OpenKruise 提供的 SidcarSet 正是為了解決上述這個問題。我們只需要將 sidecar 定義寫到一個全域性的 SidcarSet 中，不管使用者用 CloneSet、Deployment、StatefulSet 等任何方式部署，擴出來的 Pod 中都會注入我們定義好的 sidecar 容器。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/bd05c7e8cff34bf28701a72db12dd79c.png)

以日誌採集為例，我們可以先定義一個 SidecarSet：

```yaml
apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
  name: log-sidecar
spec:
  selector:
    matchLabels:
      app-type: long-term  # 往所有帶 long-term 標籤的 Pod 中注入
  containers:
  - name: log-collector
    image: xxx:latest
    volumeMounts:
    - name: log-volume
      mountPath: /var/log  #  將 log-volume 的卷掛到 /var/log 目錄，採集這個目錄下的日誌
  volumes:
  - name: log-volume   # 定義一個名為 log-volume 的卷
    emptyDir: {}
```

這裡大家可能會問，如果每個應用打出日誌的目錄路徑不同，怎麼辦？不要急，這就是本次 volume merge 的功能所在。

這個時候，比如有一個應用 A 擴容的原始 Pod 如下：

```yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    app-type: long-term
spec:
  containers:
  - name: app
    image: xxx:latest
    volumeMounts:
    - name: log-volume
      mountPath: /app/logs  # 應用自己的日誌目錄
  volumes:
  - name: log-volume   # 定義一個名為 log-volume 的卷
    persistentVolumeClaim:
    	claimName: pvc-xxx
```

那麼 kruise webhook 就會將 SidecarSet 中定義的 log sidecar 容器注入到 Pod 中：

```yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    app-type: long-term
spec:
  containers:
  - name: app
    image: xxx:latest
    volumeMounts:
    - name: log-volume
      mountPath: /app/logs  # 應用自己的日誌目錄
  - name: log-collector
    image: xxx:latest
    volumeMounts:
    - name: log-volume
      mountPath: /var/log
  volumes:
  - name: log-volume   # 定義一個名為 log-volume 的卷
    persistentVolumeClaim:
    	claimName: pvc-xxx
```

可以看到，因為 SidecarSet 和 Pod 中定義的日誌 volume 名字都叫 log-volume，那麼在注入的時候就會以 Pod 中定義的 volume 為準。比如這裡 Pod 中的 volume 採用了 pvc 的方式來掛載 pv，那麼注入 sidecar 後，同樣會把這個卷掛到 sidecar 容器中的 /var/log 目錄下，然後執行日誌採集即可。

這樣以 SidecarSet 的方式管理 sidecar 容器，既和應用部署釋出做了解耦，也同樣可以和應用容器共享 volume 卷，來實現日誌採集、監控等相關 sidecar 功能。

# 總結

本次 v0.5.0 版本的升級，主要帶來了應用無損釋出和 sidecar 容器管理上更加便捷的能力。

後續 OpenKruise 還會持續在應用部署/釋出能力上做出更深的最佳化，我們也歡迎更多的同學參與到 [OpenKruise](https://github.com/openkruise/kruise) 社群來，共同建設一個場景更加豐富、完善的 K8s 應用管理、交付擴充套件能力，能夠面向更加規模化、複雜化、極致效能的場景。

# 課程推薦

為了更多開發者能夠享受到 Serverless 帶來的紅利，這一次，我們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲端計算的新正規化——Serverless。

點選即可免費觀看課程：[https://developer.aliyun.com/learning/roadmap/serverless](https://developer.aliyun.com/learning/roadmap/serverless)

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247490733&idx=1&sn=2ee3f99b24fd230d2392044980e89057&chksm=fae51762cd929e74b53deda8a6ea7df3b40ed07e71a63ad944e7e1a82db6b5c5b18f103e14d7&token=1718612764&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

OpenKruise v0.5.0 版本釋出，支援無損的流式分批發布策略

相關文章