視頻回顧連接：https://www.bilibili.com/video/BV1Dv411v7P4/前端
本文整理自 2020 年 7 月 22 日《基於 Kubernetes 與 OAM 構建統1、標準化的應用管理平臺》主題線上網絡研討會。python
關注公衆號，回覆 「0722」 便可下載 PPTredis
文章共分爲上下兩篇。上篇文章《靈魂拷問，上 Kubernetes 有什麼業務價值？》，主要和你們介紹了上 Kubernetes 有什麼業務價值，以及什麼是「以應用爲中心」的 Kubernetes。本文爲下篇，將跟你們具體分享如何構建「以應用爲中心」的 Kubernetes。docker
如何構建「以應用爲中心」的 Kubernetes？
構建這麼一個以用戶爲中心的 Kubernetes，須要作幾個層級的事情。json
應用層驅動
首先來看最核心的部分，上圖中藍色部分，也就是 Kubernetes。能夠在 Kubernetes 之上定義一組 CRD 和 Controller。能夠在 CRD 來作用戶這一側的 API，好比說 pipeline 就是一個 API，應用也是一個 API。像運維側的擴容策略這些都是能夠經過 CRD 的方式安裝起來。 api
##應用層抽象
因此咱們的須要解決第一個問題是應用抽象。若是在 Kubernetes 去作應用層抽象，就等同於定義 CRD 和 Controller，因此 Controller 能夠叫作應用層的抽象。自己能夠是社區裏的，好比 Tekton，istio 這些，能夠做爲你的應用驅動層。這是第一個問題，解決的是抽象的問題。不是特別難。網絡
插件能力管理
不少功能不是 K8s 提供的，內置的 Controller 仍是有限的，大部分能力來自於社區或者是本身開發的 Controller。這時個人集羣裏面就會安裝好多好多插件。若是要構建以應用爲中心的 Kubernetes，那我必須可以管理起來這些能力，不然整個集羣就會脫管了。用戶想要這麼一個能力，我須要告訴他有或者是沒有。須要暴露出一個 API 來告訴他，集羣是否有他須要的能力。假設須要 istio 的流量切分，須要有個接口告訴用戶這個能力存不存在。不能期望用戶去 get 一下 crd 合不合適，檢查 Controller 是否運行。這不叫以應用爲中心的 K8s，這叫裸 K8s。架構
因此必須有個能力，叫作插件能力管理。若是我裝了 Tekton，kEDA，istio 這些組件，我必須將這些組件註冊到能力註冊中心，讓用戶可以發現這些能力，查詢這些能力。這叫作：插件能力管理。 框架
用戶體驗層
有了應用層驅動，應用層抽象，插件能力管理，咱們才能更好地去考慮，如何給用戶暴露一個友好的 API 或者是界面出來。 有這麼幾種方式，好比CLI客戶端命令行工具，或者是一個 Dashboard，又或者是研發側的 Docker Compose。或者可讓用戶寫代碼，用 python 或者 go 等實現 DSL，這都是能夠的。less
用戶體驗層怎麼作，徹底取決於用戶接受什麼樣的方式。關鍵點在於以應用爲中心的 Kubernetes，UI 層就能夠很是方便的基於應用層抽象去作。好比 CLI 就能夠直接建立一個流水線和應用，而不是兜兜轉轉去建立 Deployment 和 Pod，這兩個的銜接方式是徹底不同的。pipeline 只須要生成一下就結束了。而後去把 Pod 和 Deployment 組成一個 Pipeline，那這個工做就很是繁瑣了。這是很是重要的一點，當你有了應用層驅動，應用層抽象，插件能力管理，再去構建用戶體驗層就會很是很是簡單。
Open Application Model(OAM)
若是想構建一個應用爲中心的 Kubernetes，有沒有一個標準化的、簡單的方案呢？
下面就要爲你們介紹：Open Application Model(OAM)。
OAM 的本質是幫助你構建一個「以應用爲中心「的 Kubernetes 標準規範和框架，相比較前面的方案，OAM 專一於作這三個層次。
應用組件 Components
第一個叫作應用層抽象，OAM 對用戶暴露出本身定義的應用層抽象，第一個抽象叫作 Components。Components 其實是幫助咱們定義 Deployment、StatefulSet 這樣的 Workload 的。暴露給用戶，讓他去定義這些應用的語義。
應用特徵 Traits
第二個叫作應用特徵，叫作 Traits。運維側的概念，好比擴容策略，發佈策略，這些策略經過一個叫作 Traits 的 API 暴露給用戶。首先 OAM 給你作了一個應用層定義抽象的方式，分別叫作 Components 和 Traits。因爲你須要將 Traits 應用特徵關聯給應用組件 Components，例如 Deployment 須要某種擴容策略或者是發佈策略，怎麼把他們關聯在一塊兒呢？
應用配置 Application Configuration
這個就須要第三種配置叫作 Application Configuration 應用配置。最終這些概念和配置都會變成 CRD，若是你的 K8s 裏面安裝了 OAM 的 Kubernetes Runtime 組件，那麼那就能解析你 CRD 定義的策略和 Workload，最終去交給 K8s 去執行運行起來。就這麼一個組件幫助你更好地去定義抽象應用層，提供了幾個標準化的方法。
能力定義對象 Definitions
這些抽象和能力交給 K8s 去處理以後，我這些能力須要的 Controller 插件在哪？有沒有 Ready？這些版本是否是已經有了，能不能自動去安裝。這是第四個能力了：能力定義對象。這是 OAM 提供的最後一個 API，經過這個 API 能夠本身去註冊 K8s 全部插件，好比 Tekton、KEDA、istio 等。
把它註冊爲組件的一個能力，或者是某一個特徵。好比說 Flager，能夠把它註冊爲金絲雀發佈的能力，用戶只要發現這個發佈策略存在，說明這個集羣支持 Flager，那麼他就能夠去使用。這就是一個以應用爲中心的一個玩法。以用戶側爲出發點，而不是以集羣側爲出發點，用戶側經過一個上層的 api，特徵和組件來去了解他的系統，去操做他的系統。以上就是 OAM 提供的策略和方法。
總結下來就是 OAM 能夠經過標準化的方式幫助平臺構建者或者開發者去定義用戶側，應用側的抽象。第二點是提供了插件化能力註冊於管理機制。而且有了這些抽象和機制以後，能夠很是方便的構建可擴展的 UI 層。這就是 OAM 最核心的功能和價值。
OAM會怎樣給用戶提供一個API呢？
Components
Component 是工做負載的版本化定義，例如上圖中建立一個 Component，實際上就是建立一個 Deployment。這樣一個 Component 交給 K8s 以後，首先會建立一個 Component 來管理這個 Workload，當你修改 Component 以後就會生成一個對應版本的 deployment。這個 Component 其實是 Deployment 的一個模板。好比我把 image 的版本修改一下，這個操做就會觸發 OAM 插件，生成一個新的版本的 Deployment，這是第一個點。其實就版本化管理機制去管理 Component。
第二點是 Workload 部分徹底是自定義的，或者是是可插拔的。
今天能夠定義爲 Deployment，明天能夠定義爲一個很是簡單的版本。也就是說我 Components 的抽象程度徹底取決於用戶本身決定的。後期也能夠改爲 Knative Service，甚至改爲一個 Open PaaS。因此說在 Components 的 Workload 部分你能夠自由的去定義本身的抽象。只要你提早安裝了對應 CRD 便可，這是一個很是高級的玩法。
此外在 OAM 中，」雲服務「也是一種 Workload， 只要你能用 CRD 定義你的雲服務，就能夠直接在 OAM 中定義爲一個應用所依賴的組件。好比上圖中的redis其實是阿里雲的 Redis 服務，大概是這麼一個玩法。
Trait 和 Application Configuration
首先 Trait 是聲明式運維能力的描述，其實就是 Kubernetes API 對象。任何管理和運維 Workload 的組件和能力，均可以以這種 CER 的方式定義爲一個 Trait。因此像 HPA，API gateway，istio 裏面的 Virtual Services 都是 Trait。
Application Configuration 就像是一個信封，將 Traits 綁定給 Component，這個是顯式綁定的。OAM 裏面不建議去使用 Label 這樣的鬆耦合的方式去關聯你的工做負載。建議經過這種結構化的方式，經過 CRD 去顯式的綁定你的特徵和工做負載。這樣的好處是個人綁定關係是可管理的。能夠經過 kubectl get 看到這個綁定關係。做爲管理員或者用戶，就很是容易的看到某一個組件綁定的全部運維能力有哪些，這是能夠直接展現出來的，若是經過 label 是很難作到的。同時 Label 自己有個問題是，自己不是版本化的，不是結構體，很難去升級，很難去擴展。經過這麼結構化定義，後面的升級擴展將會變得很是簡單。
在一個用戶配置裏面，能夠關聯多個 Components。它認爲一個應用運行所須要的全部組件和所依賴的運維能力，都應該定義爲一個文件叫作 ApplicationConfiguration。因此在任何環境，只要擁有這個文件，提交以後，這個應用就會生效了。OAM 是但願可以提供一個自包含的應用聲明方式。
Definition Object
除此以外，還提到了對應管理員提供了 Definition Object，這是用來註冊和發現插件化能力的 API 對象。
好比我想講 Knative Service 定義爲平臺支持的一種工做負載，如上圖只須要簡單的寫一個文件便可。其中在 definitionRef 中引用 service.serving.knative.dev 便可。這樣的好處就是能夠直接用 kubectl get Workload 查看 Knative Service 的 Workload。因此這是一個用來註冊和發現插件化能力的機制，使得用戶很是簡單的看到系統中當前有沒有一個工做負載叫作 Knative Service。而不是讓用戶去看 CRD，看插件是否安裝，看 Controller 是否 running，這是很是麻煩的一件事情。因此必須有這麼一個插件註冊和發現機制。
這一部分還有其餘額外的能力，能夠註冊 Trait，而且容許註冊的 Trait-A 和 Trait-B 是衝突的。這個信息也能帶進去，這樣部署的時候檢查到 A 和 B 是衝突的，會產生報錯信息。不然部署下去結果什麼都不知道，兩個能力是衝突的，趕忙刪了回滾從新建立。OAM 在註冊的時候就會暴露出來運維能力的衝突，這也是靠 Definition 去作的。
除此以外，OAM 的 model 這層其餘的一些附加能力，可以讓你定義更爲複雜的應用。
總結
前面咱們提到不少企業等等都在基於 Kubernetes 去構建一個上層應用管理平臺。Kubernetes 其實是面向平臺開發者，而不是面向研發和應用運維的這麼一個項目。它天生就是這麼設計的，因此說須要基於 Kubernetes 去構建應用管理平臺。去更好的服務研發和運維，這也是一個很是天然的選擇。不是說必須使用 K8s 去服務你的用戶。若是你的用戶都是 K8s 專家，這是沒問題的。若是不是的話，你去作這樣一個應用平臺是很是天然的事情。
可是咱們不想在 K8s 以前架一個像 Cloud Foundry 傳統的 PaaS。由於它會把 K8s 的能力徹底遮住。它有本身的一套 API，本身的理念，本身的模型，本身的使用方式。跟 Kubernetes 都是不太同樣的，很難把 Kubernetes 的能力給暴露出去。這是經典 PaaS 的一個用法，可是咱們不想要這麼一個理念。咱們的目標是既能給用戶提供一個使用體驗，同時又能把 Kubernetes 的能力所有發揮出來。而且使用體驗跟 Kubernetes 是徹底一致的。OAM 本質上要作的是面向開發和運維的，或者說是面向以應用爲中心的 Kubernetes。
因此今天所介紹的 OAM 是一個統1、標準、高可擴展的應用管理平臺，可以以應用爲中心的全新的 Kubernetes，這是今天討論的一個重點。OAM 這個項目就是支撐這種理念的核心依賴和機制。簡單地來講 OAM 可以讓你以統一的，標準化的方式去作這件事情。好比標準化定義應用層抽象，標準化編寫底層應用驅動，標準化管理 K8s 插件能力。
對於平臺工程師來講，平常的工做能不能以一個標準化的框架或者依賴讓平臺工程師更簡單更快的作這件事情。這就是 OAM 給平臺工程師帶來的價值。固然它也有些額外的好處，基於 OAM 暴露出來的新的 API 以後，你上層的UI構建起來會很是簡單。
你的 OAM 自然分爲兩類，一類叫作工做負載，一類叫作運維特徵。因此你的 UI 這層能夠直接去對接了，會減小不少前端的工做。若是基於 CI/CD 作 GitOps / 持續集成發現也會變得很是簡單。由於它把一個應用經過自包含的方式給定義出來了，而不是說寫不少個 yaml 文件。而且這個文件不只自包含了工做負載，也包括了運維特徵。因此建立好了這個文件往 Kubernetes 中提交，這個應用要作金絲雀發佈或者是藍綠髮布，流量控制，所有是清清楚楚的定義在這個應用配置文件裏面的。由於 GitOps 也好，持續集成也好，是不想管你的 pod 或者是 Deployment 怎麼生成的，這個應用怎麼運維，怎麼 run 起來，仍是要靠 Kubernetes 插件或者內置能力去作的。這些能力都被定義到一個自包含的文件，適用於全部集羣。因此這就會使得你的 GitOps 和持續集成變得簡單。
以上就是 OAM 給平臺工程師帶來的一些特有的價值。簡單來講是統1、標準的 API，區分研發和運維策略，讓你的 UI 和 GitOps 特別容易去構建。另外一點是向下提供了高可擴展的管理 K8s 插件能力。這樣的系統真正作到了標準，自運維，一個以應用爲中心和用戶爲中心的 Kubernetes 平臺。
OAM 社區
上面最後但願你們踊躍加入 OAM 社區，參與討論。上圖中有釘釘羣二維碼，目前人數有幾千人，討論很是激烈，咱們會在裏面討論 GitOps，CI/CD，構建 OAM 平臺等等。OAM 也有亞太地區的週會，你們能夠去參加。上面的連接是開源項目地址，將這個安裝到 Kubernetes 中就可使用上面咱們說的這些能力了。
QA環節
Q1：例子中提問到了 Function 的例子，是否能夠理解爲 Serverless 或者是 PaaS？
A1：這樣理解是沒錯的，能夠理解爲阿里雲的一個 Function，或者是 Knative Service。
Q2：有沒有可讓我自由定義出相應的規則這種規範？
A2：有的，在 OAM 裏面有個規範，叫作 spec。spec 裏面有提交容器化的規範。後面會增長更多抽象的規範。固然也分類別，有一些是很是標準化的，須要嚴格遵照。有一些是比較鬆的，能夠不用嚴格遵照。
Q3：docker-compose 的例子能否再談談？
A3：本次 ppt 中沒有 docker-compose 的例子，可是這個其實很容易去理解，由於 OAM 將 Kubernetes API 分爲兩類，一個叫作 Components，一個叫T raits。有這麼一個 Componets 文件，就能夠直接映射 OAM 的概念，docker-compose 中有個概念叫作 Service，其實就是對應了 OAM 中的 Component。這徹底是一對一對應關係。Service 下面有個 Deployment，有個部署策略，其實對應的就是 OAM 的 Trait。
Q4：定義阿里雲的 redis 是否已經實現了？
A4：已經實現了，可是功能有限。內部已經實現了一個更強大的功能，經過 OAM 將阿里雲的全部資源給建立起來。目前這個是在 Crossplane 去作的。可是內部更完整的實現尚未徹底的放出去。咱們還在規劃中，但願經過一個叫作 Alibaba Opreator 的方式暴露出去。
Q5：是否能夠理解 OAM 經過管理元數據經過編寫 CRD 來打包 Components 和 Traits。
A5：能夠說是對的。你把本身的 CRD 也好，社區裏面的 CRD 也好，稍微作個分類或者封裝，暴露給用戶。因此對於用戶來講只要理解兩個概念——Components 和 Traits。Components 裏面的內容是靠你的 CRD 來決定的，因此說這是一個比較輕量級的抽象。
Q6：假設 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 沒有任何區別。在 K8s 看來 OAM 無非就是一個 CRD。
Q8：OAM 是否能夠生產可用？
A8：這裏面分幾個點，OAM 自己分兩個部分。第一部分是規範，是處於 alpha 版本，計劃在 2020 年內發佈 beta 版本。beta 就是一個穩定版本，這是一個比較明確的計劃。如今的 spec 是有可能會變的，可是有另一個版本叫作 oam-kubernetes-runtime 插件，這是做爲獨立項目去運營的，計劃在 Q3 發佈穩定版本。即便個人 spec 發生的改變，可是插件會作向下兼容，保證 spec 變化不會影響你的系統，咱們的 runtime 會提早發佈穩定版本，應該是比較快的。若是構建平臺化建議優先使用 runtime。
Q9：OAM 有沒有穩定性考慮？好比說高可用。
A9：這個是有的，目前 runtime 這個項目就在作不少穩定性的東西，這是阿里內部和微軟內部的一個訴求。這塊都是在作，確定是有這方面考慮的，包括邊界條件的一個覆蓋。
Q10：可不可介紹下雙十一的狀態下，有多少個 Pod 在支持？
A10：這個數量會比較大，大概在十幾萬這樣一個規模，應用容器數也是不少的。這個對你們的參考價值不是很大，由於阿里的架構和應用跟大多數同窗看到的是不太同樣的，大多數是個單元化的框架，每一個應用拆分的微服務很是很是細。pod 數和容器數都是很是多的。
Q11：目前 OAM 只有阿里和微軟，之後像 google 這些大廠會加入麼？
A11：必定會的，接下來的計劃會引入新的合做方。目前 google 和 aws 都對 OAM 有一些社區的支持。自己做爲雲原生的一個規範，也是有一些想法的。在初期的時候，大廠加入的速度會比較慢，更但願的是用戶使用起來。大廠並不必定是 OAM 的主要用戶，他們更多的是商業考慮。
Q12：OAM 是否會關聯 Mesh？
A12：必定會的，可是並非說直接 Mesh 一個核心能力，更多的說做爲 OAM trait 使用,好比描述一個流量的拓撲關係。
Q13：OAM 的高可用方案？
A13：OAM 自己就是個無狀態服務，自己的高可用方案不是很複雜。
Q14：OAM 考慮是單集羣仍是多集羣？
A14：目前是單集羣，可是咱們立刻也會發布多集羣的模型，在阿里內部已是多集羣模型。簡單來講多集羣是兩層模型。多集羣的概念是定義在 Scope 裏面的，經過 Scope 來決定 Workload 或者是 Components 放到哪一個集羣裏面。咱們會在社區儘快放出來。
若是有其餘問題，建議你們加入咱們的釘釘羣進行討論。（釘釘搜索羣號：23310022，便可進羣）
「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」