作者 | 張杰（冰羽）
來源 | 阿里巴巴云原生公眾號(hào)

背景

在正文開始之前，我們先回顧一下單元化部署的概念和設(shè)計(jì)理念。在邊緣計(jì)算場景下，計(jì)算節(jié)點(diǎn)具有很明顯的地域分布屬性，相同的應(yīng)用可能需要部署在不同地域下的計(jì)算節(jié)點(diǎn)上。以 Deployment 為例，如下圖所示，傳統(tǒng)的做法是先將相同地域的計(jì)算節(jié)點(diǎn)設(shè)置成相同的標(biāo)簽，然后創(chuàng)建多個(gè) Deployment，不同 Deployment 通過 NodeSelectors 選定不同的標(biāo)簽，從而實(shí)現(xiàn)將相同的應(yīng)用部署到不同地域的需求。

但是隨著地域分布越來越多，使得運(yùn)維變得越來越復(fù)雜，具體表現(xiàn)在以下幾個(gè)方面：

• 當(dāng)鏡像版本升級(jí)，需要修改大量相關(guān)的 Deployment 的鏡像版本配置。
• 需要自定義 Deployment 的命名規(guī)范來表明相同的應(yīng)用。
• 缺少一個(gè)更高的視角對(duì)這些 Deployment 進(jìn)行統(tǒng)一管理和運(yùn)維。運(yùn)維的復(fù)雜性隨著應(yīng)用和地域分布增多出現(xiàn)線性增長。

基于以上需求和問題，openyurt 的?yurt-app-manager 組件提供的單元化部署（UnitedDeployment）通過更上層次的抽象，對(duì)這些子的 Deployment 進(jìn)行統(tǒng)一管理：自動(dòng)創(chuàng)建/更新/刪除，從而大幅簡化了運(yùn)維復(fù)雜度的問題。

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

如下圖所示：

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

下面是一個(gè)具體的 UnitedDeployment 例子：

apiVersion: apps.openyurt.io/v1alpha1 kind: UnitedDeployment metadata:name: testnamespace: default spec:selector:matchLabels:app: testworkloadTemplate:deploymentTemplate:metadata:labels:app: testspec:selector:matchLabels:app: testtemplate:metadata:labels:app: testspec:containers:- image: nginx:1.18.0imagePullPolicy: Alwaysname: nginxtopology:pools:- name: beijingnodeSelectorTerm:matchExpressions:- key: apps.openyurt.io/nodepooloperator: Invalues:- beijingreplicas: 1- name: hangzhounodeSelectorTerm:matchExpressions:- key: apps.openyurt.io/nodepooloperator: Invalues:- hangzhoureplicas: 2

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

用戶定義了一個(gè) UnitedDeployment CR , CR 里定義了一個(gè) DeploymentTemplate 和兩個(gè) Pool。

• 其中 DeploymentTemplate 格式為一個(gè) Deployment 格式定義，本例子中使用的 Image 為?nginx:1.18.0。
• Pool1 的 name?為 beijing,?replicas=1，nodeSelector 為 apps.openyurt.io/nodepool=beijing。代表 UnitedDeployment 控制器將要?jiǎng)?chuàng)建一個(gè)子的 Deployment，replicas 為 1，nodeSelector 為 apps.openyurt.io/nodepool=beijing，其他的配置繼承自 DeploymentTemplate 配置。
• Pool2 的 name?為 hangzhou,replicas=2, nodeSelector 為 apps.openyurt.io/nodepool=hangzhou，代表 UnitedDeployment 控制器將要?jiǎng)?chuàng)建一個(gè)子的 Deployment，replicas 為 2，nodeSelector 為 apps.openyurt.io/nodepool=hangzhou，其他的配置繼承自 DeploymentTemplate 配置。

UnitedDeployment 控制器檢測到 name 為 test 的 UnitedDeployment CR 實(shí)例被創(chuàng)建后，會(huì)首先根據(jù) DeploymentTemplate 里的配置生成一個(gè) Deployment 的模板對(duì)象，根據(jù) Pool1 和 Pool2 的配置和 Deployment 的模板對(duì)象，分別生成 name 前綴為 test-hangzhou- 和 test-beijing-?的兩個(gè) deployment 資源對(duì)象，這兩個(gè) Deployment 資源對(duì)象有自己的 nodeselector 和 replica 配置。這樣通過使用 workloadTemplate+Pools 的形式，可以將 workload 分發(fā)到不同的地域，而無需用戶維護(hù)大量的 Deployment 資源。

UnitedDeployment 所解決的問題

UnitedDeployment 通過一個(gè)單元化部署實(shí)例就可以自動(dòng)維護(hù)多個(gè) Deployment 或者 Statefulset 資源，每個(gè) Deployment 或者 Statefulset 資源都遵循統(tǒng)一的命名規(guī)范。同時(shí)還能實(shí)現(xiàn) Name、NodeSelectors 和 Replicas 等的差異化配置。能極大地簡化用戶在邊緣場景下的運(yùn)維復(fù)雜度。

新的需求

UnitedDeployment 能滿足用戶的大部分需求，但是在我們進(jìn)行推廣和客戶落地以及在與社區(qū)同學(xué)討論的過程中，逐漸發(fā)現(xiàn)在一些特殊場景下，UnitedDeployment 提供的功能還顯得有點(diǎn)不足，例如如下場景：

• 應(yīng)用鏡像升級(jí)時(shí)候，用戶計(jì)劃先在在某個(gè)節(jié)點(diǎn)池中做驗(yàn)證，如果驗(yàn)證成功，再在所有節(jié)點(diǎn)池中全量更新發(fā)布。
• 為了加快鏡像拉取速度，用戶可能在不同節(jié)點(diǎn)池中搭建自己的私有鏡像倉庫，因此同一個(gè)應(yīng)用在每個(gè)節(jié)點(diǎn)池下的鏡像名會(huì)不一樣。
• 不同的節(jié)點(diǎn)池下服務(wù)器數(shù)量，規(guī)格，以及業(yè)務(wù)訪問壓力不一致，因此同一個(gè)應(yīng)用在不同節(jié)點(diǎn)池下 pod 的 cpu，內(nèi)存等配置會(huì)不一樣。
• 同一個(gè)應(yīng)用在不同節(jié)點(diǎn)池下可能會(huì)使用不同的 configmap 資源。

這些需求促使了 UnitedDeployment 需要提供針對(duì)每個(gè) Pool 做一些個(gè)性化配置的功能，允許用戶根據(jù)不同節(jié)點(diǎn)池下的實(shí)際情況做一些個(gè)性化的配置，比如鏡像、pod 的 request 和 limit 等等。為了最大化的提供靈活性，經(jīng)過討論我們決定在 Pool 里增加 Patch 的字段，允許用戶自定義 Patch 內(nèi)容，但是需要遵循Kubernetes 的 strategic merge patch規(guī)范，其行為與我們常用的 kubectl patch 有點(diǎn)類似。

pool 里新增 patch，示例如下：

pools:- name: beijingnodeSelectorTerm:matchExpressions:- key: apps.openyurt.io/nodepooloperator: Invalues:- beijingreplicas: 1 patch:spec:template:spec:containers:- image: nginx:1.19.3name: nginx

patch 里定義的內(nèi)容，需要遵循Kubernetes 的?strategic?merge?patch 規(guī)范，?如果用過 kubectl?patch?的同學(xué)就很容易的知道 patch 內(nèi)容如何書寫，具體可以參照使用 kubectl?patch?更新 Kubernetest?api?對(duì)象。
接下來我們演示一下 UnitedDeployment patch 的使用。

特性演示

1. 環(huán)境準(zhǔn)備

• 提供一個(gè) K8s 集群或者 OpenYurt 集群，集群里至少 2 臺(tái)節(jié)點(diǎn)。一臺(tái)節(jié)點(diǎn) label 為：apps.openyurt.io/nodepool=beiing, 另一臺(tái)節(jié)點(diǎn) label 為：apps.openyurt.io/nodepool=hangzhou。
• 集群里需要安裝 yurt-app-manager 組件。

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

2. 創(chuàng)建 UnitedDeployment 實(shí)例

cat <<EOF | kubectl apply -f -apiVersion: apps.openyurt.io/v1alpha1 kind: UnitedDeployment metadata:name: testnamespace: default spec:selector:matchLabels:app: testworkloadTemplate:deploymentTemplate:metadata:labels:app: testspec:selector:matchLabels:app: testtemplate:metadata:labels:app: testspec:containers:- image: nginx:1.18.0imagePullPolicy: Alwaysname: nginxtopology:pools:- name: beijingnodeSelectorTerm:matchExpressions:- key: apps.openyurt.io/nodepooloperator: Invalues:- beijingreplicas: 1- name: hangzhounodeSelectorTerm:matchExpressions:- key: apps.openyurt.io/nodepooloperator: Invalues:- hangzhoureplicas: 2 EOF

實(shí)例中 workloadTemplate 使用了 Deployment 模板，?其中 name 為 nginx 的鏡像為 nginx:1.18.0。同時(shí)拓?fù)淅锒x了兩個(gè) pool：beijing 和 hangzhou，replicas 數(shù)目分別為 1 和 2。

3. 查看 UnitedDeployment 創(chuàng)建的 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 控制器創(chuàng)建了兩個(gè) Deployment，分布對(duì)應(yīng) beijing 和 hangzhou 的 pool，Deployment 的命名規(guī)范以 {UnitedDeployment name}-{pool name}?為前綴。查看這兩個(gè) Deployment 配置我們可以發(fā)現(xiàn)，Replicas 和 Nodeselector 繼承了對(duì)應(yīng)的每個(gè) Pool 的配置，而其他的配置則繼承了 workloadTemplate 模板的配置。

4. 查看對(duì)應(yīng)創(chuàng)建的 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

可以看到創(chuàng)建了 1 個(gè) name?前綴為 test-beijing?的 pod，2 個(gè) name?前綴為 test-hangzhou?的 pod。

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

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

格式如下：

- name: beijingnodeSelectorTerm:matchExpressions:- key: apps.openyurt.io/nodepooloperator: Invalues:- beijingreplicas: 1patch:spec:template:spec:containers:- image: nginx:1.19.3name: nginx

6. 查看 Deploy 實(shí)例配置

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

kubectl get deployments test-beijing-rk8g8 -o yaml

總結(jié)

通過 UnitedDeployment 的 workloadTemplate + Pools 的形式，可以將 workload 通過繼承的模板的方式快速分發(fā)到不同的地域。在加上 Pool 的 patch 能力，在繼承模板的配置的同時(shí)還能提供更靈活的差異化配置，基本上已經(jīng)可以滿足大部分客戶在邊緣場景下特殊的需求。

如果您對(duì)于 OpenYurt 有任何疑問，歡迎使用釘釘搜索群號(hào)（31993519）加入釘釘交流群。

總結(jié)

以上是生活随笔為你收集整理的更灵活的边缘云原生运维：OpenYurt 单元化部署新增 Patch 特性的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。