以一致的體驗交付和管理云原生多集群應(yīng)用
背景
Cloud Native
隨著云原生生態(tài)的繁榮，Kubernetes 逐漸成為了基礎(chǔ)設(shè)施的標(biāo)準(zhǔn)集成界面，越來越多的基礎(chǔ)設(shè)施能力變成了開箱即用的聲明式 API，CRD Operator[1] 的普及也讓運維能力也逐漸趨向于聲明式和自動化。如圖 1 所示，從底層基礎(chǔ)設(shè)施到上層應(yīng)用開發(fā)，如今的 CNCF 生態(tài)[2]中有上千個項目。
圖 1. CNCF landscape 生態(tài) - 摘自 2021.12
然而眾多的選擇是禮物，也是研發(fā)工程師的煩惱。不同的應(yīng)用架構(gòu)涉及到的不同開發(fā)語言、技術(shù)框架、打包方式、制品形態(tài)、云資源、以及運維方式各不相同。軟件生命周期中，開發(fā)、測試、預(yù)發(fā)灰度、生產(chǎn)部署對應(yīng)的環(huán)境和應(yīng)用交付部署體驗也存在很大的不一致。研發(fā)人員切換到云原生技術(shù)棧就涉及大量復(fù)雜的新知識需要學(xué)習(xí)，這就好比對著大量操作系統(tǒng)底層的 API 寫程序，缺乏了編程框架和標(biāo)準(zhǔn)庫，讓應(yīng)用開發(fā)事倍功半。
業(yè)界的典型做法與挑戰(zhàn)
Cloud Native
為了解決應(yīng)用交付的這最后一公里問題，業(yè)界的典型做法主要分為兩大類。
針對第一類場景存在的問題，業(yè)界逐漸傾向于容器平臺層原汁原味透出 K8s 原生 API，負(fù)責(zé)提供穩(wěn)定的云原生生態(tài)能力，同時不影響靈活性和擴(kuò)展性。應(yīng)用交付通過類似 Jenkins/Gitlab 這樣的 Pipeline ，將應(yīng)用制品打包（如 Helm Chart 等），然后直接部署到容器平臺中，這就延伸出第二類做法。基于傳統(tǒng) CI 生態(tài)工具直接對接容器平臺的模式，如圖 2 所示，這類做法的核心是通過腳本、配置等方式構(gòu)建抽象體系來簡化使用門檻。這個方式目前是業(yè)內(nèi)較為流行的解決方案，其好處分工較為明確，容器平臺層作為 Infra/SRE 團(tuán)隊維護(hù)基礎(chǔ)設(shè)施能力，應(yīng)用交付則充分利用企業(yè)內(nèi)現(xiàn)有的 CI 體系，不需要建設(shè)平臺。
圖 2. 業(yè)界典型的解決方案
這種方式一定程度上解決了應(yīng)用管理的問題，對于中小規(guī)模的企業(yè)即使對容器平臺缺乏維護(hù)能力，也可以通過購買云服務(wù)的方式解決，同時也能為業(yè)務(wù)開發(fā)者提供一站式的一致體驗。但主要問題就出現(xiàn)在前面應(yīng)用交付這一環(huán)，無論是哪種規(guī)模和場景的企業(yè)，都會很快遇到這些挑戰(zhàn)：
-
缺乏自動化，需要大量手工維護(hù)工作。比如由于突發(fā)的網(wǎng)絡(luò)原因、或者由于 Pipeline 系統(tǒng)自身的某個問題，就會中斷所有的發(fā)布并且需要人工介入，缺乏自愈能力。
-
缺乏統(tǒng)一的應(yīng)用模型。無論是作為應(yīng)用的完整交付物，還是作為應(yīng)用的核心入口（single source of truth），應(yīng)用模型的統(tǒng)一都是極其重要的。缺乏統(tǒng)一的模型描述作為應(yīng)用交付入口，就會導(dǎo)致不同的人可以從多處對系統(tǒng)進(jìn)行變更，例如通過 CI Pipeline 系統(tǒng)、或者直接更改 Kubernetes，時間久了系統(tǒng)的配置會出現(xiàn)很大的不一致，從而引發(fā)故障。
-
存在安全風(fēng)險。基于 CI pipeline 系統(tǒng)構(gòu)建的應(yīng)用交付，CI/CD 體系的安全域通常不具備隔離性，即 CI/CD 通過一套系統(tǒng)完成，基礎(chǔ)設(shè)施所有集群的秘鑰全都在同一套系統(tǒng)中存儲，一旦被黑客突破容易引發(fā)非常大的系統(tǒng)安全風(fēng)險。如代碼覆蓋率統(tǒng)計工具 Codecov 在今年 4 月份就遭遇了一起安全事故[3]，所有使用該產(chǎn)品的項目配置的 CI 秘鑰全部泄露。另一方面，越來越多的開源軟件被采納到企業(yè)的生產(chǎn)系統(tǒng)，這些軟件的集成也加劇了安全隱患。
-
維護(hù)成本高。通過腳本和模板簡化開發(fā)者心智是這種模式的核心，但是腳本和模板本身的維護(hù)如果缺乏開源標(biāo)準(zhǔn)和生態(tài)，很快就會缺乏活力，久而久之就變成了再也無人敢碰的神秘代碼，極度依賴這套體系最初的構(gòu)建者經(jīng)驗，難以延續(xù)和迭代。
所以如何構(gòu)建穩(wěn)定可靠的應(yīng)用交付和管理體系，成為了我們亟需探索的關(guān)鍵。
如何構(gòu)建穩(wěn)定可靠的
應(yīng)用交付和管理體系？
Cloud Native
如何保證應(yīng)用交付的穩(wěn)定、可靠和安全，我們分別來看解決問題的方法。首先，為了解決大規(guī)模應(yīng)用交付的穩(wěn)定性和可靠性問題，我們從 Kubernetes 的設(shè)計中得到了啟示。
Kubernetes 有兩個核心理念，一個是聲明式 API，一個是面向終態(tài)的控制循環(huán)。
聲明式是用戶側(cè)抽象的最佳表達(dá)方式，它可以大大簡化用戶的心智，從描述過程到描述結(jié)果。聲明式為什么可以簡化心智，舉一個吃飯的例子大家就容易理解了，傳統(tǒng)基于過程式的描述就好比你自己在家里吃飯，你要購買食材、研究菜譜，一直到做出來吃到，最后還要洗碗，整個過程是非常復(fù)雜的。而聲明式的描述就是你去餐廳里吃飯，點菜的時候告訴服務(wù)員你想吃的菜是什么，最終餐廳會把你要點的菜端上來給你
圖 3. Kubernetes 的控制循環(huán)
另一方面，面向終態(tài)的控制循環(huán)也是保證可靠性的最佳方式，這個設(shè)計原則要求我們的系統(tǒng)具備以下特性：
- 自動化，即能夠始終面向最終的狀態(tài)去運行，如果沒達(dá)到狀態(tài)，就繼續(xù)運行。自動化的特性也保證了我們的系統(tǒng)不會因為一點點不穩(wěn)定就中斷，具備很強(qiáng)的自愈能力。
- 收斂性，即在系統(tǒng)運行過程中結(jié)果可以向終態(tài)靠攏，每次執(zhí)行都能不斷逼近最終結(jié)果。
- 冪等性，表示我們多次執(zhí)行同樣的流程要保證結(jié)果是一致的，不會因為執(zhí)行了多次就出現(xiàn)意外的問題。
- 確定性，表示系統(tǒng)只要運行是正常的，最終能夠不斷執(zhí)行，直到達(dá)成一個確定的結(jié)果。
2 應(yīng)用交付安全性的原則
然后我們來看看安全性的問題，其實核心很簡單，就是像對待生產(chǎn)環(huán)境一樣對待應(yīng)用交付系統(tǒng)的安全性。CNCF 基金會在 2021 年 4 月份也發(fā)布了應(yīng)用交付最佳實踐[4]和白皮書[5]，其中就提到了應(yīng)用交付的一些安全性原則。
- 交付環(huán)境隔離，一方面指不同的交付目的地應(yīng)該是隔離的，交付系統(tǒng)不應(yīng)該可以直接訪問所有的 Kubernetes 集群，同時不同的環(huán)境之間也應(yīng)該是隔離的。另一方面，針對 CI/CD 不同應(yīng)用生命周期的階段，安全域也應(yīng)該是隔離的，使用獨立的秘鑰信息。
- 集成物檢查，這個原則指我們在交付過程中，要對集成的開源工具，使用的依賴包，以及應(yīng)用本身的鏡像做必要的安全檢查。
- 最小權(quán)限，這個原則大家都比較容易理解，具體到實踐中就是要做權(quán)限的拆分。比如使用 token 而非永久秘鑰，加入必要的審批流程，使用秘鑰管理工具。尤其是云資源的使用，要對秘鑰做必要的權(quán)限拆分，如使用子賬號等機(jī)制，避免一個秘鑰泄露又不能及時回收導(dǎo)致出現(xiàn)單點故障。
- 審計和安全監(jiān)控，這個原則要求我們的應(yīng)用交付和管理系統(tǒng)本身也要具備很好的可觀測性能力，具備交付行為的審計和整體的安全監(jiān)控。
3 面向終態(tài)的應(yīng)用交付體系核心要素
所以總結(jié)下來，一個穩(wěn)定、可靠、安全的應(yīng)用交付系統(tǒng)，需要具備的核心要素如下圖 4 所示。
這個體系的入口是一個完整的應(yīng)用模型，涵蓋不同的交付物、云資源、以及各類環(huán)境編排的配置，它是應(yīng)用交付的統(tǒng)一入口，也是唯一的依據(jù)。
04
下一代云原生應(yīng)用交付與管理
Cloud Native
KubeVela 就是完全遵循這套理念構(gòu)建的現(xiàn)代化的應(yīng)用交付平臺，它可以讓你的應(yīng)用交付與管理在當(dāng)今流行的混合、多云環(huán)境中變得更加簡單、輕松、可靠。演進(jìn)至今已有上百位貢獻(xiàn)者參與代碼貢獻(xiàn)，吸納了來自阿里、螞蟻、騰訊、字節(jié)、第四范式、Gitlab等一系列不同領(lǐng)域公司的工程實踐，充分利用云原生領(lǐng)域百花齊放的技術(shù)生態(tài)紅利實現(xiàn)應(yīng)用的交付與管理。
圖 5. KubeVela 架構(gòu)
KubeVela 背后有一個完整的應(yīng)用模型，那就是 OAM（Open Application Model）。OAM 是阿里和微軟在 2019 年聯(lián)合發(fā)布的應(yīng)用模型，如今已經(jīng)被阿里、微軟、Oracle、Salesforce、騰訊等眾多云廠商實踐到云產(chǎn)品中，同時也被國家信通院立項作為《云計算開放應(yīng)用架構(gòu)》行業(yè)標(biāo)準(zhǔn)發(fā)布。
圖 6. OAM 應(yīng)用模型
如圖 6 所示，OAM 模型將復(fù)雜的應(yīng)用交付和管理抽象成應(yīng)用、組件、運維能力，以及工作流這四個核心概念，使得用戶可以通過一份配置文件，描述應(yīng)用交付和管理的全部內(nèi)容。OAM 具備充分的可擴(kuò)展性，滿足應(yīng)用交付到不同云、不同環(huán)境的訴求。同時 OAM 也不綁定 Kubernetes 生態(tài)，若開箱即用的 KubeVela 不滿足需求，OAM 社區(qū)也歡迎用戶參與到模型層的建設(shè)中，根據(jù)模型獨立實現(xiàn)。
KubeVela 是一個微內(nèi)核的架構(gòu)，其核心是一個基于 Kubernetes 的應(yīng)用交付和管理控制平面，具備自愈、冪等、收斂以及確定這四大特性。最小化部署的 KubeVela 只需要 0.5 核以及 200M 內(nèi)存即可支持上百個應(yīng)用的交付。同時 KubeVela 自身也具備一系列開箱即用的插件，支持包括多集群交付、云資源管理、GitOps、Helm chart、可觀測性等一系列功能，甚至包括 KubeVela 自身的 UI 控制臺也是通過插件的方式集成的。
KubeVela 也不僅局限于 Kubernetes 生態(tài)，官方內(nèi)置的云資源插件就可以集成任意的 terraform 模塊，交付不同的云資源，甚至虛擬機(jī)。同時得益于 OAM 模型以及 KubeVela 從設(shè)計之初就嚴(yán)格遵循的可擴(kuò)展性原則，用戶可以輕易的增加和擴(kuò)展生態(tài)的能力。
KubeVela 背后的多集群技術(shù)也是保證應(yīng)用穩(wěn)定、安全、大規(guī)模交付的核心。我們知道，因為地域，規(guī)模，容災(zāi)等方面的考慮，多集群早已成為企業(yè)內(nèi)部基礎(chǔ)設(shè)施的普遍形態(tài)。然而，Kubernetes 原生的管理能力目前仍然停留在單集群級別。每一個集群可以穩(wěn)定地自治運行，但是卻缺乏橫貫多個集群的統(tǒng)籌管理能力。為了形成一個穩(wěn)定、統(tǒng)一的應(yīng)用交付和管理平臺，需要具備如下能力：
- 運維管理人員能夠獲知多集群水位的變化，節(jié)點健康狀態(tài)等信息
- 業(yè)務(wù)負(fù)責(zé)人能夠決策如何調(diào)配應(yīng)用服務(wù)在各個集群中的部署分布
- 應(yīng)用運維人員能夠獲知服務(wù)狀態(tài)，下發(fā)騰挪的策略
得益于 RedHat 和螞蟻、阿里云共同發(fā)起并開源的 OCM（Open Cluster Management）多集群技術(shù)，KubeVela 可以輕松解決多集群、混合環(huán)境下資源、應(yīng)用、配置、策略等對象的生命周期管理問題。OCM 使得用戶在多集群和混合環(huán)境下也能像在單個 Kubernetes 集群平臺上一樣，使用自己熟悉的開源項目和產(chǎn)品輕松交付和管理應(yīng)用。
圖 7. OCM 的技術(shù)特點
與目前已有的多集群技術(shù)相比，OCM 的架構(gòu)在以下方面具有技術(shù)領(lǐng)先優(yōu)勢，滿足用戶對云原生應(yīng)用交付安全、穩(wěn)定、大規(guī)模能力的核心訴求：
- 模塊化：OCM 管理平臺由管理原語，基礎(chǔ)組件和眾多可擴(kuò)展組件構(gòu)成，這些組件可以像樂高積木一樣自由組合構(gòu)建滿足用戶需求的功能集合。這一理念與 KubeVela 也天然契合，共同為用戶提供了充分的生態(tài)可擴(kuò)展性。
- 大規(guī)模：OCM的基礎(chǔ)架構(gòu)繼承了 Kubernetes 開放，可擴(kuò)展的特點。正如單一 Kubernetes 集群可以支持?jǐn)?shù)千個節(jié)點一樣，OCM 在設(shè)計上可以支持?jǐn)?shù)千個被管理集群。
- 安全：OCM 在設(shè)計上以零信任和最小權(quán)限為基礎(chǔ)，管理組件和被管理上的 agent 之間的注冊通信采用兩次握手的方式。此外證書的更新，訪問權(quán)限的管理，權(quán)限 token 的分發(fā)也采用和 Kubernetes 類似的設(shè)計，由相應(yīng)的可擴(kuò)展組件通過 Kubernetes 原生 API 方式實現(xiàn)。
- 可擴(kuò)展性：OCM 提供了可擴(kuò)展組件的編程框架和管理 API，和基礎(chǔ)組件，管理原語一起，能夠方便的將Kubernetes 生態(tài)中的項目遷移到 OCM 多集群管理平臺。通過編程框架，OCM 社區(qū)已經(jīng)在多集群環(huán)境實現(xiàn)了眾多 Kubernetes 的管理能力，也得益于此，KubeVela 與 OCM 可以輕松實現(xiàn)深度集成。
KubeVela 和 OCM 協(xié)同下的安全、一致的應(yīng)用交付體驗
Cloud Native
KubeVela 和 OCM 天生具有互補(bǔ)性。KubeVela 負(fù)責(zé)應(yīng)用層的交付和生命周期管理，OCM 則管理集群基礎(chǔ)設(shè)施資源的生命周期。它們緊密合作在一起提供了應(yīng)用在多集群環(huán)境下交付和生命周期管理的端到端能力。
圖 8. 跨環(huán)境、多集群交付的一致體驗
如圖 8 所示，使用 KubeVela 和 OCM，用戶在不同環(huán)境的交付過程將完全自動化，節(jié)省大量人工操作。
- 同一個應(yīng)用，業(yè)務(wù)研發(fā)人員只要描述一次組件，就可以在不同交付環(huán)境下綁定不同運維能力獨立運行，比如開發(fā)環(huán)境可以使用端云聯(lián)調(diào)，而預(yù)發(fā)生產(chǎn)環(huán)境可以綁定可觀測性策略等等，無需重復(fù)諸如鏡像、端口、環(huán)境變量等組件級別的參數(shù)，大大節(jié)省了心智負(fù)擔(dān)。
- 另一方面，在控制平面，不同一個應(yīng)用的跨環(huán)境部署可以在一次交付過程中自動化完成，可以自助選擇多種審批方式或是全自動執(zhí)行。
更為重要的是，基于 KubeVela 和 OCM，可以構(gòu)建完全基于訂閱模式的安全 GitOps 多集群應(yīng)用交付。
圖 7. GitOps 模式下的安全應(yīng)用交付
開啟你的端到端平臺化之路
Cloud Native
在我們了解了以 KubeVela 和 OCM 為核心的應(yīng)用交付和管理引擎設(shè)計原理以后，我可以看到，這一套模式帶給我們的最大好處是自動化、低門檻以及安全性。那么如何展開實踐呢？從最新的 KubeVela v1.2 版本開始，我們增強(qiáng)了端到端的完整用戶實踐，你可以通過可視化的方式交付和管理應(yīng)用。
首先，KubeVela 的架構(gòu)是完全基于微內(nèi)核以及高可擴(kuò)展的模式打造的，它可以幫助用戶以最小的成本，按需構(gòu)建自己的云原生解決方案。如下圖 8 所示是 KubeVela 的插件管理頁面，包括 KubeVela 自身的 UI 功能以及 OCM 多集群功能，都是 KubeVela 的插件，在微內(nèi)核的基礎(chǔ)上，用戶可以任意定制和切換自己的擴(kuò)展功能。同時，它也幫助用戶敏捷地獲取更多的云原生生態(tài)能力，幫助企業(yè)更好的實現(xiàn)資源管理、 DevOps 、應(yīng)用治理等場景。實現(xiàn)層面，KubeVela 的插件體系完全基于開源社區(qū)的模式共建互助，一切提交到社區(qū)插件倉庫[6]的內(nèi)容，就會自動化的被 KubeVela 內(nèi)核發(fā)現(xiàn)，我們相信在不久的將來其即可有眾多的選擇。
圖 8. KubeVela 可視化插件頁面
圖 9. KubeVela 的組件
圖 11. 通過可配置的工作流控制交付流程