与 Karmada 一起航行：海量节点的多集群管理

在 KubeCon2021 上，中国工商银行软件开发中心云平台架构师沈一帆和华为云云原生开源负责人王泽锋发表了《与 Karmada 一起航行：海量节点的多集群管理》专题演讲，分享了工商银行多 k8s 集群管理实践过程。

*Karmada 项目介绍部分由王泽锋分享，其余部分的分享来自沈一帆

工行云平台的建设现状

• 工行目前的业务上云场景是丰富多样的，既有以春节红包等支付线为代表的核心业务类应用，也有以 MySQL、Redis 为代表的技术支撑类应用，也包含了区块链、人工智能等新技术领域。

• 目前工行云平台也是基于主流的开源项目进行了深度的定制化研发，保证了整体的自主可控性。

• 从建设情况来看，也是同业最大规模的一个容器云，目前数量达到了 28 万+。

典型业务需求及云原生基础设施现状

在大规模的云原生基础设施的背景下，工行的业务对我们提出的具体的要求以及目前的现状：

典型的业务需求主要包含：业务需要高可用的部署、应用需要跨集群地进行弹性伸缩以及跨集群的调度，一些业务产品需要对 K8s 版本有特定的一个依赖。

基于以上情况，工行目前的云原生基础现状如下：

• 单集群可靠性要求比较高。我们整体的单集群的节点数量在 2000 以下，就是为了缩小集群的一个故障率影响范围。

• 资源池随业务快速增长。目前新业务应用是全面上云，存量应用是持续地迁移入云，现在核心应用已经全部入云。

• 业务级异构集群。业务对特定的 K8s 版本有依赖，并且有大量的异构的 CNI、CSI、包括底层一些硬件异构。

• 多地、多中心、多云的建设现状，工行业务上包括总行云、分行云，生态云等。故障域方面是两地三中心的数据中心建设，并且在数据中心内部也有多故障域方面更细粒度的划分。

关键挑战

基于以上的现状，工行内部的 K8s 集群数量其实已经达到了 100 个以上，目前由容器云平台统一纳管管理。但在持续发展的过程中，我们也面临着以下问题：

• 可用性受限，因为 K8s 集群本身也是一个故障域，目前缺少跨故障域自动恢复。

• 资源受限，整体的应用的调度和弹性伸缩受限于单集群。

• 集群不透明：由于集群目前都打上了异构、故障域等属性，业务团队需要感知底层的集群去自主选择 K8s 集群，就导致了 K8s 集群本身是对上层应用是不透明的。

• 重复配置。尽管我们的业务统一在云管平台进行了配置的录入，但具体的配置需要下发到各个集群当中，且各个集群需保证同步。

设计目标

面对这些挑战，我们对多集群的管理拟定了设计目标：

• 在多集群管理平面方面：集群纳管和对集群有整体生命周期管理，并且具有统一标准的 API 入口。

• 在资源管理方面，需要支持多版本全面的 K8s 资源，同时也需要多维度的资源 Override 支持。

• 在跨集群自动调度方面，调度上需要按故障域、资源余量等进行自动调度，并且可跨集群自动伸缩。

• 容灾方面，需要进行跨集群资源的自动恢复，并且管理平面与业务集群需要解耦。

• 兼容性方面，对存量大量的异构集群需要平滑的纳管，同时项目本身需要高扩展性及社区的活跃度。

联合创新

有了清晰的设计目标，接下来就是如何实施落地了。首先对于商用产品，考虑到单一厂商的绑定和不符合自主可控的要求，首先被我们 pass，而调研 Kubefed 之后，发现它使用非原生 API，对于我们存量集群来说迁移难度过大，且近期社区活跃度下降。最后我们选择以最贴合我们需求的方式，立足自身进行联合研发，同时工行金融云本身也是基于开源，所以我们也是积极地投入到开源共建，推动社区发展这个良性循环中来，最后选择联合发起 karmada 项目。

Karmada 项目

为什么不在原有 KubeFed 的基础上继续演进，而是发起一个全新的项目呢？

实际上我们在项目的初期考虑的确实是 Kubernetes Federation 的 V3 版本，并且很快地完成了原型的开发。然而在后来与许多的社区用户的交流过程中，我们发现其实狭义的 Federation 的项目范围并不能完整地覆盖大家期望提供的能力版图。除了 Federation 本身包含的多集群应用负载管理的能力之外，其实我们重点还希望去提供像多集群的资源调度、故障迁移、自动伸缩，以及像多集群的服务发现、数据自动化和多平台支持的集群的生命周期管理等等，为用户真正地去提供开箱即用的多云多集群的开源软件站。因此一个托管于 CNCF 的中立的开源项目，会更适合于长期的技术演进和社区发展。

Karmada 技术全景图

Karmada 的核心架构

在 Karmada 的核心架构方面，吸取了多家社区发起单位在多集群管理上的经验和心得，我们把重点放在了 K8s 原生 API 支持、以及框架可扩展性上。

与 K8s 单集群架构略有相似：

• Karmada 的控制面拥有自己独立的 APIserver，来提供 K8s 原生 API 以及 Karmada 的扩展 API

• 通过 Karmada Scheduler，提供针对 [故障域、集群资源、K8s 版本及集群开启插件等多维度、多权重的]调度策略支持，并方便用户自定义扩展

• 与 member 集群的同步方面，Karmada Agent 的 pull 工作模式，可以有效分散控制面压力，实现超大规模多集群资源池的管理。

• 同时，Karmada 还支持 ExecutionController 以及集成 KubeEdge 方式实现对位于公有云、私有云以及边缘等各种网络环境中 K8s 集群的直接管理。

• 而借助 ExecutionSpace 的设计，Karmada 实现了不同集群之间的访问权限和资源隔离，来满足多集群场景下的安全性需要。

Karmada 核心概念

在 Karmada 核心概念的设计方面,我们把用户输入的一切工作负载相关资源对象定义为 Resource Template，这是严格的 K8s 原生 API，支持包括 deployment，service，configmap 等，以及用户自定义的 CRD 资源对象。这样，用户无需任何修改，就可以直接使用原有单集群的 YAML 或者 API 来创建多集群应用，而原本在 K8s 之上二次开发的业务平台也不用做任何的修改。

针对应用跨多集群的拆分和调度，扩展的 Propagation Policy 支持被多个应用复用的定义。得益于这种解耦的设计，在像工行这样独立设置平台团队和业务团队的场景中，平台团队可以针对通用的高可用部署模型设置策略，而业务团队则可以继续使用 K8s 原生的单集群 API 来管理日常的业务上线和版本升级。

案例：用户如何使用 Karmada 管理业务

零改造：使用原生 API 部署一个 3AZ 高可用的应用

那在这个例子中我们可以看到，其实首先是一个 Propagation policy。在这个 Propagation policy 的定义中，平台团队设置了 Resource selector，限定所有的 Deployment，如果它带有特殊的 Label，HA mode 为 Multi zone replication，则把这些应用严格地分发到三个 Zone 里面去。而右边就是我们所熟悉的一个标准的 Deployment 的 API 的定义。通过组合这两个定义，其实我们可以看到平台团队聚焦在了通用的应用部署的模型的设置上，而业务团队聚焦在了它本身的应用内部的如 Image、版本，以及像这些 Container port 等等的定义上面。而 Karmada 负责将两个团队的需求做结合，实现应用的跨区域的高可用。在任何底下集群出现故障的情况下，可以通过动态的调度能力，自动地去补齐缺失的集群或缺失的可用区的应用实例，来实现跨集群的故障迁移。

实践心得

在 Karmada 设计研发实践再设计研发的正向循环的过程中，工行也总结了一些它的优势，也可以说是心得。主要分以下四类：资源调度、容灾、集群管理和资源管理。那么其中我认为尤其值得关注的是以下三点，那么在真实落地的过程中也显得尤为得突出。

• 支持多种资源的绑定调度，这保证了业务节点所需的 k8s 资源能够同时调度，也大大提升了我们资源发放的实时性。

• 支持 k8s 原生对象，这保证了我们大量的目前的 k8s 外部客户端几乎无需改造。

• Karmada 目前支持 Pull 和 Push 模式分发，适配了多种场景。尤其在我们大规模集群数量的一个场景下，使用 Pull 模式能大大减轻 Karmada 控制平面性能压力。

后续计划

在大规模生产落地方面，我们希望容器云平台将来是作为面向用户的一个平台，底层基于 Karmada 统一管理多集群的资源和调度，以此去纳管存量包括异构集群在内的 100+的 k8s 集群。

在社区贡献方面，我们希望持续地进行社区贡献。主要关注的特性包括存量应用的平滑迁移，能够自动纳入到 Karmada 联邦化。在跨集群伸缩、应用迁移与数据联动方面，继续持续地进行优化和落地。

最后，欢迎大家访问 Karmada 项目的 GitHub，查看 Release note 和社区文档，了解更多的功能和细节。如果在使用 Karmada 的过程中有任何建议和反馈，欢迎加入社区群和我们交流与讨论！

附：Karmada 社区技术交流地址

项目地址：https://github.com/karmada-io/karmada

Slack 地址：https://karmada-io.slack.com