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

作者 | 張傑（冰羽）
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/zFNyoq1quUrjZRoFvkwy9Q)

# 背景

在正文開始之前，我們先回顧一下單元化部署的概念和設計理念。在邊緣計算場景下，計算節點具有很明顯的地域分佈屬性，相同的應用可能需要部署在不同地域下的計算節點上。以 Deployment 為例，如下圖所示，傳統的做法是先將相同地域的計算節點設定成相同的標籤，然後建立多個 Deployment，不同 Deployment 透過 NodeSelectors 選定不同的標籤，從而實現將相同的應用部署到不同地域的需求。

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

但是隨著地域分佈越來越多，使得運維變得越來越複雜，具體表現在以下幾個方面：

- 當映象版本升級，需要修改大量相關的 Deployment 的映象版本配置。
- 需要自定義 Deployment 的命名規範來表明相同的應用。
- 缺少一個更高的視角對這些 Deployment 進行統一管理和運維。運維的複雜性隨著應用和地域分佈增多出現線性增長。

基於以上需求和問題，openyurt 的 yurt-app-manager 元件提供的單元化部署（UnitedDeployment）透過更上層次的抽象，對這些子的 Deployment 進行統一管理：自動建立/更新/刪除，從而大幅簡化了運維複雜度的問題。

yurt-app-manager 元件： 
[_https://github.com/openyurtio/yurt-app-manager_](https://github.com/openyurtio/yurt-app-manager)

如下圖所示：

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

單元化部署（UnitedDeployment）對這些 Workload 進行了更高層次的抽象，UnitedDeployment 包含兩個主要配置：WorkloadTemplate 和 Pools。workloadTemplate 格式可以是**Deployment** 也可以是**Statefulset**。Pools 是一個列表，每個列表都有一個 Pool 的配置，每個 Pool 都有它的 name、replicas 和 nodeSelector 配置。透過 nodeSelector 可以選擇一組機器， 因此在邊緣場景下 Pool 我們可以簡單的認為它代表了某個地域下的一組機器。使用**WorkloadTemplate + Pools** 的定義，我們可以很容易的將一個 Deployment 或者 Statefulset 應用分發到不同的地域中去。

下面是一個具體的 UnitedDeployment 例子：

```
apiVersion: apps.openyurt.io/v1alpha1
kind: UnitedDeployment
metadata:
  name: test
  namespace: default
spec:
  selector:
    matchLabels:
      app: test
  workloadTemplate:
    deploymentTemplate:
      metadata:
        labels:
          app: test
      spec:
        selector:
          matchLabels:
            app: test
        template:
          metadata:
            labels:
              app: test
          spec:
            containers:
            - image: nginx:1.18.0
              imagePullPolicy: Always
              name: nginx
  topology:
    pools:
    - name: beijing
      nodeSelectorTerm:
        matchExpressions:
        - key: apps.openyurt.io/nodepool
          operator: In
          values:
          - beijing
      replicas: 1
    - name: hangzhou
      nodeSelectorTerm:
        matchExpressions:
        - key: apps.openyurt.io/nodepool
          operator: In
          values:
          - hangzhou
      replicas: 2
```

UnitedDeployment 控制器的具體邏輯如下：

使用者定義了一個 UnitedDeployment CR , CR 裡定義了一個 DeploymentTemplate 和兩個 Pool。

- 其中 DeploymentTemplate 格式為一個 Deployment 格式定義，本例子中使用的 Image 為 **nginx:1.18.0**。
- **Pool1** 的 name 為 beijing, **replicas**=1，nodeSelector 為 apps.openyurt.io/nodepool=beijing。代表 UnitedDeployment 控制器將要建立一個子的 Deployment，replicas 為 1，nodeSelector 為 apps.openyurt.io/nodepool=beijing，其他的配置繼承自 DeploymentTemplate 配置。
- **Pool2** 的 name 為 hangzhou,**replicas**=2, nodeSelector 為 apps.openyurt.io/nodepool=hangzhou，代表 UnitedDeployment 控制器將要建立一個子的 Deployment，replicas 為 2，nodeSelector 為 apps.openyurt.io/nodepool=hangzhou，其他的配置繼承自 DeploymentTemplate 配置。

UnitedDeployment 控制器檢測到 name 為 test 的 UnitedDeployment CR 例項被建立後，會首先根據 DeploymentTemplate 裡的配置生成一個 Deployment 的模板物件，根據 Pool1 和 Pool2 的配置和 Deployment 的模板物件，分別生成 name 字首為 test-hangzhou- 和 test-beijing- 的兩個 deployment 資源物件，這兩個 Deployment 資源物件有自己的 nodeselector 和 replica 配置。這樣透過使用 workloadTemplate+Pools 的形式，可以將 workload 分發到不同的地域，而無需使用者維護大量的 Deployment 資源。

## UnitedDeployment 所解決的問題

UnitedDeployment 透過一個單元化部署例項就可以自動維護多個 Deployment 或者 Statefulset 資源，每個 Deployment 或者 Statefulset 資源都遵循統一的命名規範。同時還能實現 Name、NodeSelectors 和 Replicas 等的差異化配置。能極大地簡化使用者在邊緣場景下的運維複雜度。

# 新的需求

UnitedDeployment 能滿足使用者的大部分需求，但是在我們進行推廣和客戶落地以及在與社群同學討論的過程中，逐漸發現在一些特殊場景下，UnitedDeployment 提供的功能還顯得有點不足，例如如下場景：

- 應用映象升級時候，使用者計劃先在在某個節點池中做驗證，如果驗證成功，再在所有節點池中全量更新發布。
- 為了加快映象拉取速度，使用者可能在不同節點池中搭建自己的私有映象倉庫，因此同一個應用在每個節點池下的映象名會不一樣。
- 不同的節點池下伺服器數量，規格，以及業務訪問壓力不一致，因此同一個應用在不同節點池下 pod 的 cpu，記憶體等配置會不一樣。
- 同一個應用在不同節點池下可能會使用不同的 configmap 資源。

這些需求促使了 UnitedDeployment 需要提供針對每個 Pool 做一些個性化配置的功能，允許使用者根據不同節點池下的實際情況做一些個性化的配置，比如映象、pod 的 request 和 limit 等等。為了最大化的提供靈活性，經過討論我們決定在 Pool 裡增加 Patch 的欄位，允許使用者自定義 Patch 內容，但是需要遵循**Kubernetes 的 strategic merge patch**規範，其行為與我們常用的 kubectl patch 有點類似。

pool 裡新增 patch，示例如下：

```
    pools:
    - name: beijing
      nodeSelectorTerm:
        matchExpressions:
        - key: apps.openyurt.io/nodepool
          operator: In
          values:
          - beijing
      replicas: 1          
      patch:
        spec:
          template:
            spec:
              containers:
              - image: nginx:1.19.3
                name: nginx
```

patch 裡定義的內容，需要遵循**Kubernetes 的 strategic merge patch** 規範， 如果用過 kubectl patch 的同學就很容易的知道 patch 內容如何書寫，具體可以參照使用 kubectl patch 更新 Kubernetest api 物件。
接下來我們演示一下 UnitedDeployment patch 的使用。

# 特性演示

## 1. 環境準備

- 提供一個 K8s 叢集或者 OpenYurt 叢集，叢集裡至少 2 臺節點。一臺節點 label 為：apps.openyurt.io/nodepool=beiing, 另一臺節點 label 為：apps.openyurt.io/nodepool=hangzhou。
- 叢集裡需要安裝 yurt-app-manager 元件。

yurt-app-manager 元件： 
[_https://github.com/openyurtio/yurt-app-manager_](https://github.com/openyurtio/yurt-app-manager)

## 2. 建立 UnitedDeployment 例項

```
cat <<eof kubectl="" apply="" apiversion:="" apps.openyurt.io="" kind:="" uniteddeployment="" metadata:="" name:="" test="" namespace:="" default="" spec:="" selector:="" matchlabels:="" app:="" workloadtemplate:="" deploymenttemplate:="" labels:="" template:="" containers:="" image:="" nginx:1.18.0="" imagepullpolicy:="" always="" nginx="" topology:="" pools:="" beijing="" nodeselectorterm:="" matchexpressions:="" key:="" operator:="" in="" values:="" replicas:="" hangzhou="" eof="" workloadtemplate="" deployment="" name="" pool="" get="" deployments="" ready="" up-to-date="" available="" age="" test-beijing-rk8g8="" test-hangzhou-kfhvj="" yurt-app-manager="" nodeselector="" pod="" status="" restarts="" test-beijing-rk8g8-5df688fbc5-ssffj="" running="" test-hangzhou-kfhvj-86d7c64899-2fqdj="" test-hangzhou-kfhvj-86d7c64899-8vxqk="" test-beijing="" test-hangzhou="" patch="" edit="" ud="" container="" patch:="" nginx:1.19.3="" deploy="" yaml="" pools="" workload="" openyurt="">
                        </eof>

更靈活的邊緣雲原生運維：OpenYurt 單元化部署新增 Patch 特性

相關文章