以一致的體驗交付和管理雲原生多集群應用

2022 年 1 月 6 日
筆記
KubeMeet, Kubernetes, KubeVela, OCM, 雲原生, 阿里雲

作者：馮泳，孫健波

大家好，很高興能在 KubeCon 中國峰會給大家做分享，今天的主題是「以一致的體驗構建和管理多集群應用」，主角是 KubeVela 和 OCM，這兩個都是 CNCF 的開源項目。整個演講大致分為三部分，首先介紹雲原生應用交付和管理的挑戰，然後介紹這背後的 KubeVela 和 OCM 技術原理，最後是整體的最佳實踐，以及一個完整的 Demo。

背景

隨著雲原生生態的繁榮，Kubernetes 逐漸成為了基礎設施的標準集成介面，越來越多的基礎設施能力變成了開箱即用的聲明式 API，CRD Operator [1 ] 的普及也讓運維能力也逐漸趨向於聲明式和自動化。如圖 1 所示，從底層基礎設施到上層應用開發，如今的 CNCF 生態 [2 ] 中有上千個項目。

圖 1. CNCF landscape 生態 – 摘自 2021.12

然而眾多的選擇是禮物，也是研發工程師的煩惱。不同的應用架構涉及到的不同開發語言、技術框架、打包方式、製品形態、雲資源、以及運維方式各不相同。軟體生命周期中，開發、測試、預發灰度、生產部署對應的環境和應用交付部署體驗也存在很大的不一致。研發人員切換到雲原生技術棧就涉及大量複雜的新知識需要學習，這就好比對著大量作業系統底層的 API 寫程式，缺乏了編程框架和標準庫，讓應用開發事倍功半。

如何用好雲原生繁榮的技術生態，又能讓業務的研發人員獲得一致的低門檻體驗，同時安全可靠的交付應用，是業介面臨的巨大挑戰。

業界的典型做法與挑戰

為了解決應用交付的這最後一公里問題，業界的典型做法主要分為兩大類。

第一類是在針對自身的業務場景基於 Kubernetes 構建內部的 PaaS 平台，隱藏 Kubernetes 平台介面，提供自身平台 API。這種模式通常在規模較大的公司，需要有對 Kubernetes 和業務都比較精通的團隊支撐。但是隨著時間的推移，業務場景變得複雜、需求逐漸增加，內部自建的 PaaS 都會面臨擴展能力不足、難以維護，最後不得不推翻重做的困境，這個問題在阿里早期的應用雲原生化改造的實踐過程中尤為明顯。另一方面，規模較大的公司通常會有不同的業務團隊，由於頂層設計不足，不同團隊各自構建的 PaaS 平台很容易成為互相獨立的煙囪，大量相似的能力只能重複建設、無法復用，更無法統一管理。每個不同場景的不同平台又給更上層的業務團隊帶來了新的概念和學習負擔。

針對第一類場景存在的問題，業界逐漸傾向於容器平台層原汁原味透出 K8s 原生 API，負責提供穩定的雲原生生態能力，同時不影響靈活性和擴展性。應用交付通過類似 Jenkins/Gitlab 這樣的 Pipeline ，將應用製品打包（如 Helm Chart 等），然後直接部署到容器平台中，這就延伸出第二類做法。基於傳統 CI 生態工具直接對接容器平台的模式，如圖 2 所示，這類做法的核心是通過腳本、配置等方式構建抽象體系來簡化使用門檻。這個方式目前是業內較為流行的解決方案，其好處分工較為明確，容器平台層作為 Infra/SRE 團隊維護基礎設施能力，應用交付則充分利用企業內現有的 CI 體系，不需要建設平台。

圖 2. 業界典型的解決方案

這種方式一定程度上解決了應用管理的問題，對於中小規模的企業即使對容器平台缺乏維護能力，也可以通過購買雲服務的方式解決，同時也能為業務開發者提供一站式的一致體驗。但主要問題就出現在前面應用交付這一環，無論是哪種規模和場景的企業，都會很快遇到這些挑戰：

缺乏自動化，需要大量手工維護工作。 比如由於突發的網路原因、或者由於 Pipeline 系統自身的某個問題，就會中斷所有的發布並且需要人工介入，缺乏自愈能力。
缺乏統一的應用模型。 無論是作為應用的完整交付物，還是作為應用的核心入口（single source of truth），應用模型的統一都是極其重要的。缺乏統一的模型描述作為應用交付入口，就會導致不同的人可以從多處對系統進行變更，例如通過 CI Pipeline 系統、或者直接更改 Kubernetes，時間久了系統的配置會出現很大的不一致，從而引發故障。
存在安全風險。 基於 CI pipeline 系統構建的應用交付，CI/CD 體系的安全域通常不具備隔離性，即 CI/CD 通過一套系統完成，基礎設施所有集群的秘鑰全都在同一套系統中存儲，一旦被黑客突破容易引發非常大的系統安全風險。如程式碼覆蓋率統計工具 Codecov 在今年 4 月份就遭遇了一起安全事故 [3 ] ，所有使用該產品的項目配置的 CI 秘鑰全部泄露。另一方面，越來越多的開源軟體被採納到企業的生產系統，這些軟體的集成也加劇了安全隱患。
維護成本高。 通過腳本和模板簡化開發者心智是這種模式的核心，但是腳本和模板本身的維護如果缺乏開源標準和生態，很快就會缺乏活力，久而久之就變成了再也無人敢碰的神秘程式碼，極度依賴這套體系最初的構建者經驗，難以延續和迭代。

所以如何構建穩定可靠的應用交付和管理體系，成為了我們亟需探索的關鍵。

如何構建穩定可靠的應用交付和管理體系？

如何保證應用交付的穩定、可靠和安全，我們分別來看解決問題的方法。首先，為了解決大規模應用交付的穩定性和可靠性問題，我們從 Kubernetes 的設計中得到了啟示。

Kubernetes 帶來的啟示

Kubernetes 有兩個核心理念，一個是聲明式 API，一個是面向終態的控制循環。

聲明式是用戶側抽象的最佳表達方式，它可以大大簡化用戶的心智，從描述過程到描述結果。聲明式為什麼可以簡化心智，舉一個吃飯的例子大家就容易理解了，傳統基於過程式的描述就好比你自己在家裡吃飯，你要購買食材、研究菜譜，一直到做出來吃到，最後還要洗碗，整個過程是非常複雜的。而聲明式的描述就是你去餐廳里吃飯，點菜的時候告訴服務員你想吃的菜是什麼，最終餐廳會把你要點的菜端上來給你。

圖 3. Kubernetes 的控制循環

另一方面，面向終態的控制循環也是保證可靠性的最佳方式，這個設計原則要求我們的系統具備以下特性：

自動化，即能夠始終面向最終的狀態去運行，如果沒達到狀態，就繼續運行。自動化的特性也保證了我們的系統不會因為一點點不穩定就中斷，具備很強的自愈能力。
收斂性，即在系統運行過程中結果可以向終態靠攏，每次執行都能不斷逼近最終結果。
冪等性，表示我們多次執行同樣的流程要保證結果是一致的，不會因為執行了多次就出現意外的問題。
確定性，表示系統只要運行是正常的，最終能夠不斷執行，直到達成一個確定的結果。

這四大特性也是大規模應用交付的核心要素。

應用交付安全性的原則

然後我們來看看安全性的問題，其實核心很簡單，就是像對待生產環境一樣對待應用交付系統的安全性。CNCF 基金會在 2021 年 4 月份也發布了應用交付最佳實踐 [4 ] 和白皮書 [5] ，其中就提到了應用交付的一些安全性原則。

交付環境隔離，一方面指不同的交付目的地應該是隔離的，交付系統不應該可以直接訪問所有的 Kubernetes 集群，同時不同的環境之間也應該是隔離的。另一方面，針對 CI/CD 不同應用生命周期的階段，安全域也應該是隔離的，使用獨立的秘鑰資訊。
集成物檢查，這個原則指我們在交付過程中，要對集成的開源工具，使用的依賴包，以及應用本身的鏡像做必要的安全檢查。
最小許可權，這個原則大家都比較容易理解，具體到實踐中就是要做許可權的拆分。比如使用 token 而非永久秘鑰，加入必要的審批流程，使用秘鑰管理工具。尤其是雲資源的使用，要對秘鑰做必要的許可權拆分，如使用子帳號等機制，避免一個秘鑰泄露又不能及時回收導致出現單點故障。
審計和安全監控，這個原則要求我們的應用交付和管理系統本身也要具備很好的可觀測性能力，具備交付行為的審計和整體的安全監控。

面向終態的應用交付體系核心要素

所以總結下來，一個穩定、可靠、安全的應用交付系統，需要具備的核心要素如下圖 4 所示。

圖 4. 應用交付體系的核心要素

這個體系的入口是一個完整的應用模型，涵蓋不同的交付物、雲資源、以及各類環境編排的配置，它是應用交付的統一入口，也是唯一的依據。

與此同時，這個應用模型採用聲明式的方式面向業務用戶，為業務層提供針對使用場景的抽象能力，能夠降低用戶的使用門檻，降低底層的 API 的複雜性，同時具備靈活擴展的能力。交付系統通過拉取的方式與聲明式 API 交互，用戶只需要在模型層描述終態，最終交付系統就會朝著這個終態不斷收斂。

在交付系統內部，要具備編排和部署兩大核心功能。同時這兩大核心功能的背後要始終維持一個面向終態持續運行的控制循環，這個控制循環是自動化和確定性的基石，同時也要具備對交付物、交付流程安全監測和審計的能力。

其中，編排解決的是不同交付物直接的依賴關係、部署順序、數據傳遞以及多集群多環境配置的問題，然而編排的複雜性不應該暴露給用戶。交付系統的編排執行引擎應該能夠根據用戶描述的聲明式終態自動化的完成編排，而不是讓用戶手動編寫編排的過程。部署則解決的是不同交付的部署，如雲資源、Kubernetes 資源，以及多集群的交付問題，需要能夠提供充分的可擴展性，保證不同的交付物均可以部署，同時能夠在多集群環境隔離的安全條件下完成部署。

下一代雲原生應用交付與管理

KubeVela 就是完全遵循這套理念構建的現代化的應用交付平台，它可以讓你的應用交付與管理在當今流行的混合、多雲環境中變得更加簡單、輕鬆、可靠。 演進至今已有上百位貢獻者參與程式碼貢獻，吸納了來自阿里、螞蟻、騰訊、位元組、第四範式、Gitlab等一系列不同領域公司的工程實踐，充分利用雲原生領域百花齊放的技術生態紅利實現應用的交付與管理。

圖 5. KubeVela 架構

標準、開放的應用模型（OAM）

KubeVela 背後有一個完整的應用模型，那就是 OAM（Open Application Model）。OAM 是阿里和微軟在 2019 年聯合發布的應用模型，如今已經被阿里、微軟、Oracle、Salesforce、騰訊等眾多雲廠商實踐到雲產品中，同時也被國家信通院立項作為《雲計算開放應用架構》行業標準發布。

圖 6. OAM 應用模型

如圖 6 所示，OAM 模型將複雜的應用交付和管理抽象成應用、組件、運維能力，以及工作流這四個核心概念，使得用戶可以通過一份配置文件，描述應用交付和管理的全部內容。OAM 具備充分的可擴展性，滿足應用交付到不同雲、不同環境的訴求。同時 OAM 也不綁定 Kubernetes 生態，若開箱即用的 KubeVela 不滿足需求，OAM 社區也歡迎用戶參與到模型層的建設中，根據模型獨立實現。

基於 Kubernetes 的應用交付控制平面

KubeVela 是一個微內核的架構，其核心是一個基於 Kubernetes 的應用交付和管理控制平面，具備自愈、冪等、收斂以及確定這四大特性。最小化部署的 KubeVela 只需要 0.5 核以及 200M 記憶體即可支援上百個應用的交付。同時 KubeVela 自身也具備一系列開箱即用的插件，支援包括多集群交付、雲資源管理、GitOps、Helm chart、可觀測性等一系列功能，甚至包括 KubeVela 自身的 UI 控制台也是通過插件的方式集成的。

KubeVela 也不僅局限於 Kubernetes 生態，官方內置的雲資源插件就可以集成任意的 terraform 模組，交付不同的雲資源，甚至虛擬機。同時得益於 OAM 模型以及 KubeVela 從設計之初就嚴格遵循的可擴展性原則，用戶可以輕易的增加和擴展生態的能力。

安全、可靠的多集群管理技術（OCM）

KubeVela 背後的多集群技術也是保證應用穩定、安全、大規模交付的核心。我們知道，因為地域，規模，容災等方面的考慮，多集群早已成為企業內部基礎設施的普遍形態。然而，Kubernetes 原生的管理能力目前仍然停留在單集群級別。每一個集群可以穩定地自治運行，但是卻缺乏橫貫多個集群的統籌管理能力。為了形成一個穩定、統一的應用交付和管理平台，需要具備如下能力：

運維管理人員能夠獲知多集群水位的變化，節點健康狀態等資訊
業務負責人能夠決策如何調配應用服務在各個集群中的部署分布
應用運維人員能夠獲知服務狀態，下發騰挪的策略

得益於 RedHat 和螞蟻、阿里雲共同發起並開源的 OCM（Open Cluster Management）多集群技術，KubeVela 可以輕鬆解決多集群、混合環境下資源、應用、配置、策略等對象的生命周期管理問題。OCM 使得用戶在多集群和混合環境下也能像在單個 Kubernetes 集群平台上一樣，使用自己熟悉的開源項目和產品輕鬆交付和管理應用。

圖 7. OCM 的技術特點

與目前已有的多集群技術相比，OCM 的架構在以下方面具有技術領先優勢，滿足用戶對雲原生應用交付安全、穩定、大規模能力的核心訴求：

模組化： OCM 管理平台由管理原語，基礎組件和眾多可擴展組件構成，這些組件可以像樂高積木一樣自由組合構建滿足用戶需求的功能集合。這一理念與 KubeVela 也天然契合，共同為用戶提供了充分的生態可擴展性。
大規模： OCM的基礎架構繼承了 Kubernetes 開放，可擴展的特點。正如單一 Kubernetes 集群可以支援數千個節點一樣，OCM 在設計上可以支援數千個被管理集群。
安全： OCM 在設計上以零信任和最小許可權為基礎，管理組件和被管理上的 agent 之間的註冊通訊採用兩次握手的方式。此外證書的更新，訪問許可權的管理，許可權 token 的分發也採用和 Kubernetes 類似的設計，由相應的可擴展組件通過 Kubernetes 原生 API 方式實現。
可擴展性： OCM 提供了可擴展組件的編程框架和管理 API，和基礎組件，管理原語一起，能夠方便的將Kubernetes 生態中的項目遷移到 OCM 多集群管理平台。通過編程框架，OCM 社區已經在多集群環境實現了眾多 Kubernetes 的管理能力，也得益於此，KubeVela 與 OCM 可以輕鬆實現深度集成。

KubeVela 和 OCM 協同下的安全、一致的應用交付體驗

KubeVela 和 OCM 天生具有互補性。KubeVela 負責應用層的交付和生命周期管理，OCM 則管理集群基礎設施資源的生命周期。它們緊密合作在一起提供了應用在多集群環境下交付和生命周期管理的端到端能力。

圖 8. 跨環境、多集群交付的一致體驗

如圖 8 所示，使用 KubeVela 和 OCM，用戶在不同環境的交付過程將完全自動化，節省大量人工操作。

同一個應用，業務研發人員只要描述一次組件，就可以在不同交付環境下綁定不同運維能力獨立運行，比如開發環境可以使用端雲聯調，而預發生產環境可以綁定可觀測性策略等等，無需重複諸如鏡像、埠、環境變數等組件級別的參數，大大節省了心智負擔。
另一方面，在控制平面，不同一個應用的跨環境部署可以在一次交付過程中自動化完成，可以自助選擇多種審批方式或是全自動執行。

更為重要的是，基於 KubeVela 和 OCM，可以構建完全基於訂閱模式的安全 GitOps 多集群應用交付。

圖 9. GitOps 模式下的安全應用交付

如圖 7 所示，CI 的流程還是沿用之前的模式，但是 CD 這一側則描述一個獨立的配置倉庫，首先從 Git 倉庫配置層面，兩個倉庫的許可權是完全隔離的。通過統一的應用模型，用戶可以在配置倉庫完整的描述應用，同時 KubeVela 也可以監聽完整應用描述的變化，從而主動拉取應用配置。這個過程中，Git 倉庫不持有交付系統的任何秘鑰。在交付系統完成編排以後，管控數據則通過 OCM 完成下發，整個過程也是由運行時集群主動拉取的，交付系統沒有中央管控任何子集群的秘鑰。管控數據下發到子集群以後，就可以由子集群的 GitOps agent 主動獲取交付製品的變化，形成新的自治。

我們可以看到，每一個環節都獨立工作、自成體系，每一個環節都根據需要進行授權和審核，安全可靠。KubeVela 和 OCM 的協同可以統一編排和管理混合雲、多集群、以及邊緣應用，最終實現雲邊協同的安全交付。

開啟你的端到端平台化之路

在我們了解了以 KubeVela 和 OCM 為核心的應用交付和管理引擎設計原理以後，我可以看到，這一套模式帶給我們的最大好處是自動化、低門檻以及安全性。那麼如何展開實踐呢？從最新的 KubeVela v1.2 版本開始，我們增強了端到端的完整用戶實踐，你可以通過可視化的方式交付和管理應用。

首先，KubeVela 的架構是完全基於微內核以及高可擴展的模式打造的，它可以幫助用戶以最小的成本，按需構建自己的雲原生解決方案。如下圖 8 所示是 KubeVela 的插件管理頁面，包括 KubeVela 自身的 UI 功能以及 OCM 多集群功能，都是 KubeVela 的插件，在微內核的基礎上，用戶可以任意訂製和切換自己的擴展功能。同時，它也幫助用戶敏捷地獲取更多的雲原生生態能力，幫助企業更好的實現資源管理、 DevOps 、應用治理等場景。實現層面，KubeVela 的插件體系完全基於開源社區的模式共建互助，一切提交到社區插件倉庫 [6] 的內容，就會自動化的被 KubeVela 內核發現，我們相信在不久的將來其即可有眾多的選擇。

圖 10. KubeVela 可視化插件頁面

KubeVela 也默認支援了一系列組件類型，如圖 9 所示，包括基於容器鏡像的應用交付，該模式門檻低、無需了解 Kubernetes 知識，適用於大多數企業用戶；當然也支援 Kubernetes 的 YAML 應用，圍繞 OCM 技術將應用交付到多個集群；另外，用戶通過安裝官方維護的插件，可以獲取到 Helm Chart 包、多種雲廠商的雲資源等組件類型，並獲得對應的完整應用交付和管理能力。你可以充分發揮想像，通過擴展，KubeVela 還能交付哪些類型的應用呢？

圖 11. KubeVela 的組件

KubeVela 端到端的 UI 體系中，也默認添加了環境的概念，支援應用開發和交付生命周期中涉及到的不同環境，例如開發、測試、生產環境等。同一個應用在不同的環境中部署完全隔離，安全可靠，同時又無需用戶重複配置，給用戶帶來了一致的體驗。

圖 12. 同一個環境中定義交付到多個集群

圖 13. 通過可配置的工作流控制交付流程

目前，KubeVela 1.2 已發布預覽版本 1.2.0-beta.3 [7] ，歡迎社區用戶下載體驗。

未來 KubeVela 將更多的提供端到端的完整用戶體驗，豐富更多垂直場景下的能力，朝著開發者能夠自助完成應用交付的方向演進，讓混合環境下的應用交付就像我們今天使用 App Store 一樣簡單。

以一致的體驗交付和管理雲原生多集群應用

背景

業界的典型做法與挑戰