華為云 UCS GitOps：輕松交付多集群云原生應用

摘要：使用華為云 UCS GitOps 配置管理來交付您的多云應用，

本文分享自華為云社區《華為云 UCS GitOps：輕松交付多集群云原生應用》，作者：華為云云原生團隊，

隨著業務的全球化發展和應用多元化部署的趨勢，越來越多的客戶選擇通過混合云、多云模式來進行業務部署，選擇多云進行部署可以提高部署業務的基礎設施穩定性，在單個供應商基礎設施出現故障或者訪問流量激增時，可以通過配置跨云彈性來提高業務的高可用性，同時，多云還可以避免企業的技術架構被廠商鎖定，盡管使用多云的優點很多，但管理多云集群和在多云的場景下發布應用卻面臨諸多問題和挑戰，

多云場景下集群管理和應用交付的挑戰

1、多集群基礎設施的管理及一致性發布面臨的挑戰

例如，在多集群場景下的網路策略的配置，TLS證書的發布及更新管理，在現代應用程式的部署步驟中，SSL/TLS證書是很重要的一環，但在部署應用程式時，管理證書的續訂通常是事后才想到的，證書的生命周期從90天到13個月不等，為了保持安全訪問，這些證書需要在到期前更新/重新頒發，

鑒于大多數 Ops 團隊作業繁雜，證書更新有時會被遺漏，這會導致應用間不能正常訪問和作業，在多集群場景下，運維團隊會每個供應商集群重復上述程序進行證書更新；而通過 GitOps 結合 Cert-manager[1]、Nginx Ingress Controller 可以一致的、統一的管理證書的自動化更新 [2]、大大提升 Ops 團隊的運維管理效率 ，

2. 由業務場景側需求和集群基礎設施差異性帶來的差異化配置挑戰

根據應用程式的業務場景訴求不同，不同集群部署的業務版本，更新頻率會存在不同，例如同一餐廳在不同地域的點餐系統可供給的選單種類，選單上新會有差異；或由于跨國公司在不同國家推廣策略不同，新的業務軟體僅需要部署至部分城市所在集群等，

同時，由于業務部署的基礎設施不同，應用程式部署到集群的底層架構、網路連接性、計算存盤性能表現可能多種多樣，例如同一份應用配置在被差異化渲染后可以被交付和托管在云上的CCE、EKS集群、客戶本地資料中心中的集群（存在斷連情況）、邊緣端無人機的集群上（半連接集群）以及太空中衛星鏈所組成的集群（短時連接集群），

因此根據每個集群的性能指標（CPU、Memory）不同，部署業務應用的實體副本數可能會不同；根據每個集群的網路連接情況不同，設定部署業務的版本更新周期，高可用設定（訪問某個服務的超時重試次數等）會產生差異；根據每個集群的使用目的不同（早期生命周期階段的集群通常由開發人員管理，而實際的預發及生產集群的可能由客戶的運維團隊管理），部署業務的版本和資料庫連接池等變數也會存在差異，因此當有M個應用需要交付至N個集群環境中時，差異化配置的復雜度會呈M×N維度爆炸增長，

3. 使用 UI 控制臺方式交付應用與各廠商控制臺風格各異、難以編排大規模微服務交付之間的挑戰

隨著微服務規模變大，依賴UI控制臺進行應用交付的方式變得復雜臃腫，其交付的順序編排依賴人工，無法做到自動化；且無法進行審計和版本控制，

4. 缺乏統一的應用觀測視角的挑戰

在多云集群場景下，當前缺乏統一的視圖幫助客戶查看應用在多集群的部署情況、應用的健康狀態及例外狀態定位，

使用華為云 UCS GitOps 配置管理來交付您的多云應用

為了應對上述多云集群管理和多云應用交付的挑戰，華為云 UCS 推出了基于 GitOps 理念的跨集群配置管理和應用分發的功能，通過它你可以屏蔽底層環境差異和多個管理入口，將多個集群環境的配置和治理集中于一處，以自動化的體驗完成多集群基礎設施的管理以及多云應用的發布及更新，

GitOps 的概念最早由 Weaveworks 公司于2017年提出，指具備版本控制、拉取和合入請求能力、具備CI/CD流水線發布能力的基礎設施即代碼（Infrastructure as Code, IaC），是一種云原生的持續交付模型，如圖1所示，它的核心是使用 Git 倉庫來管理基礎設施和應用的配置，并且以 Git 倉庫作為更改基礎設施和應用的單一事實來源，用戶從其他地方（例如集群控制臺或者命令列）修改的配置均會被修正，Git 倉庫中的宣告式配置描述了目標環境當前所需基礎設施的期望狀態，借助 GitOps 能力，當集群中的實際運行的配置或應用狀態與 Git 倉庫中定義的期望狀態不匹配時，Kubernetes Reconcilers 會根據期望狀態來調整當前的狀態，最終使實際狀態與期望狀態保持一致[3]，

圖1：GitOps Operator 運行方式

基于上述的思想和技術路線，CNCF 開源社區從17年開始至今，涌現出很多火熱的持續交付專案，他們以Flux、ArgoCD等CNCF畢業專案為代表，可以將用戶配置在代碼倉庫中的Kubernetes Manifast（Deployment、Service等Yaml檔案）、Helm Chart、Kustomize、Ksonnet、Jsonnet 定義和組織的應用以自動化的方式部署、將配置變化更改到應用程式的運行時環境，

UCS 的配置管理功能當前采用 Flux2 作為技術內核，并將其與 UCS 的容器艦隊、集群模型進行適配，它通過簡單易用的 UI 提供對華為云集群、多云集群、本地集群、附著集群和伙伴云集群進行跨命名空間、跨集群的應用分發與配置管理的能力，并在觀測面板中對配置的實時狀態的進行收集和展示，用戶還可以將它對接到CI流水線后面，實作多云應用的 CI/CD 流水線的集成和發布，當前UCS提供如下關鍵能力，幫助用戶實作便捷的多云交付，

▍開箱即用的GitOps引擎，兼容主流的開源生態和體驗

圖2：Flux2 主要組件的運行原理

UCS 會為每個開啟 GitOps 引擎的集群安裝一個穩定開源版本的 Flux2 組件，且用戶無須運維 GitOps 引擎，每個集群中的 GitOps 引擎會以Pull模式、定周期監聽和拉取最新的倉庫源配置資訊并把最新的配置資訊及時同步至集群中，

如圖2所示：Source-Controller 主要負責監視 Git 倉庫源、Bucket 物件存盤桶以及 Helm 倉庫的存盤配置變化，然后把最新 Commit 記錄的制品包拉取至集群本地，而 Kustomize-Controller 和 Helm-Controller 則會負責監聽集群本地拉取制品變化情況，其中以 Helm Chart/Helm Release 型別定義的制品會交由 Helm-Controller 進行渲染和同步至集群中；同理，按照 Kustomize 方式進行組織的制品交由 Kustomize-Controller 進行渲染和同步至集群中，

▍豐富的多集群差異化配置能力

隨著部署應用的規模越來越大，部署集群的底層差異性越來越大，我們發現單一的一份配置對應一個集群的模式會變的越來繁瑣和難以維護，因此面向多個集群的差異化配置策略隨之出現，UCS 配置管理功能提供了兩種多集群差異化配置的策略: Kustomize 和 Helm Release，

Kustomize 是一個 Kubernetes 應用程式配置管理工具，它提供一種簡單靈活的方式來生成 Kubernetes 資源，并可以使得這些資源在不同的環境中用不同的方式進行配置[4]，如圖3所示，Kustomize 策略在 Base 目錄下定義所有集群公共部署資源，然后在 Overlay 目錄下描述每個集群產生差異化覆寫引數，然后在部署階段，通過動態渲染引數將最終版本的制品交付至目標集群中，

圖3：Kustomize 制品組織目錄示意圖

同理，HelmRelease 也是參考上述思路，將公共定義的資源放置在 templates 目錄下，然后結合 valuesFrom/valuesFiles 等方式從 value.yaml 讀取每個環境的差異化引數，滿足客戶差異化的配置訴求，其配置的重點在于做好定義公共部分抽象和少數變數的差異化配置，對應用本身引數屬性和運維引數進行分離，減少重復編輯和維護的成本，

▍基于Git的可審計、可持續的部署能力

UCS 配置管理將 Git 倉庫中最新合入的制品配置資訊同步部署至納管的多個集群中，同時對應用發布行為進行版本化管理和權限控制，提供發布回滾和版本迭代控制，并進行審計跟蹤，

基于UCS GitOps+Pipeline流水線構建多云DevOps解決方案

隨著 DevOps 價值觀和文化的流行，越來越多的公司選擇幫助開發團隊分擔應用程式交付的責任，他們將多云環境下的交付交給專門的運維團隊來完成，讓開發團隊可以更加專注于應用程式的開發和構建本身[5,6]，基于 UCS GitOps+Pipeline 流水線可構建多云DevOps 的解決方案，實作多云環境下多云應用構建和發布，開發團隊和運維團隊可以基于 Git 作業流，將現有流程對接到華為云 CodeArts Pipeline 流水線或者企業自建的 CI/CD 流水線之上，從而擁有多云應用的業務開發、集成、測驗再到多云應用的部署—全流程 DevOps 體驗，具體來講將分為以下兩個階段：

1、定義和構建多云應用：開發團隊進行業務的開發、測驗、驗證、打包軟體和生成鏡像，這里可以是采用華為云官方的 CodeArts Pipeline 流水線或者用戶自建的 CI 流水線，然后定義每個集群交付資源的原始制品檔案，

2、交付多云應用：運維團隊首先會根據開發團隊提供的原始制品檔案對部署在多個集群環境中的差異化內容進行配置，此環節需要做好定義公共部分抽象和少數變數的差異化配置，對應用本身引數屬性和運維引數進行分離，減少重復編輯和維護引數的成本，

然后使用 UCS GitOps 統一初始化集群所需的環境和資源，對發布步驟進行編排，通過更新配置倉庫來一致的對多個集群進行自動化應用發布；同時運維團隊還對應用發布行為進行版本化管理、權限控制和審計，提供發布回滾和版本迭代控制，保證業務應用的成功部署，

圖4：結合UCS GitOps的多云DevOps流水線

下面將以一個詳細的例子來解釋：華為云某亞太跨國公司客戶需要統一管理橫跨多國的 Kubernetes 集群和進行業務發布，他們的線上商城業務應用同時運行在香港的華為云 CCE 集群中，新加坡的亞馬遜云 EKS 集群中；并且他們在馬來西亞還擁有一部分自建資料中心集群供開發團隊進行業務開發和測驗驗證，由于每個國家消費者的商品喜好差異以及當地的供應鏈供給不同，商城中發布的商品類別會存在差異，在原有的交付流程中，運維團隊會根據每個地域的供應商集群控制面板風格、部署業務版本，業務更新頻率等因素，為每個環境單獨構建一條流水線獨立交付；并在每次發布版本前，運維團隊會與開發團隊就新版本特點和每條流水線的部署細節進行詳細磋商，

而使用 UCS GitOps 可以大大降低交付上述流程的復雜度，如圖4的解決方案中所示，客戶采用多套環境共享一套 CI 流水線，并將構建的產物統一推送至華為云香港的SWR 鏡像倉庫，然后通過差異化配置不同環境的部署引數，將多個環境的發布對接到華為云 CodeArts 配置倉庫，實作了從本地集群測驗和驗證到多個生產集群的發布的無縫切換，也極大的提升了他們多云交付的效率，

總結

綜上所述，華為云 UCS GitOps 是以 Flux2 為技術內核，將其與 UCS 的容器艦隊/集群模型進行適配的多云交付平臺，它通過簡單易用的 UI 提供對華為云集群、多云集群、本地集群、附著集群和伙伴云集群進行跨命名空間、跨集群的應用分發與配置管理的能力，并在觀測面板中對配置的實時狀態進行收集和展示，它可以幫助您將多個集群環境的配置和治理集中于一處，以自動化的體驗完成多集群基礎設施的管理以及多云應用的發布及更新，

同時 UCS 會持續關注開源社區側多集群 GitOps 的發展趨勢，并將優質特性采納為產品的內核，在后續的版本迭代中，下列特性將會逐步支持：

1、支持容器艦隊級別的配置分發：通過對艦隊內部集群進行標簽化管理，完成艦隊視角下應用的一鍵分發和統一管理，

2、全面對接華為云 CodeArts Pipeline：提供全流程、更好融合體驗的多云 DevOps 流水線，

3、在界面中提供對接三方訊息系統的應用發布狀態感知能力：一方面處理來自外部系統（GitHub、Bitbucket、Harbor、Jenkins）的事件，然后通知 GitOps Toolkit 控制器有關源更改的資訊；另一方面處理由 GitOps Toolkit 控制器發出的事件，然后根據事件的嚴重性和涉及的物件將它們轉發至外部系統（Slack、Microsoft Teams、Discord、Rocker），

參考資料

[1]在 Kubernetes 環境中自動化證書管理 https://www.nginx.com/blog/automating-certificate-management-in-a-kubernetes-environment

[2]使用 Flux 管理多集群基礎設施 https://github.com/fluxcd/flux2-kustomize-helm-example/blob/main/infrastructure/controllers/cert-manager.yaml

[3]Codefresh Continuous Delivery for Kubernetes

[4]使用 Kustomize 對 Kubernetes 物件進行宣告式管理  https://kubernetes.io/zh-cn/docs/tasks/manage-kubernetes-objects/kustomization/

[5]Enterprise CI CD Best Practices

[6]GitOps-2.0 The Future of DevOps Ebook v4

點擊關注，第一時間了解華為云新鮮技術~

標籤：其他

上一篇：天翼云SD-WAN解決方案直播

下一篇：返回列表