作者：司徒放
審核&校對：田瑋靖、溪洋
編輯&排版：雯燕

導語： 云原生時代，直接使用 Kubernetes 和云基礎設施過于復雜，如用戶需要學習很多底層細節、應用管理的上手成本高、容易出錯、故障頻頻。隨著云計算的普及，不同云又有不同的細節，進一步加劇了上述問題。

本文將介紹如何在 Kubernetes 上構建新的應用管理平臺，提供一層抽象以封裝底層邏輯，只呈現用戶關心的接口，使用戶可以只關注自己的業務邏輯，管理應用更快更安全。

云原生時代是一個非常好的時代，我們所面臨的是整體技術的顛覆性革新，全面地對應用做端到端重構。目前，云原生在演進過程中產生了三個關鍵技術：

• 一是容器化，容器作為標準化交互的介質，在運維效率、部署密度和資源隔離性方面相比傳統方式有很大改進，據 CNCF 最新調研報告顯示，目前已有 92% 的企業生產系統在使用容器；

• 二是 Kubernetes，它對基礎設施進行了抽象和管理，現已成為云原生的標配；

• 三是 Operator 自動化運維，通過控制器和定制資源的機制，使 Kubernetes 不僅可以運維無狀態應用，還可以執行由用戶定義的運維能力，實現更復雜的自動化運維應用進行自動化部署和交互。

這三項關鍵技術其實是逐漸演進的關系，另外，在應用交付領域，也有與之對應的理論在跟隨上述技術不斷地演進。云原生的崛起，帶來了交付介質、基礎設施管理、運維模型和持續交付理論的全面升級和突破，加速了云計算時代的到來。

圖 1 云原生技術全景圖（??詳情可點擊此處查看??）

從 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 用開放應用模型描述的一個應用交付示例

如圖 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．面向混合環境的設計，提供環境和集群等圍繞應用的概念抽象，統一管控所有應用依賴的資源 (包含云服務等)。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-Krs9vgWO-1637639705798)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/72732d2eb9834edbb2a95c0c0d9f5318~tplv-k3u1fbpfcp-zoom-1.image “5.png”)]

圖 5 KubeVela 在阿里云原生基礎設施的位置

目前，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 等。 ?

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的Kubernetes 已经成为云原生时代的安卓，这就够了吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

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