K8s 多集群实践思考和探索

随着K8s和云原生技术的快速发展，以及各大厂商在自己的数据中心使用K8s的API进行容器化应用编排和管理，让应用交付本身变得越来越标准化和统一化，并且实现了与底层基础设施的完全解耦，为多集群和混合云提供了一个坚实技术基础。谈到多集群多云的数据中心基础架构，会想到为什么企业需要多集群？

2.1 社区在多集群上的探索

当前基于 K8s 多集群项目如下：

以上多集群项目主要功能为资源分发和调度，还有如多云基础设施管理cluster-api，多集群检索Clusterpedia，多集群pod互通submariner，multicluster-ingress解决多集群的ingress，服务治理和流量调度 Service Mesh，如istio、cilium等网络组件实现的multi cluster mesh解决跨集群的mesh网络管理，以及结合存储相关项目实现跨集群存储管理和迁移等。

2.2 vivo 在多集群上的探索

2.2.1 非联邦集群管理

非联邦多集群管理系统主要是进行资源管理、运维管理和用户管理，提供导入K8s集群权限功能，并通过统一 Web 界面进行查看和管理。这类工具不引入额外集群联邦的复杂，保持每个集群的独立性，同时通过统一的 Web 界面来查看多个集群的资源使用情况，支持通过 Web 界面创建 Deployment、Service 和负载均衡等，并且会集成持续集成、持续交付和监控告警等功能。由于集群联邦技术还在发展，大多数企业倾向于使用这种方式来运维和管理多集群 Kubernetes 环境。当前vivo主要是通过这种方式管理多集群。

2.2.2 联邦集群管理

联邦集群主要将资源联邦化，实现资源的统一管理和调度。随着K8s在数据中心大量使用，K8s已成为基础设施管理的标准，不同区域部署已非常普遍。如K8s运行在云上来托管集群、企业自建数据中心的私有云、边缘计算等。越来越多的企业投入到多集群管理项目，当然联邦集群肯定会增加整体架构的复杂度，集群之间的状态同步也会增加控制面的额外开销。尽管增加了所有的复杂性，但普遍存在的多集群拓扑引入了新的令人兴奋的潜力。这种潜力超越了目前所探索的通过多个集群进行的简单静态应用程序编排。事实上，多集群拓扑对于跨不同位置编排应用程序和统一对基础设施的访问非常有用。其中，这引入了一种令人兴奋的可能性，可以透明而快速地将应用程序从一个集群迁移到另一个集群。在处理集群灾难或关键基础设施干预、扩展或布局优化时，移动工作负载是可行的。

vivo在联邦集群的探索方向主要有以下四个方面：

本次主要分享资源分发和编排、弹性突发和多集群调度以K8s为核心的联邦多集群探索。网络为核心的能力建设，主要为不同集群的网络可以通过如 Service Mesh或者 Mesh Federation打通，就可以实现网络流量的灵活调度和故障转移。实际上，也有很多应用通过隧道或者专线打通多个集群，进一步保证了多集群之间网络通信的可靠性。vivo网络和服务发现主要是开源的基础上自研，可以持续关注后面分享。

云原生技术的发展是持续输出“事实标准的软件”，而这些事实标准中，应用的弹性、易用性和可移植性是其所解决的三大本质问题。

那么一个以应用为中心，围绕应用交付的多集群多集群管理具备统一的云原生应用标准定义和规范，通用的应用托管和分发中心，基于 Service Mesh 的跨云的应用治理能力，以及 K8s 原生的、面向多集群的应用交付和管理体系，将会持续不断的产生巨大的价值。vivo当前主要结合Karmada和CNCF周边项目来探索以上挑战。

3.1 面向应用的多集群持续发布

3.1.1 应用发布

上图是面向应用的多集群持续发布架构，我们主要的工作如下：

一个应用真正的能管理起来其实很复杂，如特定的场景需要原地升级和灰度发布等。为了可以提供更加灵活、高级和易用的应用发布能力，更好地满足应用发布的需求，最终选择使用Openkruise。比如上图有个游戏的应用game-2408。它涉及到K8s资源有configmap、secret、pv、pvc、service，openkruise的cloneset、自研的服务发现和访问资源、以及Karmada的PropagationPolicy和OverridePolicy等资源，都能达到12个资源配置。比如存储等资源都是按需申请和分配的，为了有效管理这些资源和关系，当前主要通过关联数据库进行管理，并打通cicd和容器平台的交互，记录应用发布的状态转换，实现应用的滚动、灰度等发布能力，达到可持续发布的能力。

为了方便问题定位、K8s资源和Karmada资源的策略关系，当前Karmada 策略命名规范如下：

遇到的问题总结：

3.1.2 Openkruise资源解析

当前vivo的应用主要通过OpenKruise的Cloneset(无状态)和AdvancedStatefulset(有状态)控制器进行发布。Kamrada目前只能识别K8s默认的资源，其它的资源都需要开发资源解析。为了解决上面提到的问题，Karmada 引入了 Resource Interpreter Webhook，通过干预从 ResourceTemplate-> ResourceBinding ->Work ->Resource 的这几个阶段来实现完整的自定义资源分发能力。

3.2 面向应用的多集群弹性伸缩

3.2.1 弹性伸缩

跨集群HPA这里定义为FedHPA，使用了K8s原生的HPA，在Karmada控制平面通过FedHpaController实现跨集群的弹性调度扩缩容。

FedHPA流程：

3.2.2 定时伸缩

定时扩缩容是指应在固定时间点执行应用扩容来应对流量的高峰期。K8s本身没有这个概念，这里在Karmada控制平面定义了CronHpa资源，并通过Karmada-scheduler对多集群统一调度。避免非联邦化集群在多个member集群创建多个cronhpa。定时功能通过go-cron库实现。

CronHpa流程：

3.2.3 手动和指定扩缩容

手动扩缩容流程：

指定缩容，这里用到了openkruise能力。如训练模型需要将一批性能差的pod进行缩容。

指定缩容流程：

也可以尝试从Karmada控制平面指定删除pod和更改调度的结果，这样更加合理些，也不用添加Karmada资源解析。

3.3 统一调度

3.3.1 多集群调度

Karmada多集群调度主要实现跨集群资源的合理分配和集群故障快速迁移业务。如上图所示主要通过Karmada scheudler和emulator配合实现，其中emulator主要负责每个集群的资源的估算。

workload调度流程：

故障调度：

3.3.2 重调度

重调度的存在主要解决应用下发到member集群没有真正的运行起来，导致出现这样的情况可能是集群资源在不断的变化，应用正在Karmada-scheduler多集群调度的时候可能满足，但经过member集群二次调度时候无法调度。

重调度流程：

3.3.3 单集群调度模拟器

3.4 灰度上线

3.4.1  应用迁移

3.4.2 应用回滚

有了应用迁移的能力，是否就可以保证整个流程百分百没有问题，其实是无法保证的。这就必须有应用回滚能力，提升用户的迁移满意度。

回滚的必要性总结：

回滚流程：

3.4.3 迁移策略

应用迁移Karmada原则：

vivo当前主要通过非联邦多集群管理，结合CICD实现了应用静态发布和管理，具备了应用的滚动、灰度、手动扩缩容、指定缩容和弹性扩缩容等能力。相对于非联邦多集群部分能力不足，如跨集群统一资源管理、调度和故障转移等，在联邦集群进行部分能力的探索和实践。同时联邦集群增加了整体架构的复杂度，集群之间的状态同步也会增加控制面的额外开销和风险。当前社区在联邦集群还处在一个探索和不断完善的阶段，企业在使用联邦集群应结合自身需求、建立完善的运维保障和监控体系。对于已经存在的非联邦化的资源需要建设迁移和回滚能力，控制发生故障的范围和快速恢复能力。