本篇內(nèi)容介紹了“怎么使用OpenYurt新增的Patch特性”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
那坡網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián),那坡網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為那坡近1000家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)公司要多少錢，請(qǐng)找那個(gè)售后服務(wù)好的那坡做網(wǎng)站的公司定做！
在正文開(kāi)始之前，我們先回顧一下單元化部署的概念和設(shè)計(jì)理念。在邊緣計(jì)算場(chǎng)景下，計(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 通過(guò) NodeSelectors 選定不同的標(biāo)簽，從而實(shí)現(xiàn)將相同的應(yīng)用部署到不同地域的需求。
但是隨著地域分布越來(lái)越多，使得運(yùn)維變得越來(lái)越復(fù)雜，具體表現(xiàn)在以下幾個(gè)方面：
當(dāng)鏡像版本升級(jí)，需要修改大量相關(guān)的 Deployment 的鏡像版本配置。
需要自定義 Deployment 的命名規(guī)范來(lái)表明相同的應(yīng)用。
缺少一個(gè)更高的視角對(duì)這些 Deployment 進(jìn)行統(tǒng)一管理和運(yùn)維。運(yùn)維的復(fù)雜性隨著應(yīng)用和地域分布增多出現(xiàn)線性增長(zhǎng)。
基于以上需求和問(wèn)題，openyurt 的 yurt-app-manager 組件提供的單元化部署（UnitedDeployment）通過(guò)更上層次的抽象，對(duì)這些子的 Deployment 進(jìn)行統(tǒng)一管理：自動(dòng)創(chuàng)建/更新/刪除，從而大幅簡(jiǎn)化了運(yùn)維復(fù)雜度的問(wèn)題。
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 配置。通過(guò) nodeSelector 可以選擇一組機(jī)器， 因此在邊緣場(chǎng)景下 Pool 我們可以簡(jiǎn)單的認(rèn)為它代表了某個(gè)地域下的一組機(jī)器。使用WorkloadTemplate + Pools的定義，我們可以很容易的將一個(gè) Deployment 或者 Statefulset 應(yīng)用分發(fā)到不同的地域中去。
下面是一個(gè)具體的 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 控制器的具體邏輯如下：
用戶定義了一個(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 控制器檢測(cè)到 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 配置。這樣通過(guò)使用 workloadTemplate+Pools 的形式，可以將 workload 分發(fā)到不同的地域，而無(wú)需用戶維護(hù)大量的 Deployment 資源。
UnitedDeployment 通過(guò)一個(gè)單元化部署實(shí)例就可以自動(dòng)維護(hù)多個(gè) Deployment 或者 Statefulset 資源，每個(gè) Deployment 或者 Statefulset 資源都遵循統(tǒng)一的命名規(guī)范。同時(shí)還能實(shí)現(xiàn) Name、NodeSelectors 和 Replicas 等的差異化配置。能極大地簡(jiǎn)化用戶在邊緣場(chǎng)景下的運(yùn)維復(fù)雜度。
UnitedDeployment 能滿足用戶的大部分需求，但是在我們進(jìn)行推廣和客戶落地以及在與社區(qū)同學(xué)討論的過(guò)程中，逐漸發(fā)現(xiàn)在一些特殊場(chǎng)景下，UnitedDeployment 提供的功能還顯得有點(diǎn)不足，例如如下場(chǎng)景：
應(yīng)用鏡像升級(jí)時(shí)候，用戶計(jì)劃先在在某個(gè)節(jié)點(diǎn)池中做驗(yàn)證，如果驗(yàn)證成功，再在所有節(jié)點(diǎn)池中全量更新發(fā)布。
為了加快鏡像拉取速度，用戶可能在不同節(jié)點(diǎn)池中搭建自己的私有鏡像倉(cāng)庫(kù)，因此同一個(gè)應(yīng)用在每個(gè)節(jié)點(diǎn)池下的鏡像名會(huì)不一樣。
不同的節(jié)點(diǎn)池下服務(wù)器數(shù)量，規(guī)格，以及業(yè)務(wù)訪問(wèn)壓力不一致，因此同一個(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)過(guò)討論我們決定在 Pool 里增加 Patch 的字段，允許用戶自定義 Patch 內(nèi)容，但是需要遵循Kubernetes 的 strategic merge patch規(guī)范，其行為與我們常用的 kubectl patch 有點(diǎn)類似。
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 里定義的內(nèi)容，需要遵循Kubernetes 的 strategic merge patch規(guī)范， 如果用過(guò) kubectl patch 的同學(xué)就很容易的知道 patch 內(nèi)容如何書寫，具體可以參照使用 kubectl patch 更新 Kubernetest api 對(duì)象。 接下來(lái)我們演示一下 UnitedDeployment patch 的使用。
提供一個(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
重慶分公司
重慶分公司
