本文为云原生应用创新实践联盟——容器云自动化运维课题组生产内容，相关专家如下所示，更多内容可 点击此处进入云原生应用创新实践联盟 进行查看。
  ① 已通过课题组专家审核
  ② 待课题用户组织评议（欢迎各位在下方评论区提出您的宝贵意见）

执笔专家：
唐伟志 容器云自动化运维用户委员会委员
twt社区云原生应用创新实践联盟——容器云自动化运维方向课题组专家。担任国信证券容器云平台负责人，目前负责国信证券容器、kubernetes等云原生相关技术架构和开发工作，专注于分布式系统、云原生、多集群管理和微服务治理等方向。曾在电子工业出版社出版技术书籍《深入理解分布式系统》。

顾问专家：
孙洪轩 容器云自动化运维用户委员会委员
twt社区云原生应用创新实践联盟—— 容器云自动化运维方向课题组特邀外部专家。 多年IT研发经验，近几年一直深耕区块链，云原生等前沿技术领域。作为光大科技的自动化专家，先后为集团设计并建设了区块链云服务平台，容器云PaaS平台等中大型项目。具备丰富的软件架构设计，项目落地经验
毛天明 容器云自动化运维用户委员会委员
twt社区云原生应用创新实践联盟—— 容器云自动化运维方向课题组专家。 10年金融行业工作。太平洋保险容器工作前负责人，领导容器云平台的项目建设5年。电信翼支付容器工作负责人，领导容器云平台的项目建设3年。主要从事云原生架构建设、应用容器化改造、CICD工具链设计。2020 容器云职业技能大赛百位专家委员会成员。

摘要：

从容器、Kubernetes 和 DevOps 等技术问世，业界一遍遍地质疑它们是否能够禁得住生产级别考验，到今天许多大型企业大规模采用 Kubernetes 已成事实。

而随着云原生技术的普及和落地，越来越多的云原生应用需要差异化的部署到不同的环境或不同的数据中心中，不同应用不同组件在不同的环境或集群会存在多个差异化配置，传统通过流水线进行持续交付的模式不再适合Kubernetes声明式和控制循环的模式，在这种情况下，应用的发布管理越复杂，业务系统将面临巨大的风险。以 ArgoCD 和 FluxCD 等持续交付为代表的 GitOps 为管理基础设施和应用程序提供了一种方法，以声明式描述整个系统并进行版本控制，提供了一个自动化的过程来确保部署的环境和存储库中期望的状态相匹配。

本文讨论了企业容器云在多集群情况下如何实践 DevOps。首先分析了如今容器云出现多集群的原因，然后介绍了云原生 DevOps 的落地方式——GitOps，并推荐了一种多集群 GitOps 工作流作为落地参考，最后部分介绍了在持续集成和持续交付中具体实践 GitOps 的主流方式，能有效地帮助读者了解和落地容器云多集群 DevOps 实践，帮助读者比较和选择众多 DevOps 工具和方法，少走弯路。

1 为什么需要多集群 Kubernetes

虽然 Kubernetes 成为容器编排领域的事实标准，解决了大多数容器编排领域的问题，但 Kubernetes 原生的管理能力仍然停留在但单集群级别。每一个集群可以稳定地自治运行，但是却缺乏横贯多个集群的统筹管理能力。企业内部出现多集群 Kubernetes 主要有以下几个原因。

1.1 Kubernetes 单个集群规模问题

单个 Kubernetes 集群存在规模性限制，并且在扩容的过程中，etcd、API Server、调度器以及控制器都有可能出现性能瓶颈。以 v1.23 版本 Kubernetes 为例，官方社区给出的单集群规模数据如下：

• 单个集群节点数不超过 5000；
• 每个节点的 Pod 数量不超过 110；
• Pod 总数不超过 150000；
• 容器总数不超过 300000；

社区中也有一些开发者试图突破该规模上限，例如在节点上增加缓存降低 API Server 的负载。但其缺乏官方社区支持，暂时没有被业界广泛接受。

1.2 高可用架构

为了提高业务应用的可用性，避免单个集群或单个数据中心故障导致业务应用暂时不可用，影响用户正常使用，大型企业通常会对业务应用进行灾备甚至多数据中心多活部署，这也会导致业务应用被部署在多个不同的 Kubernetes 集群中。

除此之外，企业内外部也常有开发、测试和 QA 等多个不同环境，一个企业可能存在有以下环境：

（1）开发测试环境
（2）QA 环境
（3）预发环境
（4）生产环境

同时，按照高可用架构，生产环境还会部署在三个数据中心或云上环境，这样算下来至少有 6 个不同的集群环境——这还只是一个部门或一个应用的情况。

1.3 混合云架构

如今企业还会采用内部基础架构、私有云和公有云的混合云基础架构，自然也会引入多集群 Kubernetes。

2、容器云多集群管理

容器云多集群管理就是通过统一的控制平台纳管多个 Kubernetes 集群。通过容器云平台，平台管理人员能够获知多集群节点健康状态、资源使用情况和集群使用情况等信息；业务应用负责人和开发能够决策如何调配应用服务在各个集群中的部署分布；应用的运维人员能够获知服务状态。因此，多集群管理涉及资源管理、跨集群资源访问和调度以及运维和管理三大块。

多集群管理暂无统一成熟的事实标准，开源社区和各大厂商都已对这一方向进行了长时间探索，社区中的多集群兴趣小组（SIG Multi-Cluster）和，以及 RedHat、蚂蚁、华为和腾讯等厂商都提出自己的方案。

多集群管理项目众多，但我们可以从集群联邦和非集群联邦来归类，我们来简单对比下两种方案。

2.1 基于 KubeFed 的多集群管理

(1) RedHat 和 Kubernetes 社区牵头的 KubeFed
KubeFed 是最早的 Kubernetes 集群联邦项目，主要支持：跨集群的资源同步与伸缩、跨集群的服务发现。KubeFed 能够根据负载情况，调度并调节各集群的资源分布，同时能够提供跨集群的应用故障转移，以及跨集群的服务发现。实现了方便的跨地区、跨服务商配置并管理多个 Kubernetes 集群，以及多集群资源的统一管理。但是，其 API 复杂、CRD 编写不规范等缺点，也成为掣肘其推广的关键。

Kubefed 项目今天基本处于停止维护的状态，项目也鲜有更新。

(2) RedHat、蚂蚁和阿里云共同发起并开源的 OCM（Open Cluster Management）
OCM 旨在解决多集群、混合环境下资源、应用、配置、策略等对象的生命周期管理问题。OCM 基于 KubeFed 优化而来，它将管理开销从中枢集群下放到每个被管理集群上的代理（Agent）上，让它在整个基础设施中分布式自治并维护稳定。这使得 OCM 理论上能管理的集群数量至少比 KubeFed 多一个数量级。到目前为止，官方宣称可同时管理多达 1000 个集群。

(3) 此外，同样继承自 KubeFed 的还有华为云开源的 Ka