怎樣構(gòu)建以應(yīng)用為中心的Kubernetes，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。
十多年的閩侯網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。網(wǎng)絡(luò)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整閩侯建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)從事“閩侯網(wǎng)站設(shè)計”,“閩侯網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。
下面將跟大家具體分享如何構(gòu)建“以應(yīng)用為中心”的 Kubernetes。
構(gòu)建這么一個以用戶為中心的 Kubernetes，需要做幾個層級的事情。
首先來看最核心的部分，上圖中藍色部分，也就是 Kubernetes?？梢栽?Kubernetes 之上定義一組 CRD 和 Controller?？梢栽?CRD 來做用戶這一側(cè)的 API，比如說 pipeline 就是一個 API，應(yīng)用也是一個 API。像運維側(cè)的擴容策略這些都是可以通過 CRD 的方式安裝起來。
所以我們的需要解決第一個問題是應(yīng)用抽象。如果在 Kubernetes 去做應(yīng)用層抽象，就等同于定義 CRD 和 Controller，所以 Controller 可以叫做應(yīng)用層的抽象。本身可以是社區(qū)里的，比如 Tekton，istio 這些，可以作為你的應(yīng)用驅(qū)動層。這是第一個問題，解決的是抽象的問題。不是特別難。
很多功能不是 K8s 提供的，內(nèi)置的 Controller 還是有限的，大部分能力來自于社區(qū)或者是自己開發(fā)的 Controller。這時我的集群里面就會安裝好多好多插件。如果要構(gòu)建以應(yīng)用為中心的 Kubernetes，那我必須能夠管理起來這些能力，否則整個集群就會脫管了。用戶想要這么一個能力，我需要告訴他有或者是沒有。需要暴露出一個 API 來告訴他，集群是否有他需要的能力。假設(shè)需要 istio 的流量切分，需要有個接口告訴用戶這個能力存不存在。不能指望用戶去 get 一下 crd 合不合適，檢查 Controller 是否運行。這不叫以應(yīng)用為中心的 K8s，這叫裸 K8s。
所以必須有個能力，叫做插件能力管理。如果我裝了 Tekton，kEDA，istio 這些組件，我必須將這些組件注冊到能力注冊中心，讓用戶能夠發(fā)現(xiàn)這些能力，查詢這些能力。這叫做：插件能力管理。
有了應(yīng)用層驅(qū)動，應(yīng)用層抽象，插件能力管理，我們才能更好地去考慮，如何給用戶暴露一個友好的 API 或者是界面出來。 有這么幾種方式，比如CLI客戶端命令行工具，或者是一個 Dashboard，又或者是研發(fā)側(cè)的 Docker Compose?；蛘呖梢宰層脩魧懘a，用 python 或者 go 等實現(xiàn) DSL，這都是可以的。
用戶體驗層怎么做，完全取決于用戶接受什么樣的方式。關(guān)鍵點在于以應(yīng)用為中心的 Kubernetes，UI 層就可以非常方便的基于應(yīng)用層抽象去做。比如 CLI 就可以直接創(chuàng)建一個流水線和應(yīng)用，而不是兜兜轉(zhuǎn)轉(zhuǎn)去創(chuàng)建 Deployment 和 Pod，這兩個的銜接方式是完全不一樣的。pipeline 只需要生成一下就結(jié)束了。然后去把 Pod 和 Deployment 組成一個 Pipeline，那這個工作就非常繁瑣了。這是非常重要的一點，當你有了應(yīng)用層驅(qū)動，應(yīng)用層抽象，插件能力管理，再去構(gòu)建用戶體驗層就會非常非常簡單。
如果想構(gòu)建一個應(yīng)用為中心的 Kubernetes，有沒有一個標準化的、簡單的方案呢？
下面就要為大家介紹：Open Application Model(OAM)。
OAM 的本質(zhì)是幫助你構(gòu)建一個“以應(yīng)用為中心“的 Kubernetes 標準規(guī)范和框架，相比較前面的方案，OAM 專注于做這三個層次。
第一個叫做應(yīng)用層抽象，OAM 對用戶暴露出自己定義的應(yīng)用層抽象，第一個抽象叫做 Components。Components 實際上是幫助我們定義 Deployment、StatefulSet 這樣的 Workload 的。暴露給用戶，讓他去定義這些應(yīng)用的語義。
第二個叫做應(yīng)用特征，叫做 Traits。運維側(cè)的概念，比如擴容策略，發(fā)布策略，這些策略通過一個叫做 Traits 的 API 暴露給用戶。首先 OAM 給你做了一個應(yīng)用層定義抽象的方式，分別叫做 Components 和 Traits。由于你需要將 Traits 應(yīng)用特征關(guān)聯(lián)給應(yīng)用組件 Components，例如 Deployment 需要某種擴容策略或者是發(fā)布策略，怎么把他們關(guān)聯(lián)在一起呢？
這個就需要第三種配置叫做 Application Configuration 應(yīng)用配置。最終這些概念和配置都會變成 CRD，如果你的 K8s 里面安裝了 OAM 的 Kubernetes Runtime 組件，那么那就能解析你 CRD 定義的策略和 Workload，最終去交給 K8s 去執(zhí)行運行起來。就這么一個組件幫助你更好地去定義抽象應(yīng)用層，提供了幾個標準化的方法。
這些抽象和能力交給 K8s 去處理之后，我這些能力需要的 Controller 插件在哪？有沒有 Ready？這些版本是不是已經(jīng)有了，能不能自動去安裝。這是第四個能力了：能力定義對象。這是 OAM 提供的最后一個 API，通過這個 API 可以自己去注冊 K8s 所有插件，比如 Tekton、KEDA、istio 等。
把它注冊為組件的一個能力，或者是某一個特征。比如說 Flager，可以把它注冊為金絲雀發(fā)布的能力，用戶只要發(fā)現(xiàn)這個發(fā)布策略存在，說明這個集群支持 Flager，那么他就可以去使用。這就是一個以應(yīng)用為中心的一個玩法。以用戶側(cè)為出發(fā)點，而不是以集群側(cè)為出發(fā)點，用戶側(cè)通過一個上層的 api，特征和組件來去了解他的系統(tǒng)，去操作他的系統(tǒng)。以上就是 OAM 提供的策略和方法。
總結(jié)下來就是 OAM 可以通過標準化的方式幫助平臺構(gòu)建者或者開發(fā)者去定義用戶側(cè)，應(yīng)用側(cè)的抽象。第二點是提供了插件化能力注冊于管理機制。并且有了這些抽象和機制之后，可以非常方便的構(gòu)建可擴展的 UI 層。這就是 OAM 最核心的功能和價值。
Component 是工作負載的版本化定義，例如上圖中創(chuàng)建一個 Component，實際上就是創(chuàng)建一個 Deployment。這樣一個 Component 交給 K8s 之后，首先會創(chuàng)建一個 Component 來管理這個 Workload，當你修改 Component 之后就會生成一個對應(yīng)版本的 deployment。這個 Component 實際上是 Deployment 的一個模板。比如我把 image 的版本修改一下，這個操作就會觸發(fā) OAM 插件，生成一個新的版本的 Deployment，這是第一個點。其實就版本化管理機制去管理 Component。
第二點是 Workload 部分完全是自定義的，或者是是可插拔的。
今天可以定義為 Deployment，明天可以定義為一個非常簡單的版本。也就是說我 Components 的抽象程度完全取決于用戶自己決定的。后期也可以改成 Knative Service，甚至改成一個 Open PaaS。所以說在 Components 的 Workload 部分你可以自由的去定義自己的抽象。只要你提前安裝了對應(yīng) CRD 即可，這是一個非常高級的玩法。
此外在 OAM 中，”云服務(wù)“也是一種 Workload， 只要你能用 CRD 定義你的云服務(wù)，就可以直接在 OAM 中定義為一個應(yīng)用所依賴的組件。比如上圖中的redis實際上是阿里云的 Redis 服務(wù)，大概是這么一個玩法。
首先 Trait 是聲明式運維能力的描述，其實就是 Kubernetes API 對象。任何管理和運維 Workload 的組件和能力，都可以以這種 CER 的方式定義為一個 Trait。所以像 HPA，API gateway，istio 里面的 Virtual Services 都是 Trait。
Application Configuration 就像是一個信封，將 Traits 綁定給 Component，這個是顯式綁定的。OAM 里面不建議去使用 Label 這樣的松耦合的方式去關(guān)聯(lián)你的工作負載。建議通過這種結(jié)構(gòu)化的方式，通過 CRD 去顯式的綁定你的特征和工作負載。這樣的好處是我的綁定關(guān)系是可管理的?？梢酝ㄟ^ kubectl get 看到這個綁定關(guān)系。作為管理員或者用戶，就非常容易的看到某一個組件綁定的所有運維能力有哪些，這是可以直接展示出來的，如果通過 label 是很難做到的。同時 Label 本身有個問題是，本身不是版本化的，不是結(jié)構(gòu)體，很難去升級，很難去擴展。通過這么結(jié)構(gòu)化定義，后面的升級擴展將會變得非常簡單。
在一個用戶配置里面，可以關(guān)聯(lián)多個 Components。它認為一個應(yīng)用運行所需要的所有組件和所依賴的運維能力，都應(yīng)該定義為一個文件叫做 ApplicationConfiguration。所以在任何環(huán)境，只要擁有這個文件，提交之后，這個應(yīng)用就會生效了。OAM 是希望能夠提供一個自包含的應(yīng)用聲明方式。
除此之外，還提到了對應(yīng)管理員提供了 Definition Object，這是用來注冊和發(fā)現(xiàn)插件化能力的 API 對象。
比如我想講 Knative Service 定義為平臺支持的一種工作負載，如上圖只需要簡單的寫一個文件即可。其中在 definitionRef 中引用 service.serving.knative.dev 即可。這樣的好處就是可以直接用 kubectl get Workload 查看 Knative Service 的 Workload。所以這是一個用來注冊和發(fā)現(xiàn)插件化能力的機制，使得用戶非常簡單的看到系統(tǒng)中當前有沒有一個工作負載叫做 Knative Service。而不是讓用戶去看 CRD，看插件是否安裝，看 Controller 是否 running，這是非常麻煩的一件事情。所以必須有這么一個插件注冊和發(fā)現(xiàn)機制。
這一部分還有其他額外的能力，可以注冊 Trait，并且允許注冊的 Trait-A 和 Trait-B 是沖突的。這個信息也能帶進去，這樣部署的時候檢查到 A 和 B 是沖突的，會產(chǎn)生報錯信息。否則部署下去結(jié)果什么都不知道，兩個能力是沖突的，趕緊刪了回滾重新創(chuàng)建。OAM 在注冊的時候就會暴露出來運維能力的沖突，這也是靠 Definition 去做的。
除此之外，OAM 的 model 這層其他的一些附加能力，能夠讓你定義更為復(fù)雜的應(yīng)用。
前面我們提到很多企業(yè)等等都在基于 Kubernetes 去構(gòu)建一個上層應(yīng)用管理平臺。Kubernetes 實際上是面向平臺開發(fā)者，而不是面向研發(fā)和應(yīng)用運維的這么一個項目。它天生就是這么設(shè)計的，所以說需要基于 Kubernetes 去構(gòu)建應(yīng)用管理平臺。去更好的服務(wù)研發(fā)和運維，這也是一個非常自然的選擇。不是說必須使用 K8s 去服務(wù)你的用戶。如果你的用戶都是 K8s 專家，這是沒問題的。如果不是的話，你去做這樣一個應(yīng)用平臺是非常自然的事情。
但是我們不想在 K8s 之前架一個像 Cloud Foundry 傳統(tǒng)的 PaaS。因為它會把 K8s 的能力完全遮住。它有自己的一套 API，自己的理念，自己的模型，自己的使用方式。跟 Kubernetes 都是不太一樣的，很難把 Kubernetes 的能力給暴露出去。這是經(jīng)典 PaaS 的一個用法，但是我們不想要這么一個理念。我們的目標是既能給用戶提供一個使用體驗，同時又能把 Kubernetes 的能力全部發(fā)揮出來。并且使用體驗跟 Kubernetes 是完全一致的。OAM 本質(zhì)上要做的是面向開發(fā)和運維的，或者說是面向以應(yīng)用為中心的 Kubernetes。
所以今天所介紹的 OAM 是一個統(tǒng)一、標準、高可擴展的應(yīng)用管理平臺，能夠以應(yīng)用為中心的全新的 Kubernetes，這是今天討論的一個重點。OAM 這個項目就是支撐這種理念的核心依賴和機制。簡單地來說 OAM 能夠讓你以統(tǒng)一的，標準化的方式去做這件事情。比如標準化定義應(yīng)用層抽象，標準化編寫底層應(yīng)用驅(qū)動，標準化管理 K8s 插件能力。
對于平臺工程師來說，日常的工作能不能以一個標準化的框架或者依賴讓平臺工程師更簡單更快的做這件事情。這就是 OAM 給平臺工程師帶來的價值。當然它也有些額外的好處，基于 OAM 暴露出來的新的 API 之后，你上層的UI構(gòu)建起來會非常簡單。
你的 OAM 天然分為兩類，一類叫做工作負載，一類叫做運維特征。所以你的 UI 這層可以直接去對接了，會減少很多前端的工作。如果基于 CI/CD 做 GitOps / 持續(xù)集成發(fā)現(xiàn)也會變得非常簡單。因為它把一個應(yīng)用通過自包含的方式給定義出來了，而不是說寫很多個 yaml 文件。并且這個文件不僅自包含了工作負載，也包括了運維特征。所以創(chuàng)建好了這個文件往 Kubernetes 中提交，這個應(yīng)用要做金絲雀發(fā)布或者是藍綠發(fā)布，流量控制，全部是清清楚楚的定義在這個應(yīng)用配置文件里面的。因為 GitOps 也好，持續(xù)集成也好，是不想管你的 pod 或者是 Deployment 怎么生成的，這個應(yīng)用怎么運維，怎么 run 起來，還是要靠 Kubernetes 插件或者內(nèi)置能力去做的。這些能力都被定義到一個自包含的文件，適用于所有集群。所以這就會使得你的 GitOps 和持續(xù)集成變得簡單。
以上就是 OAM 給平臺工程師帶來的一些特有的價值。簡單來說是統(tǒng)一、標準的 API，區(qū)分研發(fā)和運維策略，讓你的 UI 和 GitOps 特別容易去構(gòu)建。另一點是向下提供了高可擴展的管理 K8s 插件能力。這樣的系統(tǒng)真正做到了標準，自運維，一個以應(yīng)用為中心和用戶為中心的 Kubernetes 平臺。
上面最后希望大家踴躍加入 OAM 社區(qū)，參與討論。上圖中有釘釘群二維碼，目前人數(shù)有幾千人，討論非常激烈，我們會在里面討論 GitOps，CI/CD，構(gòu)建 OAM 平臺等等。OAM 也有亞太地區(qū)的周會，大家可以去參加。上面的鏈接是開源項目地址，將這個安裝到 Kubernetes 中就可以使用上面我們說的這些能力了。
Q1：例子中提問到了 Function 的例子，是否可以理解為 Serverless 或者是 PaaS？
A1：這樣理解是沒錯的，可以理解為阿里云的一個 Function，或者是 Knative Service。
Q2：有沒有可以讓我自由定義出相應(yīng)的規(guī)則這種規(guī)范？
A2：有的，在 OAM 里面有個規(guī)范，叫做 spec。spec 里面有提交容器化的規(guī)范。后面會增加更多抽象的規(guī)范。當然也分類別，有一些是非常標準化的，需要嚴格遵守。有一些是比較松的，可以不用嚴格遵守。
Q3：docker-compose 的例子可否再談?wù)劊?/strong>
A3：本次 ppt 中沒有 docker-compose 的例子，但是這個其實很容易去理解，因為 OAM 將 Kubernetes API 分為兩類，一個叫做 Components，一個叫T raits。有這么一個 Componets 文件，就可以直接映射 OAM 的概念，docker-compose 中有個概念叫做 Service，其實就是對應(yīng)了 OAM 中的 Component。這完全是一對一對應(yīng)關(guān)系。Service 下面有個 Deployment，有個部署策略，其實對應(yīng)的就是 OAM 的 Trait。
Q4：定義阿里云的 redis 是否已經(jīng)實現(xiàn)了？
A4：已經(jīng)實現(xiàn)了，但是功能有限。內(nèi)部已經(jīng)實現(xiàn)了一個更強大的功能，通過 OAM 將阿里云的所有資源給創(chuàng)建起來。目前這個是在 Crossplane 去做的。但是內(nèi)部更完整的實現(xiàn)還沒有完全的放出去。我們還在規(guī)劃中，希望通過一個叫做 Alibaba Opreator 的方式暴露出去。
Q5：是否可以理解 OAM 通過管理元數(shù)據(jù)通過編寫 CRD 來打包 Components 和 Traits。
A5：可以說是對的。你把自己的 CRD 也好，社區(qū)里面的 CRD 也好，稍微做個分類或者封裝，暴露給用戶。所以對于用戶來說只要理解兩個概念——Components 和 Traits。Components 里面的內(nèi)容是靠你的 CRD 來決定的，所以說這是一個比較輕量級的抽象。
Q6：假設(shè) Components 有四個，Traits 有五個，是否可以理解為可封裝能力有 20 項。
A6：這個不是這么算的，不管有多少 Components 和 Trait，最終有幾個能力取決于你注冊的實際 CRD。Components 和 Traits 與背后的能力是解耦開的。
Q7：OAM 能使用 Kustomize 生成么？
A7：當然可以了，Kustomize 使一個 yaml 文件操作工具。你可以用這個工具生成任何你想要的 yaml 文件，你也可以用其他的，比如 google 的另一個項目叫 kpt，比如你用 DSL，json。所有可以操作 yaml 文件的工具都可以操作 OAM 文件，OAM 的 yaml 文件跟正常的 K8s 中的 yaml 沒有任何區(qū)別。在 K8s 看來 OAM 無非就是一個 CRD。
Q8：OAM 是否可以生產(chǎn)可用？
A8：這里面分幾個點，OAM 本身分兩個部分。第一部分是規(guī)范，是處于 alpha 版本，計劃在 2020 年內(nèi)發(fā)布 beta 版本。beta 就是一個穩(wěn)定版本，這是一個比較明確的計劃?，F(xiàn)在的 spec 是有可能會變的，但是有另外一個版本叫做 oam-kubernetes-runtime 插件，這是作為獨立項目去運營的，計劃在 Q3 發(fā)布穩(wěn)定版本。即使我的 spec 發(fā)生的改變，但是插件會做向下兼容，保證 spec 變化不會影響你的系統(tǒng)，我們的 runtime 會提前發(fā)布穩(wěn)定版本，應(yīng)該是比較快的。如果構(gòu)建平臺化建議優(yōu)先使用 runtime。
Q9：OAM 有沒有穩(wěn)定性考慮？比如說高可用。
A9：這個是有的，目前 runtime 這個項目就在做很多穩(wěn)定性的東西，這是阿里內(nèi)部和微軟內(nèi)部的一個訴求。這塊都是在做，肯定是有這方面考慮的，包括邊界條件的一個覆蓋。
Q10：可不可介紹下雙十一的狀態(tài)下，有多少個 Pod 在支持？
A10：這個數(shù)量會比較大，大概在十幾萬這樣一個規(guī)模，應(yīng)用容器數(shù)也是很多的。這個對大家的參考價值不是很大，因為阿里的架構(gòu)和應(yīng)用跟大多數(shù)同學(xué)看到的是不太一樣的，大多數(shù)是個單元化的框架，每個應(yīng)用拆分的微服務(wù)非常非常細。pod 數(shù)和容器數(shù)都是非常多的。
Q11：目前 OAM 只有阿里和微軟，以后像 google 這些大廠會加入么？
A11：一定會的，接下來的計劃會引入新的合作方。目前 google 和 aws 都對 OAM 有一些社區(qū)的支持。本身作為云原生的一個規(guī)范，也是有一些想法的。在初期的時候，大廠加入的速度會比較慢，更希望的是用戶使用起來。大廠并不一定是 OAM 的主要用戶，他們更多的是商業(yè)考慮。
Q12：OAM 是否會關(guān)聯(lián) Mesh？
A12：一定會的，但是并不是說直接 Mesh 一個核心能力，更多的說作為 OAM trait 使用,比如描述一個流量的拓撲關(guān)系。
Q13：OAM 的高可用方案？
A13：OAM 本身就是個無狀態(tài)服務(wù)，本身的高可用方案不是很復(fù)雜。
Q14：OAM 考慮是單集群還是多集群？
A14：目前是單集群，但是我們馬上也會發(fā)布多集群的模型，在阿里內(nèi)部已經(jīng)是多集群模型。簡單來說多集群是兩層模型。多集群的概念是定義在 Scope 里面的，通過 Scope 來決定 Workload 或者是 Components 放到哪個集群里面。我們會在社區(qū)盡快放出來。
看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進一步的了解或閱讀更多相關(guān)文章，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。
重慶分公司
重慶分公司
