本文主要内容如下： 

• 概述
• Karmada主要功能
• Karmada技术架构
• Karmada优势
• Karmada分发流程
• Karmada应用场景
• 未来展望

1、概述

随着企业业务的快速发展，多云也逐步成为数据中心建设的基础架构，多区域容灾与多活、大规模多集群管理、跨云弹性与迁移等场景推动云原生多云相关技术的快速发展。 然而，在实际的生产落地过程中，云原生的多云仍面临如下挑战：

• 集群繁多的重复劳动：运维工程师需要应对繁琐的集群配置、不同云厂商集群间的管理差异以及碎片化的API访问入口等问题；
• 业务过度分散的维护难题：应用在各集群的差异化配置繁琐；业务跨云访问以及集群间的应用同步难以管理；
• 集群的边界限制：应用的可用性受限于集群；资源调度、弹性伸缩受限于集群；
• 厂商绑定：业务部署的黏性问题，缺少自动化故障迁移；缺少中立的开源多云容器编排项目。

为了解决云原生多云存在的问题，Karmada结合华为云多云容器平台MCP以及Kubernetes Federation核心实践，并融入了众多新技术：包括Kubernetes原生API支持、多层级高可用部署、多集群自动故障迁移、多集群应用自动伸缩、多集群服务发现等，并且提供原生Kubernetes平滑演进路径，让基于Karmada的多云方案无缝融入云原生技术生态，为企业提供从单集群到多云架构的平滑演进方案。

2、Karmada主要功能

Karmada 整体的功能视图如下图所示：

Karmada 相当契合我们工作中的实现目标要求，具有整体的集群生命周期管理、集群注册，包括多集群的伸缩、调度、统一的 API、底层的标准 API 支持，并且 CNI、CSI 在其整体的功能视图中，对 CI/CD 有整体上的规划与考虑，所以工行最终决定投入到该项目中，与华为在内的一系列伙伴共建该项目并回馈到社区中。

3、Karmada技术架构

Karmada 控制平面由以下几个组件组成：

• API 服务器（Karmada API Server）
• 控制管理器（Karmada Controller Manager ）
• 调度器 (Karmada Scheduler)

Karmada通过独立的API 服务器（Karmada API Server）提供与其他组件进行通信的 REST 接口，包含Kubernetes原生API及Karmada扩展API，而Karmada 控制管理器根据用户创建的 API 对象执行操作, Karmada 调度器则实现应用在多集群中的调度。

Karmada 控制器运行各种控制器，控制器监视Karmada 的对象，然后与底层集群的 API 服务器通信，对Kubernetes资源进行全生命周期管理。

集群控制器：聚焦集群管理，将 Kubernetes 集群附加到 Karmada，通过创建集群对象管理集群的生命周期。

策略控制器：实现PropagationPolicy对象的生命周期。根据 PropagationPolicy中的resourceSelector 匹配对应Kubernetes资源对象，并为创建ResourceBinding以进行应用多集群调度。

绑定控制器：实现 ResourceBinding 对象的生命周期，根据调度器的角度结果，为每个调度到目标集群的对应资源创建Work 对象；

执行控制器：负责work对象与成员集群中实际资源对象的状态同步。

4、Karmada技术优势

Karmada 的优势分为以下四点。

• 自定义跨集群调度策略。
• 对上层应用透明。
• 支持两种资源绑定调度。

• 动态 binding 调整。
• 按照集群标签或故障域自动分发资源对象。

• 支持集群注册。
• 全生命周期管理。
• 统一标准的 API。

• 支持 k8s 原生对象。
• works 支持子集群资源部署状态获取。
• 资源对象分发既支持 pull 也支持 push 方式。

5、Karmada分发流程

Karmada Resources 分发流程示意图如下图所示：

Karmada Resources 分发流程如下：

• 第一步，集群注册到 Karmada。
• 第二步，定义 Resource Template。
• 第三步，制定分发策略 Propagation Policy。
• 第四步，制定 Override 策略。
• 第五步，看 Karmada 干活。

Propagation 机制分发如下：

Propagation Policy 信息配置

• 集群亲和性。
• 集群容忍。
• 按集群标签、故障域分发。

具体的 Work 分发机制如下图所示：

6、Karmada应用场景

Karmada是华为云今年开源的云原生多云容器编排项目，沉淀了众多企业在多云管理领域的丰富经验，可构建无限可扩展的容器资源池，让开发者像使用单个K8s集群一样使用多云。目前Karmada已正式捐赠给云原生计算基金会CNCF，也是CNCF首个多云/多集群容器编排项目。Karmada 项目的加入，将CNCF 的云原生版图进一步扩展至分布式云领域。

自该项目发布以来，社区中的很多伙伴也共同参与项目开发，如今已经运行在很多生产环境当中。工商银行作为发起单位之一目前已经依托Karmada对其容器云管平台进行了全面升级，并且深度参与到Karmada的设计与研发中，在实践过程中也总结了Karmada的优势，主要有资源调度、容灾、集群管理、资源管理四大类，而以下几点在真实落地过程中会显得尤其突出：

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

支持K8s原生对象，保证了大量 K8s 外部客户端几乎无需改造

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

在容器云方面，工行的金融云成效也是非常大的，首先体现在它的入云规模大，截至目前应用平台云容器规模超20万，业务容器占到55,000个左右，整体的一些核心业务都已入容器云内部。除了在同业的入云规模最大之外，我们的业务场景涉及非常广泛，一些核心的应用，核心的银行业务系统，包括个人金融体系的账户，快捷支付、线上渠道、纪念币预约等，这些核心的业务应用也已容器化部署；另外，我们的一些核心技术支撑类应用如MySQL，还有一些中间件以及微服务框架，这一类核心支撑类应用也已入云；此外，一些新技术领域，包括物联网、人工智能、大数据等。

当越来越多的核心业务应用入云之后，对我们最大的挑战是容灾以及高可用，在这方面我们也做了很多实践：

1）云平台支持多层次故障保护机制，确保同一业务的不同实例会均衡分发到两地三中心的不同资源域，确保单个存储、单个集群甚至单个数据中心发生故障时，不会影响业务的整体可用性。

2）在故障情况下，云平台通过容器重启及自动漂移，实现故障的自动恢复。

在整体容器云实践下，我们也遇到了一些问题，其中比较突出的是 pass层容器层的多集群的现状。现在工行内部整体的k8s总数，k8s集群的总数已近百个，主要的原因有4个：

1）集群种类多：刚刚也说了我们的业务场景非常的广泛，比如GPU要有不同支持GPU的设备，一些中间件，数据库它对底层的网络容器存储的需求是不同的，那势必会产生不同的解决方案，因此我们需要为不同的业务场景定制不同集群。

2）受到k8s本身性能的限制，包括scheduler、 etcd 、API server等一些性能瓶颈，每一个集群也有它数量的上限。

3）业务扩展非常快。

4）故障域分区多，我们两地三中心的架构至少有三个DC,每个DC内部还有不同的网络区域，通过防火墙进行隔离, 这样的倍乘关系，中间就会产生很多集群故障域的分布。

基于以上4点，针对当前的现状，我们现有的解决方案还是依靠容器云的云管平台，通过云管平台管理这些多k8s集群，另外上层的业务应用需要自主选择它的集群，包括它需要的偏好、网络、区域等，去选择它具体的某一个k8s集群。在选择到k8s集群之后，我们内部是通过故障率进行自动打散的调度。

但现有的解决方案对上层应用还是暴露出非常多的问题：

1）对上层应用来说，它可能上了容器云比较关心的一个部分，就是我们具有在业务峰值的过程中自动伸缩的能力，但自动伸缩现在只是在集群内部，没有整体的跨集群自动伸缩的能力。

2）无跨集群自动调度能力，包括调度的能力可能都是在集群内部，应用需要自主的选择具体的集群

3）集群对上层用户不透明

4）无跨集群故障自动迁移能力。我们还是主要依靠两地三中心架构上副本的冗余，那么在故障恢复的自动化恢复过程中，这一块的高可用能力是有缺失的。

业界多集群管理方案及选型

基于目前的现状，我们定下了一些目标，对业界的一些方案进行整体的技术选型，总共分为5个模块：

当时我们和华为交流到了多集群管理的一个现状以及痛点，包括对社区联邦类项目的讨论，我们双方也非常希望能够在这方面革新，下图为Karmada的功能视图：

从它整体功能视图及规划来看，和我们上文提到的目标非常契合，它有集群整体的生命周期管理、集群注册、多集群伸缩、多集群调度、整体统一的API、底层标准API支持，它都是CNI/CSI在它整体功能视图里，包括上层的应用、对Istio、Mash、CI/CD等都有整体规划上的考虑。因此基于整体思路，它的功能与我们非常契合，工行也决定投入到这个项目中来，跟华为和我们很多的项目伙伴共建Karmada项目，并把它回馈到我们社区整体。

7、未来展望

跨集群伸缩现在也是在Karmada规划当中,现在我们可能还是需要解决一些问题:

1. 考虑它跨集群伸缩和子集群伸缩之间的关系，因为现在往往我们上层业务应用配置的是单个集群伸缩的策略，那么整体跨集群的策略与子集群伸缩策略都配置时，它们之间的关系，到底是上层整体去做管理，还是有优先级，这可能是我们后面需要考虑的。
2. 跨集群伸缩和跨集群调度间的关系，我觉得整体上还是以一个调度器为准。我的一个Multi-cluster仅仅负责伸缩的部分，比如到达了多少CPU、多少的内存，比如说70% -80%的时候去进行伸缩，伸缩到多少个，具体的调度还是由整体scheduler去进行。
3. 需要汇聚各个集群的metric，包括可能有一些性能瓶颈，它整体的工作模式，是需要我们后续去考虑的。

【与云原生的故事】有奖征文火热进行中：https://bbs.huaweicloud.com/blogs/345260