文章共分為上下兩篇。上篇文章《靈魂拷問，上 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 專注於做這三個層次。第一個叫做應用層抽象，OAM 對使用者暴露出自己定義的應用層抽象，第一個抽象叫做 Components。Components 實際上是幫助我們定義 Deployment、StatefulSet 這樣的 Workload 的。暴露給使用者，讓他去定義這些應用的語義。第二個叫做應用特徵，叫做 Traits。運維側的概念，比如擴容策略，釋出策略，這些策略透過一個叫做 Traits 的 API 暴露給使用者。首先 OAM 給你做了一個應用層定義抽象的方式，分別叫做 Components 和 Traits。由於你需要將 Traits 應用特徵關聯給應用元件 Components，例如 Deployment 需要某種擴容策略或者是釋出策略，怎麼把他們關聯在一起呢？3. 應用配置 Application Configuration
這個就需要第三種配置叫做 Application Configuration 應用配置。最終這些概念和配置都會變成 CRD，如果你的 K8s 裡面安裝了 OAM 的 Kubernetes Runtime 元件，那麼那就能解析你 CRD 定義的策略和 Workload，最終去交給 K8s 去執行執行起來。就這麼一個元件幫助你更好地去定義抽象應用層，提供了幾個標準化的方法。這些抽象和能力交給 K8s 去處理之後，我這些能力需要的 Controller 外掛在哪？有沒有 Ready？這些版本是不是已經有了，能不能自動去安裝。這是第四個能力了：能力定義物件。這是 OAM 提供的最後一個 API，透過這個 API 可以自己去註冊 K8s 所有外掛，比如 Tekton、KEDA、istio 等。把它註冊為元件的一個能力，或者是某一個特徵。比如說 Flager，可以把它註冊為金絲雀釋出的能力，使用者只要發現這個釋出策略存在，說明這個叢集支援 Flager，那麼他就可以去使用。這就是一個以應用為中心的一個玩法。以使用者側為出發點，而不是以叢集側為出發點，使用者側透過一個上層的 api，特徵和元件來去了解他的系統，去操作他的系統。以上就是 OAM 提供的策略和方法。總結下來就是 OAM 可以透過標準化的方式幫助平臺構建者或者開發者去定義使用者側，應用側的抽象。第二點是提供了外掛化能力註冊於管理機制。並且有了這些抽象和機制之後，可以非常方便的構建可擴充套件的 UI 層。這就是 OAM 最核心的功能和價值。5. OAM 會怎樣給使用者提供一個 API 呢？
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 服務，大概是這麼一個玩法。2）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，這是用來註冊和發現外掛化能力的 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。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。A8：這裡面分幾個點，OAM 本身分兩個部分。第一部分是規範，是處於 alpha 版本，計劃在 2020 年內釋出 beta 版本。beta 就是一個穩定版本，這是一個比較明確的計劃。現在的 spec 是有可能會變的，但是有另外一個版本叫做 oam-kubernetes-runtime 外掛，這是作為獨立專案去運營的，計劃在 Q3 釋出穩定版本。即使我的 spec 發生的改變，但是外掛會做向下相容，保證 spec 變化不會影響你的系統，我們的 runtime 會提前釋出穩定版本，應該是比較快的。如果構建平臺化建議優先使用 runtime。A9：這個是有的，目前 runtime 這個專案就在做很多穩定性的東西，這是阿里內部和微軟內部的一個訴求。這塊都是在做，肯定是有這方面考慮的，包括邊界條件的一個覆蓋。Q10：可不可介紹下雙十一的狀態下，有多少個 Pod 在支援？A10：這個數量會比較大，大概在十幾萬這樣一個規模，應用容器數也是很多的。這個對大家的參考價值不是很大，因為阿里的架構和應用跟大多數同學看到的是不太一樣的，大多數是個單元化的框架，每個應用拆分的微服務非常非常細。pod 數和容器數都是非常多的。Q11：目前 OAM 只有阿里和微軟，以後像 google 這些大廠會加入麼？A11：一定會的，接下來的計劃會引入新的合作方。目前 google 和 aws 都對 OAM 有一些社群的支援。本身作為雲原生的一個規範，也是有一些想法的。在初期的時候，大廠加入的速度會比較慢，更希望的是使用者使用起來。大廠並不一定是 OAM 的主要使用者，他們更多的是商業考慮。A12：一定會的，但是並不是說直接 Mesh 一個核心能力，更多的說作為 OAM trait 使用,比如描述一個流量的拓撲關係。A13：OAM 本身就是個無狀態服務，本身的高可用方案不是很複雜。A14：目前是單叢集，但是我們馬上也會發布多叢集的模型，在阿里內部已經是多叢集模型。簡單來說多叢集是兩層模型。多叢集的概念是定義在 Scope 裡面的，透過 Scope 來決定 Workload 或者是 Components 放到哪個叢集裡面。我們會在社群儘快放出來。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69975341/viewspace-2710666/，如需轉載，請註明出處，否則將追究法律責任。