作者：司徒放
稽核&校對：田瑋靖、溪洋
編輯&排版：雯燕
導語： 雲原生時代，直接使用 Kubernetes 和雲基礎設施過於複雜，如使用者需要學習很多底層細節、應用管理的上手成本高、容易出錯、故障頻頻。隨著雲端計算的普及，不同雲又有不同的細節，進一步加劇了上述問題。
本文將介紹如何在 Kubernetes 上構建新的應用管理平臺，提供一層抽象以封裝底層邏輯，只呈現使用者關心的介面，使使用者可以只關注自己的業務邏輯，管理應用更快更安全。
雲原生時代是一個非常好的時代，我們所面臨的是整體技術的顛覆性革新，全面地對應用做端到端重構。目前，雲原生在演進過程中產生了三個關鍵技術：
- 一是容器化，容器作為標準化互動的介質，在運維效率、部署密度和資源隔離性方面相比傳統方式有很大改進，據 CNCF 最新調研報告顯示，目前已有 92% 的企業生產系統在使用容器；
- 二是 Kubernetes，它對基礎設施進行了抽象和管理，現已成為雲原生的標配；
- 三是 Operator 自動化運維，通過控制器和定製資源的機制，使 Kubernetes 不僅可以運維無狀態應用，還可以執行由使用者定義的運維能力，實現更復雜的自動化運維應用進行自動化部署和互動。
這三項關鍵技術其實是逐漸演進的關係，另外，在應用交付領域，也有與之對應的理論在跟隨上述技術不斷地演進。雲原生的崛起，帶來了交付介質、基礎設施管理、運維模型和持續交付理論的全面升級和突破，加速了雲端計算時代的到來。
從 CNCF 釋出的雲原生技術全景圖（見圖 1）中，可以看到雲原生的蓬勃生態，細數圖中這 900 + Logo，其中不乏開源專案、創業公司，未來雲原生的技術都會在這些地方誕生。
雲原生 “作業系統” Kubernetes 帶來的應用交付挑戰
上文提到，Kubernetes 已成為雲原生的標配，其對下封裝基礎設施的差異，對上支援各種應用的運維部署，如無狀態應用、微服務，再如有狀態、批處理、大資料、AI、區塊鏈等新技術的應用，在 Kubernetes 上面都有辦法部署。Kubernetes 已經成為了現實意義的 “作業系統” 。它在雲原生的地位正如移動裝置中的 Android。為什麼這樣講？Android 不僅僅裝在我們的手機上，它還進一步滲透到汽車、電視、天貓精靈等智慧終端裡，移動應用可以通過 Android 執行在這些裝置上。而 Kubernetes 也有這樣的潛力或發展趨勢，當然它不是出現在智慧家電中，而是出現在各家公有云、自建機房，以及邊緣叢集。可以預想，Kubernetes 未來會像 Android 一樣無處不在。
那麼，有了 Kubernetes 這層交付以後，容器 + Kubernetes 這層介面是不是就可以解決掉所有的交付問題了？答案肯定不是。試想，如果我們的手機中只有 Android 系統，它能夠滿足我們工作和生活需求嗎？不能，必須有各種各樣的軟體應用才行。對應到雲原生，它除了 Kubernetes 這個 “作業系統” 外，也需要一套應用的交付能力。在手機中，軟體應用可以通過類似“豌豆莢”這樣的應用以便使用者安裝，同樣在雲原生時代，我們也需要將應用部署到不同的 Kubernetes 叢集上。但由於 Kubernetes 海量瑣碎的設施細節與複雜各異的操作語言，導致部署過程中會遇到各種各樣的問題，這時就需要雲原生的“豌豆莢”來解決這個問題，也就是應用管理平臺，去遮蔽交付的複雜性。
應用管理平臺在業界有兩種主流模式，第一種是傳統平臺模式，在 Kubernetes 上 “蓋一個大帽子” ，將所有複雜度遮蔽，在此之上，再根據需求自己提供一層簡化的應用抽象。通過這種方式，雖然應用平臺變得易用了，但新的能力需要由平臺開發實現，也就帶來了擴充套件難、迭代緩慢的問題，無法滿足日益增長的應用管理訴求。
另一種解法是容器平臺模式。這種模式比較雲原生，元件是開放的，擴充套件性強，但是，它缺乏應用層的抽象，導致了很多問題，比如開發者學習路線陡峭。舉個例子，當一個業務開發者把自己的程式碼提交到應用平臺時，他需要寫 Deployment 部署應用、寫 Prometheus 規則配置監控、寫 HPA 設定彈性伸縮，寫 Istio 規則控制路由等，這些都不是業務開發希望去做的。
所以，不論是哪種解法，都有優缺點，需要取捨。那麼，到底怎麼做才能封裝平臺的複雜性，還能擁有良好的擴充套件性？這是我們一直在探索的。
通過應用管理平臺，遮蔽雲原生應用交付的複雜性
2012 年，阿里巴巴已經開始做容器化相關的調研，起初主要是為了提高資源利用率，開始了自研容器虛擬化技術之路。隨著應對大促的機器資源量不斷增多，在 2015 年開始採用容器的混合雲彈性架構，並使用阿里雲的公有云計算資源，支撐大促流量高峰。這也是阿里巴巴做雲原生的早期階段。
轉折發生在 2018 年，阿里巴巴的底層排程採用開源的 Kubernetes 後，我們從面對虛擬機器的指令碼化安裝部署模式，轉變為基於標準的容器排程系統部署應用，全面推進阿里巴巴基礎設施的 Kubernetes 升級。但很快，新的問題就出現了：應用平臺沒有標準、不統一，大家“各自為政”。
因此，我們在 2019 年攜手微軟釋出了開放應用模型——OAM（Open Application Model），並開始做 OAM 平臺化改造。一切都比較順利，2020 年 OAM 的實現引擎 KubeVela 正式開源，在內部推進多套應用管理平臺基於 OAM 和 KubeVela 演進。並推動了三位一體戰略，不僅阿里內部的核心繫統全面使用這套技術，而且在面向客戶的商業化雲產品以及在開源時，都使用同樣的技術。通過全面擁抱開源，讓整個 OAM 和 KubeVela 社群參與共建。
在這段探索歷程中，我們走了不少彎路，也累積了許多踩坑經驗，接下來將作具體介紹，同時分享 KubeVela 的設計原理和使用方法，幫助開發者瞭解雲原生應用管理平臺的完整解決方案，提高應用開發者的使用體驗和應用交付效率。
雲原生應用管理平臺的解決方案
在探索雲原生應用管理平臺解決方案的過程中，我們主要遇到 4 項重大挑戰，並總結了 4 個基本原則，下文將一一介紹。
挑戰 1：不同場景的應用平臺介面不統一，重複建設。
雖然，雲原生有了 Kubernetes 系統，但在不同場景它會構建不一樣的應用平臺，且介面完全不統一，交付能力存在很大差異，比如 AI、中介軟體、Serverless 和電商線上業務都有各自不同的服務平臺。因此，在構建應用管理平臺時，難免重複開發和重複運維。最理想的狀況當然是實現複用，但運維平臺架構模式各有不同，沒辦法做到互通。另外，業務開發者在不同場景對接應用交付時，對接的 API 完全不同，交付能力存在很大差異。這是我們遇到的第一個挑戰。
挑戰 2：“面向終態”無法滿足過程式的交付方式。
在雲原生時代，面向終態的設計很受歡迎，因為它能減少使用者對實現過程的關心。使用者只需要描述自己想要什麼，不需要詳細規劃執行路徑，系統就能自動把事情做好。但在實際使用過程中，交付過程通常需要審批、暫停觀察、調整等人為干預。舉個例子，我們的 Kubernetes 系統在交付過程中處於強管護的狀態，要審批發布。在《阿里集團變更管理規範》中明確 “線上變更，前 x 個線上生產環境批次，每個批次變更後觀察時間應大於 y 分鐘。” “必須先在安全生產環境（SPE）內進行釋出，只有在 SPE 驗證無問題後，才能線上上生產環境進行灰度釋出。” 因此，應用交付是一個程式導向而非面向終態的執行流程，我們必須考慮，怎樣讓它更好地適應程式導向的流程。
挑戰 3：平臺能力擴充套件複雜度太高。
上文提到，傳統模式下的應用平臺擴充套件性差，那麼在雲原生時代，有哪些常見擴充套件平臺的機制？在 Kubernetes 系統中，可以直接用 Go Template 等模板語言做部署，但缺點是靈活性不夠，整個模板寫下來結構複雜，難以做大規模的維護。有些高手可能會說 “我可以自定義一套 Kubernetes Controller，擴充套件性一定很好！” 沒錯，但是，瞭解 Kubernetes 及 CRD 擴充套件機制的人比較少。即使高手把 Controller 寫出來了，他還有後續的許多工作要做，比如需要編譯並將其安裝在 Kubernetes 上執行，另外，Controller 數量也不能一直這樣膨脹上去。因此，要想做一個高可擴充套件的應用平臺有很大挑戰。
挑戰 4：不同環境不同場景，交付差異巨大。
在應用交付過程中，對於不同用途的環境，其運維能力差異特別大。比如開發測試環境，重視開發和聯調效率，每次修改採用熱載入，不重新打包、走映象部署的一套流程，同時為開發人員部署按需建立的獨立環境。再比如預發聯調環境，有攻防演練、故障注入的日常運維訴求。以及在生產環境，需要加入安全生產、服務高可用方面的運維能力。此外，同一個應用，元件依賴也有巨大差異，資料庫、負載均衡、儲存，在不同雲上存在諸多差異。
針對以上四項挑戰，我們總結了現代應用管理平臺的 4 點核心設計原則：
- 統一的、基礎設施無關的開放應用模型。
- 圍繞工作流的宣告式交付。
- 高度可擴充套件，易程式設計。
- 面向混合環境的設計。
原則1：統一的、基礎設施無關的開放應用模型。
怎樣提煉統一的、基礎設施無關的開放應用模型呢？以開放應用模型，即 OAM 為例，首先，它的設計非常簡單，且能夠大幅簡化我們對管理平臺的使用：原來使用者要面對上百個 API，OAM 將其抽象成 4 類交付模型。其次，OAM 從業務開發者視角描述要交付的元件，要用到的運維能力和交付策略，由平臺開發者提供運維能力和交付策略的實現，從而對開發者遮蔽基礎設施細節與差異性。通過元件模型，OAM 可以用來描述容器、虛擬機器、雲服務、Terraform 元件、Helm 等製品。
如圖 2，這是用 OAM 描述的一個 KubeVela 應用交付示例，裡面包含上述 4 類模型。首先，要描述一個應用部署時包含的待交付元件（Component），一般是映象、製品包、雲服務等形式；其次，要描述應用部署後用到的運維能力（Trait），比如路由規則、自動擴縮容規則等，運維能力都作用於元件上；再次，是交付策略（Policy），比如叢集分發策略、健康檢查策略、防火牆規則等，任何一個部署前需要遵守的規則都可以在這個階段宣告和執行；最後，是工作流（Workflow）的定義，比如藍綠部署、帶流量的漸進式部署、手動審批等任意的管道式持續交付策略。
原則 2：圍繞工作流做宣告式的交付。
上面 4 類模型中最核心的是工作流，應用交付本質上是一次編排，將元件、運維能力、交付策略、工作流步驟等按順序定義在一個有向無環圖 DAG 裡面。
圖 3 KubeVela 通過工作流編排應用交付的示例
舉個例子，應用交付前的第一步，比如安裝系統部署依賴、初始化檢查等，通過交付策略描述並在交付最開始的時候執行；第二步是依賴的部署，比如應用依賴了資料庫，我們可以通過元件建立相關的雲資源，也可以引用一個已有的資料庫資源，將資料庫連線串作為環境引數注入到應用環境中；第三步是用元件部署應用本身，包括映象版本、開放埠等；第四步是應用的運維能力，比如設定監控方式、彈性伸縮策略、負載均衡等；第五步是線上上環境插入一個人工稽核，檢查應用啟動是否有問題，人工確認沒問題之後再繼續讓工作流往下走；第六步是將剩下的資源並行部署完，然後通過釘釘訊息做回撥，將部署完的訊息告訴開發人員。這就是我們在真實場景中的交付流程。
這個工作流最大的價值在於，它把一個複雜的、面向不同環境的交付過程通過標準化的程式，較為規範地描述了出來。
原則 3：高度可擴充套件、易程式設計。
我們一直希望能夠像樂高積木一樣構建應用模組，平臺開發者可以使用平臺的業務開發輕鬆擴充套件應用平臺的能力。但前文提到，用模板語言這種方式，靈活性不夠、擴充套件性不足，而寫 Kubernetes Controller 又太複雜、對開發者的專業能力要求極高。那怎麼才能既有高度可擴充套件性，又有程式設計的靈活性？我們最後借鑑了谷歌 Borg 的 CUElang，這是一個適合做資料模板化、資料傳遞的配置語言。它天然適合呼叫 Go 語言，很容易與 Kubernetes 生態融合，具備高靈活性。而且 CUElang 是動態配置語言，不需要編譯釋出，響應速度快，只要將規則釋出到 Kubernetes，就立馬生效。
圖 4 KubeVela 動態擴充套件機制
以 KubeVela 的動態擴充套件機制為例，平臺開發者編寫完 Web 服務、定時任務等元件模板，以及彈性伸縮、滾動升級等運維能力模板後，將這些能力模板（OAM X-Definition）註冊到對應的環境。KubeVela 根據能力模板內容將能力執行時需要的依賴安裝到對應環境的叢集上。此時，應用開發者就可以使用平臺開發者剛才編寫的這些模板，他通過選擇元件和運維能力構建出一個應用 Application yaml，並將 yaml 釋出到 KubeVela 控制面上。KubeVela 通過 Application yaml 編排應用，執行對應選取的能力模板，最終把應用釋出到 Kubernetes 叢集中。整個從能力定義、應用描述，到最終完成交付的過程就完成了。
原則4：面向混合環境的設計。
在 KubeVela 設計之初，我們就考慮到未來可能是在混合環境（混合雲/多雲/分散式雲/邊緣）中做應用的交付，且不同環境、不同場景的交付差異較大。我們做了兩件事。第一，將 KubeVela 控制平面完全獨立，不入侵業務叢集。可以在業務叢集中使用任何來自社群的 Kubernetes 外掛運維和管理應用，由 KubeVela 負責在控制平面管理和操作這些外掛。第二，不使用 KubeFed 等會生成大量聯邦物件的技術，而是直接向多叢集進行交付，保持和單叢集管理一致的體驗。通過整合 OCM/Karmada 等多容器叢集管理方案支援 Push 和 Pull 模式。在中央管控、異構網路等場景下，KubeVela 可以實現安全叢集治理、環境差異化配置、多叢集灰度釋出等能力。
以阿里雲內部邊緣計算產品的方案為例，開發人員只需將編寫的映象和 KubeVela 的檔案直接釋出到 KubeVela 控制平面，控制平面會將應用元件分發到中心託管叢集或邊緣叢集。邊緣叢集可以採用 OpenYurt 等邊緣叢集管理方案。因為 KubeVela 是多叢集統一的控制平面，所以它可以實現應用元件的統一編排、雲-邊叢集差異配置，以及匯聚所有底層的監控資訊，實現統一可觀測和繪製跨叢集資源拓撲等目的。
總結
總的來說，上述 4 個 KubeVela 核心設計原則可以簡單囊括為：1．基於 OAM 抽象基礎設施底層細節，使用者只需要關心 4 個交付模型。
2．圍繞工作流的宣告式交付，工作流無需額外啟動程式或容器，交付流程標準化。
3．高度可擴充套件、易程式設計：將運維邏輯用 CUE 語言程式碼化，比模板語言更靈活，比寫 Controller 簡單一個量級。
4．面向混合環境的設計，提供環境和叢集等圍繞應用的概念抽象，統一管控所有應用依賴的資源 (包含雲服務等)。
目前，KubeVela 已經成為阿里雲原生基礎設施一部分。從圖 5 可見，我們在 Kubernetes 之上做了很多擴充套件，包括資源池、節點、叢集管理能力，對工作負載和自動化運維能力也做了很多支援。KubeVela 在這些能力之上做了一層統一的應用交付和管理層，以便集團業務能夠適用不同場景。
未來雲原生將如何演進呢？回顧近十年的雲原生髮展，一個不可逆轉的趨勢是標準化介面不斷上移。 為什麼？從 2010 年左右雲端計算嶄露頭角到如今站穩腳跟，雲的算力得到普及；2015 年前後容器大範圍鋪開，帶來了交付介質的標準化；2018 年左右，Kubernetes 通過對叢集排程和運維抽象，實現了基礎設施管理的標準化；近兩年 Prometheus 和 OpenTelemetry 逐漸讓監控走向統一，Envoy/Istio 等 Service Mesh 技術在讓流量管理更加通用。從這些雲原生髮展歷程中，我們看到了雲原生領域技術碎片化和應用交付複雜性的問題，提出開放應用模型 OAM 並開源 KubeVela 試圖解決這個問題。我們相信，應用層標準化將是雲原生時代的趨勢。
點選此處，檢視 KubeVela 專案官網！！
您可以通過如下材料瞭解更多關於 KubeVela 以及 OAM 專案的細節：
專案程式碼庫： github.com/oam-dev/kubevela 歡迎 Star/Watch/Fork！
專案官方主頁與文件： kubevela.io從 1.1 版本開始，已提供中文、英文文件，更多語言文件歡迎開發者進行翻譯。
專案釘釘群： 23310022；Slack：CNCF #kubevela Channel
加入微信群： 請先新增以下 maintainer 微訊號，表明進入KubeVela使用者群：
作者介紹：
司徒放，花名“姬風”｜阿里雲資深技術專家，阿里雲應用 PaaS 及 Serverless 產品線負責人。2010 年加入阿里巴巴後一直深度參與服務化和雲原生架構的多次跨代演進，如鏈路跟蹤、容器虛擬化、全鏈路壓測、異地多活、中介軟體雲產品化、雲原生上雲等。負責並主導了阿里巴巴在微服務、可觀測性、Serverless 等領域的開源技術和商業化產品建設，致力於通過雲原生技術，為外部企業提供成熟穩定的網際網路架構解決方案和產品。參與或主導設計的開源專案包括 KubeVela、Spring Cloud Alibaba、Apache Dubbo、Nacos 等。