共計 5866 個字符，預計需要花費 15 分鐘才能閱讀完成。

本篇內容介紹了“怎么使用 OpenYurt 新增的 Patch 特性”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓丸趣 TV 小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

背景

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

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

當鏡像版本升級，需要修改大量相關的 Deployment 的鏡像版本配置。

需要自定義 Deployment 的命名規范來表明相同的應用。

缺少一個更高的視角對這些 Deployment 進行統一管理和運維。運維的復雜性隨著應用和地域分布增多出現線性增長。

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

yurt-app-manager 組件：  https://github.com/openyurtio/yurt-app-manager

如下圖所示：

單元化部署（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

2. 創建 UnitedDeployment 實例

cat  EOF | kubectl apply -f -
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 
EOF

實例中 workloadTemplate 使用了 Deployment 模板，  其中 name 為 nginx 的鏡像為 nginx:1.18.0。同時拓撲里定義了兩個 pool：beijing 和 hangzhou，replicas 數目分別為 1 和 2。

3. 查看 UnitedDeployment 創建的 Deployment

# kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
test-beijing-rk8g8 1/1 1 1 6m4s
test-hangzhou-kfhvj 2/2 2 2 6m4s

可以看到 yurt-app-manager 控制器創建了兩個 Deployment，分布對應 beijing 和 hangzhou 的 pool，Deployment 的命名規范以 {UnitedDeployment name}-{pool name}  為前綴。查看這兩個 Deployment 配置我們可以發現，Replicas 和 Nodeselector 繼承了對應的每個 Pool 的配置，而其他的配置則繼承了 workloadTemplate 模板的配置。

4. 查看對應創建的 Pod

# kubectl get pod
NAME READY STATUS RESTARTS AGE
test-beijing-rk8g8-5df688fbc5-ssffj 1/1 Running 0 3m36s
test-hangzhou-kfhvj-86d7c64899-2fqdj 1/1 Running 0 3m36s
test-hangzhou-kfhvj-86d7c64899-8vxqk 1/1 Running 0 3m36s

可以看到創建了 1 個 name  前綴為 test-beijing  的 pod，2 個 name  前綴為 test-hangzhou  的 pod。

5. 使用 patch 能力做差異化配置

使用 kubectl edit ud test   命令為 beijing 的 pool 增加 patch 字段，patch 里的內容是修改 name 為 nginx 的 container 鏡像版本為：nginx:1.19.3。

格式如下：

 - 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

6. 查看 Deploy 實例配置

重新查看前綴為 test-beijing  的 Deployment，可以看到 container 的鏡像配置已經變成了 1.19.3。

 kubectl get deployments test-beijing-rk8g8 -o yaml

“怎么使用 OpenYurt 新增的 Patch 特性”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注丸趣 TV 網站，丸趣 TV 小編將為大家輸出更多高質量的實用文章！