摘要：使用華爲雲 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