*作者：酒祝（王思宇）*

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

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

## 版本解析

在 v1.1 版本中，OpenKruise 對不少已有功能做了擴充套件與增強，並且最佳化了在大規模叢集中的執行效能。以下對 v1.1 的部分功能做簡要介紹。

值得注意的是，OpenKruise v1.1 已經將 Kubernetes **程式碼依賴版本**升級到 v1.22，這意味著使用者可以在 CloneSet 等工作負載的 pod template 模板中使用 up to v1.22 的新欄位等， 但使用者安裝使用 OpenKruise 所相容的 Kubernetes 叢集版本仍然保持在 >= v1.16。

### 原地升級支援容器順序優先順序

去年底釋出的 v1.0 版本，OpenKruise 引入了容器啟動順序控制 **[2]** 功能， 它支援為一個 Pod 中的多個容器定義不同的權重關係，並在 Pod 建立時按照權重來控制不同容器的啟動順序。

在 v1.0 中，這個功能僅僅能夠作用於每個 Pod 的建立階段。當建立完成後，如果對 Pod 中多個容器做原地升級，則這些容器都會被同時執行升級操作。

最近一段時間，社群與 LinkedIn 等公司做過一些交流，獲得了更多使用者使用場景的輸入。在一些場景下，Pod 中多個容器存在關聯關係，例如業務容器升級的同時，Pod 中其他一些容器也需要升級配置從而關聯到這個新版本；或是多個容器避免並行升級，從而保證如日誌採集類的 sidecar 容器不會丟失業務容器中的日誌等。

因此，在 v1.1 版本中 OpenKruise 支援了按容器優先順序順序的原地升級。在實際使用過程中，使用者無需配置任何額外引數，只要 Pod 在建立時已經帶有了容器啟動優先順序，則不僅在 Pod 建立階段，會保證高優先順序容器先於低優先順序容器啟動；並且在**單次原地升級**中，如果同時升級了多個容器，會先升級高優先順序容器，等待它升級啟動完成後，再升級低優先順序容器。

**這裡的原地升級，包括修改 image 映象升級與修改 env from metadata 的環境變數升級，詳見原地升級介紹[3]** 總結來說：

-   對於不存在容器啟動順序的 Pod，在多容器原地升級時沒有順序保證。
-   對於存在容器啟動順序的 Pod：

-   如果本次原地升級的多個容器具有不同的啟動順序，會按啟動順序來控制原地升級的先後順序。
-   如果本地原地升級的多個容器的啟動順序相同，則原地升級時沒有順序保證。

例如，一個包含兩個不同啟動順序容器的 CloneSet 如下：

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

當我們更新 CloneSet，將其中 app-config annotation 和 main 容器的映象修改後， 意味著 sidecar 與 main 容器都需要被更新，Kruise 會先原地升級 Pod 來將其中 sidecar 容器重建來生效新的 env from annotation。

接下來，我們可以在已升級的 Pod 中看到 apps.kruise.io/inplace-update-state annotation 和它的值：

```
{
  "revision": "{CLONESET_NAME}-{HASH}",         // 本次原地升級的目標 revision 名字
  "updateTimestamp": "2022-03-22T09:06:55Z",    // 整個原地升級的初次開始時間
  "nextContainerImages": {"main": "main-image:v2"},                // 後續批次中還需要升級的容器映象
  // "nextContainerRefMetadata": {...},                            // 後續批次中還需要升級的容器 env from labels/annotations
  "preCheckBeforeNext": {"containersRequiredReady": ["sidecar"]},  // pre-check 檢查項，符合要求後才能原地升級後續批次的容器
  "containerBatchesRecord":[
    {"timestamp":"2022-03-22T09:06:55Z","containers":["sidecar"]}  // 已更新的首個批次容器（它僅僅表明容器的 spec 已經被更新，例如 pod.spec.containers 中的 image 或是 labels/annotations，但並不代表 node 上真實的容器已經升級完成了）
  ]
}
```

當 sidecar 容器升級成功之後，Kruise 會接著再升級 main 容器。最終你會在 Pod 中看到如下的 apps.kruise.io/inplace-update-state annotation：

```
{
  "revision": "{CLONESET_NAME}-{HASH}",
  "updateTimestamp": "2022-03-22T09:06:55Z",
  "lastContainerStatuses":{"main":{"imageID":"THE IMAGE ID OF OLD MAIN CONTAINER"}},
  "containerBatchesRecord":[
    {"timestamp":"2022-03-22T09:06:55Z","containers":["sidecar"]},
    {"timestamp":"2022-03-22T09:07:20Z","containers":["main"]}
  ]
}
```

通常來說，使用者只需要關注其中 containerBatchesRecord 來確保容器是被分為多批升級的。 如果這個 Pod 在原地升級的過程中卡住了，你可以檢查 nextContainerImages/nextContainerRefMetadata 欄位，以及 preCheckBeforeNext 中前一次升級的容器是否已經升級成功並 ready 了。

### StatefulSetAutoDeletePVC 功能

從 Kubernetes v1.23 開始，原生的 StatefulSet 加入了 StatefulSetAutoDeletePVC 功能，即**根據給定策略來選擇保留或自動刪除 StatefulSet 建立的 PVC 物件**，參考文件 **[4]** 。

因此，v1.1 版本的 Advanced StatefulSet 從上游同步了這個功能，允許使用者透過 .spec.persistentVolumeClaimRetentionPolicy 欄位來指定這個自動清理策略。這需要你在安裝或升級 Kruise 的時候，啟用 StatefulSetAutoDeletePVC feature-gate 功能。

```
apiVersion: apps.kruise.io/v1beta1
kind: StatefulSet
spec:
  ...
  persistentVolumeClaimRetentionPolicy:  # optional
    whenDeleted: Retain | Delete
    whenScaled: Retain | Delete
```

其中，兩個策略欄位包括：

-   whenDeleted：當 Advanced StatefulSet 被刪除時，對 PVC 的保留/刪除策略。
-   whenScaled：當 Advanced StatefulSet 發生縮容時，對縮容 Pod 關聯 PVC 的保留/刪除策略。

每個策略都可以配置以下兩種值：

-   Retain（預設值）：它的行為與過去 StatefulSet 一樣，在 Pod 刪除時對它關聯的 PVC 做保留。
-   Delete：當 Pod 刪除時，自動刪除它所關聯的 PVC 物件。

除此之外，還有幾個注意點：

1.  StatefulSetAutoDeletePVC 功能只會清理由 volumeClaimTemplate 中定義和建立的 PVC，而不會清理使用者自己建立或關聯到 StatefulSet Pod 中的 PVC。
1.  上述清理只發生在 Advanced StatefulSet 被刪除或主動縮容的情況下。例如 node 故障導致的 Pod 驅逐重建等，仍然會複用已有的 PVC。

### Advanced DaemonSet 重構並支援生命週期鉤子

早先版本的 Advanced DaemonSet 實現與上游控制器差異較大，例如對於 not-ready 和 unschedulable 的節點需要額外配置欄位來選擇是否處理，這對於我們的使用者來說都增加了使用成本和負擔。

在 v1.1 版本中，我們對 Advanced DaemonSet 做了一次小重構，將它與上游控制器重新做了對齊。因此，Advanced DaemonSet 的所有預設行為會與原生 DaemonSet 基本一致，使用者可以像使用 Advanced StatefulSet 一樣，透過修改 apiVersion 就能很方便地將一個原生 DaemonSet 修改為 Advanced DaemonSet 來使用。

另外，我們還為 Advanced DaemonSet 增加了生命週期鉤子，首先支援 preDelete hook，來允許使用者在 daemon Pod 被刪除前執行一些自定義的邏輯。

```
apiVersion: apps.kruise.io/v1alpha1
kind: DaemonSet
spec:
  ...
  # define with label
  lifecycle:
    preDelete:
      labelsHandler:
        example.io/block-deleting: "true"
```

當 DaemonSet 刪除一個 Pod 時（包括縮容和重建升級）：

-   如果沒有定義 lifecycle hook 或者 Pod 不符合 preDelete 條件，則直接刪除。
-   否則，會先將 Pod 更新為 PreparingDelete 狀態，並等待使用者自定義的 controller 將 Pod 中關聯的 label/finalizer 去除，再執行 Pod 刪除。

### Disable DeepCopy 效能最佳化

預設情況下，我們在使用 controller-runtime 來編寫 Operator/Controller 時， 使用其中 sigs.k8s.io/controller-runtime/pkg/client Client 客戶端來 get/list 查詢物件（typed），都是從記憶體 Informer 中獲取並返回，這是大部分人都知道的。

但很多人不知道的是，在這些 get/list 操作背後，controller-runtime 會將從 Informer 中查到的所有物件做一次 deep copy 深複製後再返回。

這個設計的初衷，是避免開發者錯誤地將 Informer 中的物件直接篡改。在深複製之後，無論開發者對 get/list 返回的物件做了任何修改，都不會影響到 Informer 中的物件，後者只會從 kube-apiserver 的 ListWatch 請求中同步。

但是在一些很大規模的叢集中，OpenKruise 中各個控制器同時在執行，同時每個控制器還存在多個 worker 執行 Reconcile，可能會帶來大量的 deep copy 操作。例如叢集中有大量應用的 CloneSet，而其中一些 CloneSet 下管理的 Pod 數量非常多，則每個 worker 在 Reconcile 的時候都會 list 查詢一個 CloneSet 下的所有 Pod 物件，再加上多個 worker 並行操作， 可能造成 kruise-manager 瞬時的 CPU 和 Memory 壓力陡增，甚至在記憶體配額不足的情況下有發生 OOM 的風險。

在上游的 controller-runtime 中，我在去年已經提交合並了 DisableDeepCopy 功能 **[5]** ，包含在 controller-runtime v0.10 及以上的版本。它允許開發者指定某些特定的資源型別，在做 get/list 查詢時不執行深複製，而是直接返回 Informer 中的物件指標。

例如下述程式碼，在 main.go 中初始化 Manager 時，為 cache 加入引數即可配置 Pod 等資源型別不做深複製。

```
mgr, err := ctrl.NewManager(cfg, ctrl.Options{
        ...
        NewCache: cache.BuilderWithOptions(cache.Options{
            UnsafeDisableDeepCopyByObject: map[client.Object]bool{
                &v1.Pod{}: true,
            },
        }),
    })
```

但在 Kruise v1.1 版本中，我們沒有選擇直接使用這個功能，而是將 Delegating Client **[6]** 重新做了封裝， 從而使得開發者可以在任意做 list 查詢的地方透過 DisableDeepCopy ListOption 來指定單次的 list 操作不做深複製。

```
if err := r.List(context.TODO(), &podList, client.InNamespace("default"), utilclient.DisableDeepCopy); err != nil {
        return nil, nil, err
    }
```

這樣做的好處是使用上更加靈活，避免為整個資源型別關閉深複製後，眾多社群貢獻者在參與開發的過程中如果沒有注意到則可能會錯誤修改 Informer 中的物件。

### 其他改動

你可以透過 Github release **[7]** 頁面，來檢視更多的改動以及它們的作者與提交記錄。

## 社群參與

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

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

### 相關連結* *

[1]OpenKruise

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

[2]容器啟動順序控制

[https://openkruise.io/zh/docs/user-manuals/containerlaunchpriority/](https://openkruise.io/zh/docs/user-manuals/containerlaunchpriority/)

[3]原地升級介紹

[https://openkruise.io/zh/docs/core-concepts/inplace-update](https://openkruise.io/zh/docs/core-concepts/inplace-update)

[4]參考文件

[https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#persistentvolumeclaim-retention](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#persistentvolumeclaim-retention)

[5]DisableDeepCopy 功能

[https://github.com/kubernetes-sigs/controller-runtime/pull/1274 ](https://github.com/kubernetes-sigs/controller-runtime/pull/1274)

[6]Delegating Client

[https://github.com/openkruise/kruise/blob/master/pkg/util/client/delegating_client.go](https://github.com/openkruise/kruise/blob/master/pkg/util/client/delegating_client.go)

[7]Github release

[https://github.com/openkruise/kruise/releases](https://github.com/openkruise/kruise/releases)

[8]社群雙週會

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

[9]Slack channel

[https://kubernetes.slack.com/?redir=%2Farchives%2Fopenkruise](https://kubernetes.slack.com/?redir=%2Farchives%2Fopenkruise)

點選[**此處**](https://openkruise.io/)，檢視 OpenKruise 專案官方主頁與文件！

OpenKruise v1.1：功能增強與上游對齊，大規模場景效能最佳化

相關文章