与Karmada一起航行：海量节点的多集群管理
在KubeCon2021上，中国工商银行软件开发中心云平台架构师沈一帆和华为云云原生开源负责人王泽锋发表了《与Karmada一起航行：海量节点的多集群管理》专题演讲，分享了工商银行多k8s集群管理实践过程。
工行云平台的建设现状
工行目前的业务上云场景是丰富多样的，既有以春节红包等支付线为代表的核心业务类应用，也有以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社区技术交流地址