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

阿里巴巴雲原生發表於2022-01-06

作者：馮泳，孫健波

大家好，很高興能在 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 一樣簡單。