摘要：使用华为云 UCS GitOps 配置管理来交付您的多云应用。
本文分享自华为云社区《华为云 UCS GitOps：轻松交付多集群云原生应用》，作者：华为云云原生团队。
随着业务的全球化发展和应用多元化部署的趋势，越来越多的客户选择通过混合云、多云模式来进行业务部署。选择多云进行部署可以提高部署业务的基础设施稳定性，在单个供应商基础设施出现故障或者访问流量激增时，可以通过配置跨云弹性来提高业务的高可用性，同时，多云还可以避免企业的技术架构被厂商锁定。尽管使用多云的优点很多，但管理多云集群和在多云的场景下发布应用却面临诸多问题和挑战。
例如，在多集群场景下的网络策略的配置，TLS证书的发布及更新管理。在现代应用程序的部署步骤中，SSL/TLS证书是很重要的一环。但在部署应用程序时，管理证书的续订通常是事后才想到的。证书的生命周期从90天到13个月不等，为了保持安全访问，这些证书需要在到期前更新/重新颁发。
鉴于大多数 Ops 团队工作繁杂，证书更新有时会被遗漏，这会导致应用间不能正常访问和工作。在多集群场景下，运维团队会每个供应商集群重复上述过程进行证书更新；而通过 GitOps 结合 Cert-manager[1]、Nginx Ingress Controller 可以一致的、统一的管理证书的自动化更新 [2]、大大提升 Ops 团队的运维管理效率 。
根据应用程序的业务场景诉求不同，不同集群部署的业务版本，更新频率会存在不同。例如同一餐厅在不同地域的点餐系统可供给的菜单种类，菜单上新会有差异；或由于跨国公司在不同国家推广策略不同，新的业务软件仅需要部署至部分城市所在集群等。
同时，由于业务部署的基础设施不同，应用程序部署到集群的底层架构、网络连接性、计算存储性能表现可能多种多样。例如同一份应用配置在被差异化渲染后可以被交付和托管在云上的CCE、EKS集群、客户本地数据中心中的集群（存在断连情况）、边缘端无人机的集群上（半连接集群）以及太空中卫星链所组成的集群（短时连接集群）。
因此根据每个集群的性能指标（CPU、Memory）不同，部署业务应用的实例副本数可能会不同；根据每个集群的网络连接情况不同，设置部署业务的版本更新周期，高可用设置（访问某个服务的超时重试次数等）会产生差异；根据每个集群的使用目的不同（早期生命周期阶段的集群通常由开发人员管理，而实际的预发及生产集群的可能由客户的运维团队管理），部署业务的版本和数据库连接池等变量也会存在差异。因此当有M个应用需要交付至N个集群环境中时，差异化配置的复杂度会呈M×N维度爆炸增长。
随着微服务规模变大，依赖UI控制台进行应用交付的方式变得复杂臃肿，其交付的顺序编排依赖人工，无法做到自动化；且无法进行审计和版本控制。
在多云集群场景下，当前缺乏统一的视图帮助客户查看应用在多集群的部署情况、应用的健康状态及异常状态定位。
为了应对上述多云集群管理和多云应用交付的挑战，华为云 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提供如下关键能力，帮助用户实现便捷的多云交付。
图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 读取每个环境的差异化参数，满足客户差异化的配置诉求。其配置的重点在于做好定义公共部分抽象和少数变量的差异化配置，对应用本身参数属性和运维参数进行分离，减少重复编辑和维护的成本。
UCS 配置管理将 Git 仓库中最新合入的制品配置信息同步部署至纳管的多个集群中，同时对应用发布行为进行版本化管理和权限控制，提供发布回滚和版本迭代控制，并进行审计跟踪。
随着 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
MySQL 8.0中的数据字典，通过对两级缓存的逐级访问，以及精妙的对缓存未命中情况的处理方式，有效的加速了在不同场景下数据库对DD的访问速度，显著的提升了数据库访问元数据信息的效率。