雲原生應用自動化管理套件、CNCF Sandbox 專案 -- OpenKruise，近期釋出了 v1.0 大版本。

OpenKruise **[1]**  是針對 Kubernetes 的增強能力套件，聚焦於雲原生應用的部署、升級、運維、穩定性防護等領域。所有的功能都透過 CRD 等標準方式擴充套件，可以適用於 1.16 以上版本的任意 Kubernetes 叢集。單條 helm 命令即可完成 Kruise 的一鍵部署，無需更多配置。

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a99317da93d2423eabcf307c7a1cec14~tplv-k3u1fbpfcp-zoom-1.image)

總得來看，目前 OpenKruise 提供的能力分為幾個領域：

-   **應用工作負載：** 面向無狀態、有狀態、daemon 等多種型別應用的高階部署釋出策略，例如原地升級、灰度流式釋出等。
-   **Sidecar 容器管理：** 支援獨立定義 sidecar 容器，完成動態注入、獨立原地升級、熱升級等功能。
-   **增強運維能力：** 包括容器原地重啟、映象預拉取、容器啟動順序保障等。
-   **應用分割槽管理：** 管理應用在多個分割槽（可用區、不同機型等）上的部署比例、順序、優先順序等。
-   **應用安全防護：** 幫助應用在 Kubernetes 之上獲得更高的安全性保障與可用性防護。

## 版本解析

在 v1.0 大版本中，OpenKruise 帶來了多種新的特性，同時也對不少已有功能做了增強與最佳化。

首先要說的是，從 v1.0 開始 OpenKruise 將 CRD/WehhookConfiguration 等資源配置的版本從 v1beta1 升級到 v1 **，因此可以支援 Kubernetes v1.22 及以上版本的叢集，但同時也要求 Kubernetes 的版本不能低於 v1.16。**

以下對 v1.0 的部分功能做簡要介紹，詳細的 ChangeLog 列表請檢視 OpenKruise Github 上的 release 說明以及官網文件。

### 支援環境變數原地升級

*Author:* *@FillZpp **[2]***

OpenKruise 從早期版本開始就支援了 “原地升級” 功能，主要應用於 CloneSet 與 Advanced StatefulSet 兩種工作負載上。簡單來說，原地升級使得應用在升級的過程中，不需要刪除、新建 Pod 物件，而是透過對 Pod 中容器配置的修改來達到升級的目的。![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3e8a682d8f1b41e78fe47c0d8c0f51f2~tplv-k3u1fbpfcp-zoom-1.image)

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ad603a59096e42e1a311671a02335f05~tplv-k3u1fbpfcp-zoom-1.image)

如上圖所示，原地升級過程中只修改了 Pod 中的欄位，因此：

1.  可以避免如**排程、分配 IP、分配、掛載盤**等額外的操作和代價。
1.  更快的映象拉取，因為開源複用已有舊映象的大部分 layer 層，只需要拉取新映象變化的一些 layer。
1.  當一個容器在原地升級時，Pod 的網路、掛載盤、以及 Pod 中的其他容器不會受到影響，仍然維持執行。

然而，OpenKruise 過去只能對 Pod 中 image 欄位的更新做原地升級，對於其他欄位仍然只能採用與 Deployment 相似的重建升級。一直以來，我們收到很多使用者反饋，希望支援對 env 等更多欄位的原地升級 -- 由於受到 kube-apiserver 的限制，這是很難做到的。

經過我們的不懈努力，OpenKruise 終於在 v1.0 版本中，支援了透過 Downward API 的方式支援了 env 環境變數的原地升級。例如對以下 CloneSet YAML，使用者將配置定義在 annotation 中並關聯到對應 env 中。後續在修改配置時，只需要更新 annotation value 中的值，Kruise 就會對 Pod 中所有 env 裡引用了這個 annotation 的容器觸發原地重建，從而生效這個新的 value 配置。

```
apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
metadata:
  ...
spec:
  replicas: 1
  template:
    metadata:
      annotations:
        app-config: "... the real env value ..."
    spec:
      containers:
      - name: app
        env:
        - name: APP_CONFIG
          valueFrom:
            fieldRef:
              fieldPath: metadata.annotations['app-config']
  updateStrategy:
    type: InPlaceIfPossible
```

與此同時，我們在這個版本中也去除了過去對映象原地升級的 imageID 限制，即支援相同 imageID 的兩個映象替換升級。

具體使用方式請參考文件 **[3]** 。

### 配置跨名稱空間分發

*Author:*  *@veophi **[4]***

在對 Secret、ConfigMap 等 namespace-scoped 資源進行跨 namespace 分發及同步的場景中，原生 kubernetes 目前只支援使用者 one-by-one 地進行手動分發與同步，十分地不方便。

典型的案例有：

-   當使用者需要使用 SidecarSet 的 imagePullSecrets 能力時，要先重複地在相關 namespaces 中建立對應的 Secret，並且需要確保這些 Secret 配置的正確性和一致性。
-   當使用者想要採用 ConfigMap 來配置一些**通用**的環境變數時，往往需要在多個 namespaces 做 ConfigMap 的下發，並且後續的修改往往也要求多 namespaces 之間保持同步。

因此，面對這些需要跨 namespaces 進行資源分發和**多次同步**的場景，我們期望一種更便捷的分發和同步工具來自動化地去做這件事，為此我們設計並實現了一個新的 CRD --- **ResourceDistribution**。

ResourceDistribution 目前支援 **Secret** 和 **ConfigMap** 兩類資源的分發和同步。

```
apiVersion: apps.kruise.io/v1alpha1
kind: ResourceDistribution
metadata:
  name: sample
spec:
  resource:
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: game-demo
    data:
      ...
  targets:
   namespaceLabelSelector:
      ...
    # or includedNamespaces, excludedNamespaces
```

如上述 YAML 所示，ResourceDistribution 是一類 **cluster-scoped** 的 CRD，其主要由 resource 和 targets 兩個欄位構成，其中 resource 欄位用於描述使用者所要分發的資源，targets 欄位用於描述使用者所要分發的目標名稱空間。

具體使用方式請參考文件 **[5]** 。

### 容器啟動順序控制

*Author:* *@Concurrensee **[6]***

對於 Kubernetes 的一個 Pod，其中的多個容器可能存在依賴關係，比如 容器 B 中應用程式的執行依賴於 容器 A 中的應用。因此，多個容器之間存在順序關係的需求：

-   容器 A 先啟動，啟動成功後才可以啟動 容器 B
-   容器 B 先退出，退出完成後才可以停止 容器 A

通常來說 Pod 容器的啟動和退出順序是由 Kubelet 管理的。Kubernetes 曾經有一個 KEP 計劃在 container 中增加一個 type 欄位來標識不同型別容器的啟停優先順序。但是由於 sig-node 考慮到對現有程式碼架構的改動太大，目前這個 KEP 已經被拒絕了。

因此，OpenKruise 在 v1.0 中提供了名為 **Container Launch Priority** 的功能，用於控制一個 Pod 中多個容器的強制啟動順序：

1.  對於任意一個 Pod 物件，只需要在 annotations 中定義 apps.kruise.io/container-launch-priority: Ordered，則 Kruise 會按照 Pod 中 containers 容器列表的順序來保證其中容器的序列啟動。

1.  如果要自定義 containers 中多個容器的啟動順序，則在容器 env 中新增 KRUISE_CONTAINER_PRIORITY 環境變數，value 值是範圍在 [-2147483647, 2147483647] 的整數。一個容器的 priority 值越大，會保證越先啟動。

具體使用方式請參考文件 **[7]** 。

### kubectl-kruise 命令列工具

*Author:* *@hantmac* **[8]**

過去 OpenKruise 是透過 kruise-api、client-java 等倉庫提供了 Go、Java 等語言的 Kruise API 定義以及客戶端封裝，可供使用者在自己的應用程式中引入使用。但仍然有不少使用者在測試環境下需要靈活地用命令列操作 workload 資源。

然而原生 kubectl 工具提供的 rollout、set image 等命令只能適用於原生的 workload 型別，如 Deployment、StatefulSet，並不能識別 OpenKruise 中擴充套件的 workload 型別。

因此，OpenKruise 最新提供了 kubectl-kruise 命令列工具，它是 kubectl 的標準外掛，提供了許多適用於 OpenKruise workload 的功能。

```
# rollout undo cloneset
$ kubectl kruise rollout undo cloneset/nginx
#  rollout status advanced statefulset
$ kubectl kruise rollout status statefulsets.apps.kruise.io/sts-demo
# set image of a cloneset
$ kubectl kruise set image cloneset/nginx busybox=busybox nginx=nginx:1.9.1
```

具體使用方式請參考文件 **[9]** 。

### 其餘部分功能改進與最佳化

#### CloneSet:

-   透過 scaleStrategy.maxUnavailable 策略支援流式擴容
-   Stable revision 判斷邏輯變化，當所有 Pod 版本與 updateRevision 一致時則標記為 currentRevision

#### WorkloadSpread:

-   支援接管存量 Pod 到匹配的 subset 分組中
-   最佳化 webhook 在 Pod 注入時的更新與重試邏輯

#### Advanced DaemonSet:

-   支援對 Daemon Pod 做原地升級
-   引入 progressive annotation 來選擇是否按 partition 限制 Pod 建立

#### SidecarSet:

-   解決 SidecarSet 過濾遮蔽 inactive Pod
-   在 transferenv 中新增 SourceContainerNameFrom 和 EnvNames 欄位，來解決 container name 不一致與大量 env 情況下的冗餘問題

#### PodUnavailableBudget:

-   新增 “跳過保護” 標識
-   PodUnavailableBudget controller 關注 workload 工作負載的 replicas 變化

#### NodeImage:

-   加入 --nodeimage-creation-delay 引數，並預設等待新增 Node ready 一段時間後同步建立 NodeImage

#### UnitedDeployment:

-   解決 NodeSelectorTerms 為 nil 情況下 Pod NodeSelectorTerms 長度為 0 的問題

#### Other optimization:

-   kruise-daemon 採用 protobuf 協議操作 Pod 資源
-   暴露 cache resync 為命令列引數，並在 chart 中設定預設值為 0
-   解決 certs 更新時的 http checker 重新整理問題
-   去除對 forked controller-tools 的依賴，改為使用原生 controller-tools 配合 markers 註解

## 社群參與

非常歡迎你透過 Github/Slack/釘釘/微信 等方式加入我們來參與 OpenKruise 開源社群。你是否已經有一些希望與我們社群交流的內容呢？可以在我們的社群雙週會 **[10]** 上分享你的聲音，或透過以下渠道參與討論：

-   加入社群 Slack channel **[11]** (English)
-   加入社群釘釘群：搜尋群號 23330762 (Chinese)
-   加入社群微信群：新增使用者 openkruise 並讓機器人拉你入群 (Chinese)

## 參考資料

[1]  OpenKruise:

[*https://openkruise.io*](https://openkruise.io)

[2]  @FillZpp:

[*https://github.com/FillZpp*](https://github.com/FillZpp)

[3]  文件:

*/docs/core-concepts/inplace-update*

[4]  @veophi:

[*https://github.com/veophi*](https://github.com/veophi)

[5]  文件:

*/docs/user-manuals/resourcedistribution*

[6]  @Concurrensee:

[*https://github.com/Concurrensee*](https://github.com/Concurrensee)

[7]  文件:

*/docs/user-manuals/containerlaunchpriority*

[8]  @hantmac:

[*https://github.com/hantmac*](https://github.com/hantmac)

[9]  文件:

*/docs/cli-tool/kubectl-plugin*

[10]  社群雙週會:

[*https://shimo.im/docs/gXqmeQOYBehZ4vqo*](https://shimo.im/docs/gXqmeQOYBehZ4vqo)

[11]  Slack channel:

[*https://kubernetes.slack.com/channels/openkruise*](https://kubernetes.slack.com/channels/openkruise)

戳[原文](https://openkruise.io/)，檢視 OpenKruise 專案官方主頁與文件！

OpenKruise v1.0：雲原生應用自動化達到新的高峰

相關文章