視頻回顧鏈接：https://www.bilibili.com/video/BV1Dv411v7P4/

本文整理自 2020 年 7 月 22 日《基于 Kubernetes 與 OAM 構建統一、標準化的應用管理平臺》主題線上網絡研討會。

關注公眾號，回復?“0722” 即可下載 PPT

文章共分為上下兩篇。上篇文章《靈魂拷問，上 Kubernetes 有什么業務價值？》，主要和大家介紹了上 Kubernetes 有什么業務價值，以及什么是“以應用為中心”的 Kubernetes。本文為下篇，將跟大家具體分享如何構建“以應用為中心”的 Kubernetes。

如何構建“以應用為中心”的 Kubernetes？

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

應用層驅動

首先來看最核心的部分，上圖中藍色部分，也就是 Kubernetes。可以在 Kubernetes 之上定義一組 CRD 和 Controller。可以在 CRD 來做用戶這一側的 API，比如說 pipeline 就是一個 API，應用也是一個 API。像運維側的擴容策略這些都是可以通過 CRD 的方式安裝起來。

##應用層抽象

所以我們的需要解決第一個問題是應用抽象。如果在 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，這都是可以的。

用戶體驗層怎么做，完全取決于用戶接受什么樣的方式。關鍵點在于以應用為中心的 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 是一個統一、標準、高可擴展的應用管理平臺，能夠以應用為中心的全新的 Kubernetes，這是今天討論的一個重點。OAM 這個項目就是支撐這種理念的核心依賴和機制。簡單地來說 OAM 能夠讓你以統一的，標準化的方式去做這件事情。比如標準化定義應用層抽象，標準化編寫底層應用驅動，標準化管理 K8s 插件能力。

對于平臺工程師來說，日常的工作能不能以一個標準化的框架或者依賴讓平臺工程師更簡單更快的做這件事情。這就是 OAM 給平臺工程師帶來的價值。當然它也有些額外的好處，基于 OAM 暴露出來的新的 API 之后，你上層的UI構建起來會非常簡單。

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

以上就是 OAM 給平臺工程師帶來的一些特有的價值。簡單來說是統一、標準的 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 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的公眾號。”

總結

以上是生活随笔為你收集整理的阿里张磊：如何构建以应用为中心的“Kubernetes”?（内含 QA 整理）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。