怎樣構(gòu)建以應(yīng)用為中心的Kubernetes

怎樣構(gòu)建以應(yīng)用為中心的Kubernetes，很多新手對此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

下面將跟大家具體分享如何構(gòu)建“以應(yīng)用為中心”的 Kubernetes。

如何構(gòu)建“以應(yīng)用為中心”的 Kubernetes？

構(gòu)建這么一個(gè)以用戶為中心的 Kubernetes，需要做幾個(gè)層級的事情。

應(yīng)用層驅(qū)動(dòng)

首先來看最核心的部分，上圖中藍(lán)色部分，也就是 Kubernetes?？梢栽?Kubernetes 之上定義一組 CRD 和 Controller。可以在 CRD 來做用戶這一側(cè)的 API，比如說 pipeline 就是一個(gè) API，應(yīng)用也是一個(gè) API。像運(yùn)維側(cè)的擴(kuò)容策略這些都是可以通過 CRD 的方式安裝起來。 

##應(yīng)用層抽象

所以我們的需要解決第一個(gè)問題是應(yīng)用抽象。如果在 Kubernetes 去做應(yīng)用層抽象，就等同于定義 CRD 和 Controller，所以 Controller 可以叫做應(yīng)用層的抽象。本身可以是社區(qū)里的，比如 Tekton，istio 這些，可以作為你的應(yīng)用驅(qū)動(dòng)層。這是第一個(gè)問題，解決的是抽象的問題。不是特別難。

插件能力管理

很多功能不是 K8s 提供的，內(nèi)置的 Controller 還是有限的，大部分能力來自于社區(qū)或者是自己開發(fā)的 Controller。這時(shí)我的集群里面就會(huì)安裝好多好多插件。如果要構(gòu)建以應(yīng)用為中心的 Kubernetes，那我必須能夠管理起來這些能力，否則整個(gè)集群就會(huì)脫管了。用戶想要這么一個(gè)能力，我需要告訴他有或者是沒有。需要暴露出一個(gè) API 來告訴他，集群是否有他需要的能力。假設(shè)需要 istio 的流量切分，需要有個(gè)接口告訴用戶這個(gè)能力存不存在。不能指望用戶去 get 一下 crd 合不合適，檢查 Controller 是否運(yùn)行。這不叫以應(yīng)用為中心的 K8s，這叫裸 K8s。

所以必須有個(gè)能力，叫做插件能力管理。如果我裝了 Tekton，kEDA，istio 這些組件，我必須將這些組件注冊到能力注冊中心，讓用戶能夠發(fā)現(xiàn)這些能力，查詢這些能力。這叫做：插件能力管理。 

用戶體驗(yàn)層

有了應(yīng)用層驅(qū)動(dòng)，應(yīng)用層抽象，插件能力管理，我們才能更好地去考慮，如何給用戶暴露一個(gè)友好的 API 或者是界面出來。 有這么幾種方式，比如CLI客戶端命令行工具，或者是一個(gè) Dashboard，又或者是研發(fā)側(cè)的 Docker Compose?；蛘呖梢宰層脩魧懘a，用 python 或者 go 等實(shí)現(xiàn) DSL，這都是可以的。

用戶體驗(yàn)層怎么做，完全取決于用戶接受什么樣的方式。關(guān)鍵點(diǎn)在于以應(yīng)用為中心的 Kubernetes，UI 層就可以非常方便的基于應(yīng)用層抽象去做。比如 CLI 就可以直接創(chuàng)建一個(gè)流水線和應(yīng)用，而不是兜兜轉(zhuǎn)轉(zhuǎn)去創(chuàng)建 Deployment 和 Pod，這兩個(gè)的銜接方式是完全不一樣的。pipeline 只需要生成一下就結(jié)束了。然后去把 Pod 和 Deployment 組成一個(gè) Pipeline，那這個(gè)工作就非常繁瑣了。這是非常重要的一點(diǎn)，當(dāng)你有了應(yīng)用層驅(qū)動(dòng)，應(yīng)用層抽象，插件能力管理，再去構(gòu)建用戶體驗(yàn)層就會(huì)非常非常簡單。

Open Application Model(OAM)

如果想構(gòu)建一個(gè)應(yīng)用為中心的 Kubernetes，有沒有一個(gè)標(biāo)準(zhǔn)化的、簡單的方案呢？

下面就要為大家介紹：Open Application Model(OAM)。

OAM 的本質(zhì)是幫助你構(gòu)建一個(gè)“以應(yīng)用為中心“的 Kubernetes 標(biāo)準(zhǔn)規(guī)范和框架，相比較前面的方案，OAM 專注于做這三個(gè)層次。

應(yīng)用組件 Components

第一個(gè)叫做應(yīng)用層抽象，OAM 對用戶暴露出自己定義的應(yīng)用層抽象，第一個(gè)抽象叫做 Components。Components 實(shí)際上是幫助我們定義 Deployment、StatefulSet 這樣的 Workload 的。暴露給用戶，讓他去定義這些應(yīng)用的語義。 

應(yīng)用特征 Traits

第二個(gè)叫做應(yīng)用特征，叫做 Traits。運(yùn)維側(cè)的概念，比如擴(kuò)容策略，發(fā)布策略，這些策略通過一個(gè)叫做 Traits 的 API 暴露給用戶。首先 OAM 給你做了一個(gè)應(yīng)用層定義抽象的方式，分別叫做 Components 和 Traits。由于你需要將 Traits 應(yīng)用特征關(guān)聯(lián)給應(yīng)用組件 Components，例如 Deployment 需要某種擴(kuò)容策略或者是發(fā)布策略，怎么把他們關(guān)聯(lián)在一起呢？

應(yīng)用配置 Application Configuration

這個(gè)就需要第三種配置叫做 Application Configuration 應(yīng)用配置。最終這些概念和配置都會(huì)變成 CRD，如果你的 K8s 里面安裝了 OAM 的 Kubernetes Runtime 組件，那么那就能解析你 CRD 定義的策略和 Workload，最終去交給 K8s 去執(zhí)行運(yùn)行起來。就這么一個(gè)組件幫助你更好地去定義抽象應(yīng)用層，提供了幾個(gè)標(biāo)準(zhǔn)化的方法。

能力定義對象 Definitions

這些抽象和能力交給 K8s 去處理之后，我這些能力需要的 Controller 插件在哪？有沒有 Ready？這些版本是不是已經(jīng)有了，能不能自動(dòng)去安裝。這是第四個(gè)能力了：能力定義對象。這是 OAM 提供的最后一個(gè) API，通過這個(gè) API 可以自己去注冊 K8s 所有插件，比如 Tekton、KEDA、istio 等。

把它注冊為組件的一個(gè)能力，或者是某一個(gè)特征。比如說 Flager，可以把它注冊為金絲雀發(fā)布的能力，用戶只要發(fā)現(xiàn)這個(gè)發(fā)布策略存在，說明這個(gè)集群支持 Flager，那么他就可以去使用。這就是一個(gè)以應(yīng)用為中心的一個(gè)玩法。以用戶側(cè)為出發(fā)點(diǎn)，而不是以集群側(cè)為出發(fā)點(diǎn)，用戶側(cè)通過一個(gè)上層的 api，特征和組件來去了解他的系統(tǒng)，去操作他的系統(tǒng)。以上就是 OAM 提供的策略和方法。

總結(jié)下來就是 OAM 可以通過標(biāo)準(zhǔn)化的方式幫助平臺(tái)構(gòu)建者或者開發(fā)者去定義用戶側(cè)，應(yīng)用側(cè)的抽象。第二點(diǎn)是提供了插件化能力注冊于管理機(jī)制。并且有了這些抽象和機(jī)制之后，可以非常方便的構(gòu)建可擴(kuò)展的 UI 層。這就是 OAM 最核心的功能和價(jià)值。

OAM會(huì)怎樣給用戶提供一個(gè)API呢？

Components

Component 是工作負(fù)載的版本化定義，例如上圖中創(chuàng)建一個(gè) Component，實(shí)際上就是創(chuàng)建一個(gè) Deployment。這樣一個(gè) Component 交給 K8s 之后，首先會(huì)創(chuàng)建一個(gè) Component 來管理這個(gè) Workload，當(dāng)你修改 Component 之后就會(huì)生成一個(gè)對應(yīng)版本的 deployment。這個(gè) Component 實(shí)際上是 Deployment 的一個(gè)模板。比如我把 image 的版本修改一下，這個(gè)操作就會(huì)觸發(fā) OAM 插件，生成一個(gè)新的版本的 Deployment，這是第一個(gè)點(diǎn)。其實(shí)就版本化管理機(jī)制去管理 Component。

第二點(diǎn)是 Workload 部分完全是自定義的，或者是是可插拔的。

今天可以定義為 Deployment，明天可以定義為一個(gè)非常簡單的版本。也就是說我 Components 的抽象程度完全取決于用戶自己決定的。后期也可以改成 Knative Service，甚至改成一個(gè) Open PaaS。所以說在 Components 的 Workload 部分你可以自由的去定義自己的抽象。只要你提前安裝了對應(yīng) CRD 即可，這是一個(gè)非常高級的玩法。

此外在 OAM 中，”云服務(wù)“也是一種 Workload， 只要你能用 CRD 定義你的云服務(wù)，就可以直接在 OAM 中定義為一個(gè)應(yīng)用所依賴的組件。比如上圖中的redis實(shí)際上是阿里云的 Redis 服務(wù)，大概是這么一個(gè)玩法。

Trait 和 Application Configuration

首先 Trait 是聲明式運(yùn)維能力的描述，其實(shí)就是 Kubernetes API 對象。任何管理和運(yùn)維 Workload 的組件和能力，都可以以這種 CER 的方式定義為一個(gè) Trait。所以像 HPA，API gateway，istio 里面的 Virtual Services 都是 Trait。

Application Configuration 就像是一個(gè)信封，將 Traits 綁定給 Component，這個(gè)是顯式綁定的。OAM 里面不建議去使用 Label 這樣的松耦合的方式去關(guān)聯(lián)你的工作負(fù)載。建議通過這種結(jié)構(gòu)化的方式，通過 CRD 去顯式的綁定你的特征和工作負(fù)載。這樣的好處是我的綁定關(guān)系是可管理的?？梢酝ㄟ^ kubectl get 看到這個(gè)綁定關(guān)系。作為管理員或者用戶，就非常容易的看到某一個(gè)組件綁定的所有運(yùn)維能力有哪些，這是可以直接展示出來的，如果通過 label 是很難做到的。同時(shí) Label 本身有個(gè)問題是，本身不是版本化的，不是結(jié)構(gòu)體，很難去升級，很難去擴(kuò)展。通過這么結(jié)構(gòu)化定義，后面的升級擴(kuò)展將會(huì)變得非常簡單。

在一個(gè)用戶配置里面，可以關(guān)聯(lián)多個(gè) Components。它認(rèn)為一個(gè)應(yīng)用運(yùn)行所需要的所有組件和所依賴的運(yùn)維能力，都應(yīng)該定義為一個(gè)文件叫做 ApplicationConfiguration。所以在任何環(huán)境，只要擁有這個(gè)文件，提交之后，這個(gè)應(yīng)用就會(huì)生效了。OAM 是希望能夠提供一個(gè)自包含的應(yīng)用聲明方式。 

Definition Object

除此之外，還提到了對應(yīng)管理員提供了 Definition Object，這是用來注冊和發(fā)現(xiàn)插件化能力的 API 對象。

比如我想講 Knative Service 定義為平臺(tái)支持的一種工作負(fù)載，如上圖只需要簡單的寫一個(gè)文件即可。其中在 definitionRef 中引用 service.serving.knative.dev 即可。這樣的好處就是可以直接用 kubectl get Workload 查看 Knative Service 的 Workload。所以這是一個(gè)用來注冊和發(fā)現(xiàn)插件化能力的機(jī)制，使得用戶非常簡單的看到系統(tǒng)中當(dāng)前有沒有一個(gè)工作負(fù)載叫做 Knative Service。而不是讓用戶去看 CRD，看插件是否安裝，看 Controller 是否 running，這是非常麻煩的一件事情。所以必須有這么一個(gè)插件注冊和發(fā)現(xiàn)機(jī)制。

這一部分還有其他額外的能力，可以注冊 Trait，并且允許注冊的 Trait-A 和 Trait-B 是沖突的。這個(gè)信息也能帶進(jìn)去，這樣部署的時(shí)候檢查到 A 和 B 是沖突的，會(huì)產(chǎn)生報(bào)錯(cuò)信息。否則部署下去結(jié)果什么都不知道，兩個(gè)能力是沖突的，趕緊刪了回滾重新創(chuàng)建。OAM 在注冊的時(shí)候就會(huì)暴露出來運(yùn)維能力的沖突，這也是靠 Definition 去做的。

除此之外，OAM 的 model 這層其他的一些附加能力，能夠讓你定義更為復(fù)雜的應(yīng)用。 

總結(jié)

前面我們提到很多企業(yè)等等都在基于 Kubernetes 去構(gòu)建一個(gè)上層應(yīng)用管理平臺(tái)。Kubernetes 實(shí)際上是面向平臺(tái)開發(fā)者，而不是面向研發(fā)和應(yīng)用運(yùn)維的這么一個(gè)項(xiàng)目。它天生就是這么設(shè)計(jì)的，所以說需要基于 Kubernetes 去構(gòu)建應(yīng)用管理平臺(tái)。去更好的服務(wù)研發(fā)和運(yùn)維，這也是一個(gè)非常自然的選擇。不是說必須使用 K8s 去服務(wù)你的用戶。如果你的用戶都是 K8s 專家，這是沒問題的。如果不是的話，你去做這樣一個(gè)應(yīng)用平臺(tái)是非常自然的事情。

但是我們不想在 K8s 之前架一個(gè)像 Cloud Foundry 傳統(tǒng)的 PaaS。因?yàn)樗鼤?huì)把 K8s 的能力完全遮住。它有自己的一套 API，自己的理念，自己的模型，自己的使用方式。跟 Kubernetes 都是不太一樣的，很難把 Kubernetes 的能力給暴露出去。這是經(jīng)典 PaaS 的一個(gè)用法，但是我們不想要這么一個(gè)理念。我們的目標(biāo)是既能給用戶提供一個(gè)使用體驗(yàn)，同時(shí)又能把 Kubernetes 的能力全部發(fā)揮出來。并且使用體驗(yàn)跟 Kubernetes 是完全一致的。OAM 本質(zhì)上要做的是面向開發(fā)和運(yùn)維的，或者說是面向以應(yīng)用為中心的 Kubernetes。

所以今天所介紹的 OAM 是一個(gè)統(tǒng)一、標(biāo)準(zhǔn)、高可擴(kuò)展的應(yīng)用管理平臺(tái)，能夠以應(yīng)用為中心的全新的 Kubernetes，這是今天討論的一個(gè)重點(diǎn)。OAM 這個(gè)項(xiàng)目就是支撐這種理念的核心依賴和機(jī)制。簡單地來說 OAM 能夠讓你以統(tǒng)一的，標(biāo)準(zhǔn)化的方式去做這件事情。比如標(biāo)準(zhǔn)化定義應(yīng)用層抽象，標(biāo)準(zhǔn)化編寫底層應(yīng)用驅(qū)動(dòng)，標(biāo)準(zhǔn)化管理 K8s 插件能力。

對于平臺(tái)工程師來說，日常的工作能不能以一個(gè)標(biāo)準(zhǔn)化的框架或者依賴讓平臺(tái)工程師更簡單更快的做這件事情。這就是 OAM 給平臺(tái)工程師帶來的價(jià)值。當(dāng)然它也有些額外的好處，基于 OAM 暴露出來的新的 API 之后，你上層的UI構(gòu)建起來會(huì)非常簡單。

你的 OAM 天然分為兩類，一類叫做工作負(fù)載，一類叫做運(yùn)維特征。所以你的 UI 這層可以直接去對接了，會(huì)減少很多前端的工作。如果基于 CI/CD 做 GitOps / 持續(xù)集成發(fā)現(xiàn)也會(huì)變得非常簡單。因?yàn)樗岩粋€(gè)應(yīng)用通過自包含的方式給定義出來了，而不是說寫很多個(gè) yaml 文件。并且這個(gè)文件不僅自包含了工作負(fù)載，也包括了運(yùn)維特征。所以創(chuàng)建好了這個(gè)文件往 Kubernetes 中提交，這個(gè)應(yīng)用要做金絲雀發(fā)布或者是藍(lán)綠發(fā)布，流量控制，全部是清清楚楚的定義在這個(gè)應(yīng)用配置文件里面的。因?yàn)?GitOps 也好，持續(xù)集成也好，是不想管你的 pod 或者是 Deployment 怎么生成的，這個(gè)應(yīng)用怎么運(yùn)維，怎么 run 起來，還是要靠 Kubernetes 插件或者內(nèi)置能力去做的。這些能力都被定義到一個(gè)自包含的文件，適用于所有集群。所以這就會(huì)使得你的 GitOps 和持續(xù)集成變得簡單。

以上就是 OAM 給平臺(tái)工程師帶來的一些特有的價(jià)值。簡單來說是統(tǒng)一、標(biāo)準(zhǔn)的 API，區(qū)分研發(fā)和運(yùn)維策略，讓你的 UI 和 GitOps 特別容易去構(gòu)建。另一點(diǎn)是向下提供了高可擴(kuò)展的管理 K8s 插件能力。這樣的系統(tǒng)真正做到了標(biāo)準(zhǔn)，自運(yùn)維，一個(gè)以應(yīng)用為中心和用戶為中心的 Kubernetes 平臺(tái)。

OAM 社區(qū)

上面最后希望大家踴躍加入 OAM 社區(qū)，參與討論。上圖中有釘釘群二維碼，目前人數(shù)有幾千人，討論非常激烈，我們會(huì)在里面討論 GitOps，CI/CD，構(gòu)建 OAM 平臺(tái)等等。OAM 也有亞太地區(qū)的周會(huì)，大家可以去參加。上面的鏈接是開源項(xiàng)目地址，將這個(gè)安裝到 Kubernetes 中就可以使用上面我們說的這些能力了。

QA環(huán)節(jié)

Q1：例子中提問到了 Function 的例子，是否可以理解為 Serverless 或者是 PaaS？

A1：這樣理解是沒錯(cuò)的，可以理解為阿里云的一個(gè) Function，或者是 Knative Service。

Q2：有沒有可以讓我自由定義出相應(yīng)的規(guī)則這種規(guī)范？

A2：有的，在 OAM 里面有個(gè)規(guī)范，叫做 spec。spec 里面有提交容器化的規(guī)范。后面會(huì)增加更多抽象的規(guī)范。當(dāng)然也分類別，有一些是非常標(biāo)準(zhǔn)化的，需要嚴(yán)格遵守。有一些是比較松的，可以不用嚴(yán)格遵守。

Q3：docker-compose 的例子可否再談?wù)劊?/strong>

A3：本次 ppt 中沒有 docker-compose 的例子，但是這個(gè)其實(shí)很容易去理解，因?yàn)?OAM 將 Kubernetes API 分為兩類，一個(gè)叫做 Components，一個(gè)叫T raits。有這么一個(gè) Componets 文件，就可以直接映射 OAM 的概念，docker-compose 中有個(gè)概念叫做 Service，其實(shí)就是對應(yīng)了 OAM 中的 Component。這完全是一對一對應(yīng)關(guān)系。Service 下面有個(gè) Deployment，有個(gè)部署策略，其實(shí)對應(yīng)的就是 OAM 的 Trait。

Q4：定義阿里云的 redis 是否已經(jīng)實(shí)現(xiàn)了？

A4：已經(jīng)實(shí)現(xiàn)了，但是功能有限。內(nèi)部已經(jīng)實(shí)現(xiàn)了一個(gè)更強(qiáng)大的功能，通過 OAM 將阿里云的所有資源給創(chuàng)建起來。目前這個(gè)是在 Crossplane 去做的。但是內(nèi)部更完整的實(shí)現(xiàn)還沒有完全的放出去。我們還在規(guī)劃中，希望通過一個(gè)叫做 Alibaba Opreator 的方式暴露出去。

Q5：是否可以理解 OAM 通過管理元數(shù)據(jù)通過編寫 CRD 來打包 Components 和 Traits。

A5：可以說是對的。你把自己的 CRD 也好，社區(qū)里面的 CRD 也好，稍微做個(gè)分類或者封裝，暴露給用戶。所以對于用戶來說只要理解兩個(gè)概念——Components 和 Traits。Components 里面的內(nèi)容是靠你的 CRD 來決定的，所以說這是一個(gè)比較輕量級的抽象。

Q6：假設(shè) Components 有四個(gè)，Traits 有五個(gè)，是否可以理解為可封裝能力有 20 項(xiàng)。

A6：這個(gè)不是這么算的，不管有多少 Components 和 Trait，最終有幾個(gè)能力取決于你注冊的實(shí)際 CRD。Components 和 Traits 與背后的能力是解耦開的。

Q7：OAM 能使用 Kustomize 生成么？

A7：當(dāng)然可以了，Kustomize 使一個(gè) yaml 文件操作工具。你可以用這個(gè)工具生成任何你想要的 yaml 文件，你也可以用其他的，比如 google 的另一個(gè)項(xiàng)目叫 kpt，比如你用 DSL，json。所有可以操作 yaml 文件的工具都可以操作 OAM 文件，OAM 的 yaml 文件跟正常的 K8s 中的 yaml 沒有任何區(qū)別。在 K8s 看來 OAM 無非就是一個(gè) CRD。

Q8：OAM 是否可以生產(chǎn)可用？

A8：這里面分幾個(gè)點(diǎn)，OAM 本身分兩個(gè)部分。第一部分是規(guī)范，是處于 alpha 版本，計(jì)劃在 2020 年內(nèi)發(fā)布 beta 版本。beta 就是一個(gè)穩(wěn)定版本，這是一個(gè)比較明確的計(jì)劃?，F(xiàn)在的 spec 是有可能會(huì)變的，但是有另外一個(gè)版本叫做 oam-kubernetes-runtime 插件，這是作為獨(dú)立項(xiàng)目去運(yùn)營的，計(jì)劃在 Q3 發(fā)布穩(wěn)定版本。即使我的 spec 發(fā)生的改變，但是插件會(huì)做向下兼容，保證 spec 變化不會(huì)影響你的系統(tǒng)，我們的 runtime 會(huì)提前發(fā)布穩(wěn)定版本，應(yīng)該是比較快的。如果構(gòu)建平臺(tái)化建議優(yōu)先使用 runtime。

Q9：OAM 有沒有穩(wěn)定性考慮？比如說高可用。

A9：這個(gè)是有的，目前 runtime 這個(gè)項(xiàng)目就在做很多穩(wěn)定性的東西，這是阿里內(nèi)部和微軟內(nèi)部的一個(gè)訴求。這塊都是在做，肯定是有這方面考慮的，包括邊界條件的一個(gè)覆蓋。

Q10：可不可介紹下雙十一的狀態(tài)下，有多少個(gè) Pod 在支持？

A10：這個(gè)數(shù)量會(huì)比較大，大概在十幾萬這樣一個(gè)規(guī)模，應(yīng)用容器數(shù)也是很多的。這個(gè)對大家的參考價(jià)值不是很大，因?yàn)榘⒗锏募軜?gòu)和應(yīng)用跟大多數(shù)同學(xué)看到的是不太一樣的，大多數(shù)是個(gè)單元化的框架，每個(gè)應(yīng)用拆分的微服務(wù)非常非常細(xì)。pod 數(shù)和容器數(shù)都是非常多的。

Q11：目前 OAM 只有阿里和微軟，以后像 google 這些大廠會(huì)加入么？

A11：一定會(huì)的，接下來的計(jì)劃會(huì)引入新的合作方。目前 google 和 aws 都對 OAM 有一些社區(qū)的支持。本身作為云原生的一個(gè)規(guī)范，也是有一些想法的。在初期的時(shí)候，大廠加入的速度會(huì)比較慢，更希望的是用戶使用起來。大廠并不一定是 OAM 的主要用戶，他們更多的是商業(yè)考慮。

Q12：OAM 是否會(huì)關(guān)聯(lián) Mesh？

A12：一定會(huì)的，但是并不是說直接 Mesh 一個(gè)核心能力，更多的說作為 OAM trait 使用,比如描述一個(gè)流量的拓?fù)潢P(guān)系。

Q13：OAM 的高可用方案？

A13：OAM 本身就是個(gè)無狀態(tài)服務(wù)，本身的高可用方案不是很復(fù)雜。

Q14：OAM 考慮是單集群還是多集群？

A14：目前是單集群，但是我們馬上也會(huì)發(fā)布多集群的模型，在阿里內(nèi)部已經(jīng)是多集群模型。簡單來說多集群是兩層模型。多集群的概念是定義在 Scope 里面的，通過 Scope 來決定 Workload 或者是 Components 放到哪個(gè)集群里面。我們會(huì)在社區(qū)盡快放出來。

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注億速云行業(yè)資訊頻道，感謝您對億速云的支持。