关于k8s-operator:K8s-多集群实践思考和探索

作者：vivo 互联网容器团队 – Zhang Rong

本文次要讲述了一些对于 K8s 多集群治理的思考，包含为什么须要多集群、多集群的劣势以及现有的一些基于 Kubernetes 衍生出的多集群治理架构实际。

一、为什么须要多集群

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

1. 单集群容量限度 ：

集群下限 5000 个节点和 15 万个 Pod。同时单集群的最大节点数不是一个确定值，其受到集群部署形式和业务应用集群资源的形式的影响。

2. 多云混合应用 ：

防止被单家供应商锁定，不同集群的最新技术布局，或是出于老本等思考，企业抉择了多云架构。

3. 业务流量突发 ：

失常状况下用户应用本人的 IDC 集群提供服务，当应答突发大流量时，迅速将利用扩容到云上集群独特提供服务，需具备私有云 IaaS 接入，能够主动扩缩容计算节点，将私有云作为备用资源池。该模式个别针对无状态的服务，能够疾速弹性扩大，次要针对应用 CPU、内存较为密集的服务，如搜寻、查问、计算等类型的服务。

4. 业务高可用 ：

单集群无奈应答网络故障或者数据中心故障导致的服务的不可用。通常次要服务的集群为一个，另一个集群周期性备份。或者一个集群次要负责读写，其余备份集群只读，在主集群所在的云呈现问题时能够疾速切换到备份集群。该模式可用于数据量较大的存储服务，如部署一个高可用的 mysql 集群，一个集群负责读写，其余 2 个集群备份只读，能够主动切换主备。

5. 异地多活 ：

数据是实时同步的，多集群都能够同时读写，这种模式通常针对极其重要的数据，如全局对立的用户账号信息等。

6. 地区亲和性 ：

只管国内互联网始终在提速，然而处于带宽老本的考量，同一调用链的服务网络间隔越近越好。服务的主和谐被调部署在同一个地区内可能无效缩小带宽老本；并且分而治之的形式让应用服务本区域的业务，也能无效缓解应用服务的压力。

二、多集群摸索

2.1 社区在多集群上的摸索

以后基于 K8s 多集群我的项目如下：

1.Federation v1：

曾经被社区废除，次要起因在于 v1 的设计试图在 K8s 之上又构建一层 Federation API，间接屏蔽掉了曾经获得宽泛共识的 K8s API，这与云原生社区的倒退理念是相悖。

2.Federation v2：

曾经被社区废除，提供了一个能够将任何 K8s API type 转换成有多集群概念的 federated type 的办法，以及一个对应的控制器以便推送这些 federated 对象 (Object)。而它并不像 V1 一样关怀简单的推送策略（V1 的 Federation Scheduler），只负责把这些 Object 散发到用户当时定义的集群去。这也就意味着 Federation v2 的次要设计指标，其实是向多集群推送 RBAC，policy 等集群配置信息。

3.Karmada：

参考 Kubernetes Federation v2 外围实际，并融入了泛滥新技术，包含 Kubernetes 原生 API 反对、多层级高可用部署、多集群主动故障迁徙、多集群利用主动伸缩、多集群服务发现等，并且提供原生 Kubernetes 平滑演进门路。

4.Clusternet：

是一个兼具多集群治理和跨集群利用编排的开源云原生管控平台，解决了跨云、跨地区、跨可用区的集群治理问题。在我的项目布局阶段，就是面向未来混合云、分布式云和边缘计算等场景来设计的，反对海量集群的接入和治理、利用散发、流量治理等。

5.OCM：

OCM 是一款 Kubernetes 多集群平台开源我的项目，它能够帮忙你大大简化跨云 / 多云场景下的集群治理，无论这些集群是在云上托管，还是部署在自建数据中心，再或者是在边缘数据中心中。OCM 提供的根底模型能够帮忙咱们同时了解单集群外部的容量状况，也能够横跨多集群进行资源 / 工作负载的编排调度。与此同时，OCM 还提供了一系列弱小的扩展性或者叫做插件框架（addon-framework）来帮忙咱们集成 CNCF 生态中的其余我的项目，这些扩展性也能够帮忙咱们无侵入地针对你的特定应用场景手工扩大个性。

以上多集群我的项目次要性能为资源散发和调度，还有如多云基础设施治理 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 在联邦集群的摸索方向次要有以下四个方面：

1. 资源散发和编排
2. 弹性突发
3. 多集群调度
4. 服务治理和流量调度

本次次要分享资源散发和编排、弹性突发和多集群调度以 K8s 为外围的联邦多集群摸索。网络为外围的能力建设，次要为不同集群的网络能够通过如 Service Mesh 或者 Mesh Federation 买通，就能够实现网络流量的灵便调度和故障转移。实际上，也有很多利用通过隧道或者专线买通多个集群，进一步保障了多集群之间网络通信的可靠性。vivo 网络和服务发现次要是开源的根底上自研，能够继续关注前面分享。

三、面向利用的多集群实际

云原生技术的倒退是继续输入“事实标准的软件”，而这些事实标准中，利用的弹性、易用性和可移植性是其所解决的三大实质问题。

• 利用的弹性 ：对于云产品的客户来说等价于业务可靠性和业务摸索与翻新的敏捷性，体现的是云计算所发明的客户价值，利用弹性的另一个关注点在于疾速部署、交付、以及在云上的扩缩容能力。这就须要欠缺的利用交付链路以及利用的云原生开发框架撑持；
• 易用性 ：能更好地施展利用的弹性，在微服务软件架构成为支流的情景下，易用性须要思考通过技术手段实现对利用整体做全局性的治理，实现全局最优。这凸显了 Service Mesh 的服务能力；
• 可移植性 ：实现多集群和混合云无障碍迁徙等。

那么一个以利用为核心，围绕利用交付的多集群多集群治理具备对立的云原生利用规范定义和标准，通用的利用托管和散发核心，基于 Service Mesh 的跨云的利用治理能力，以及 K8s 原生的、面向多集群的利用交付和管理体系，将会继续一直的产生微小的价值。vivo 以后次要联合 Karmada 和 CNCF 周边我的项目来摸索以上挑战。

3.1 面向利用的多集群继续公布

3.1.1 利用公布

上图是面向利用的多集群继续公布架构，咱们次要的工作如下：

• 治理注册多个 Kubernetes 集群并接入 Karmada，Karmada 负责多个集群的资源调度编排和故障转移。
• 容器平台对立治理 K8s 资源、Karmada 策略和配置。
• CICD 平台对利用进行单元测试、平安测试、编译镜像等操作，配置利用的存储、密钥、环境变量、网络和资源等，最终对接容器平台的 API 生成 K8s 对象，对立交付。

一个利用真正的能治理起来其实很简单，如特定的场景须要原地降级和灰度公布等。为了能够提供更加灵便、高级和易用的利用公布能力，更好地满足利用公布的需要，最终抉择应用 Openkruise。比方上图有个游戏的利用 game-2408。它波及到 K8s 资源有 configmap、secret、pv、pvc、service，openkruise 的 cloneset、自研的服务发现和拜访资源、以及 Karmada 的 PropagationPolicy 和 OverridePolicy 等资源，都能达到 12 个资源配置。比方存储等资源都是按需申请和调配的，为了无效治理这些资源和关系，以后次要通过关联数据库进行治理，并买通 cicd 和容器平台的交互，记录利用公布的状态转换，实现利用的滚动、灰度等公布能力，达到可继续公布的能力。

为了不便问题定位、K8s 资源和 Karmada 资源的策略关系，以后 Karmada 策略命名标准如下：

1. 能够辨认策略属于那个 workload
2. 防止策略反复，须要退出 workload 类型
3. 策略名超过 63 个字符，须要 hash 解决
4. xxx 为非 workload 的资源名

遇到的问题总结：

1. 一个资源无奈被多个策略匹配，导致如 configmap、secret 等专用资源无奈再次下发到其它集群。
2. 多个集群之间串行公布，如公布完 A 集群能力公布 B 集群的管制。

3.1.2 Openkruise 资源解析

以后 vivo 的利用次要通过 OpenKruise 的 Cloneset(无状态) 和 AdvancedStatefulset(有状态) 控制器进行公布。Kamrada 目前只能辨认 K8s 默认的资源，其它的资源都须要开发资源解析。为了解决下面提到的问题，Karmada 引入了 Resource Interpreter Webhook，通过干涉从 ResourceTemplate-> ResourceBinding ->Work ->Resource 的这几个阶段来实现残缺的自定义资源散发能力。

（1）InterpretReplica：

该 hook 点产生在从 ResourceTemplate 到 ResourceBinding 这个过程中，针对有 replica 性能的资源对象，比方相似 Deployment 的自定义资源，实现该接口来通知 Karmada 对应资源的正本数。

（2）ReviseReplica：

该 hook 点产生在从 ResourceBinding 到 Work 这个过程中，针对有 replica 性能的资源对象，须要依照 Karmada 发送的 request 来批改对象的正本数。Karmada  会通过调度策略把每个集群须要的正本数计算好，你须要做的只是把最初计算好的值赋给你的 CR 对象。

（3）Retain：

该 hook 点产生在从 Work 到 Resource 这个过程中，针对 spec 内容会在 member 集群独自更新的状况，能够通过该 hook 告知 Karmada 保留某些字段的内容。

（4）AggregateStatus：

该 hook 点产生在从 ResourceBinding 到 ResourceTemplate 这个过程中，针对须要将 status 信息聚合到 Resource Template 的资源类型，可通过实现该接口来更新 Resource Template 的 status 信息。

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

3.2.1 弹性伸缩

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

FedHPA 流程：

1. 用户创立 HPA 资源，如指定 workload、cpu 下限、min 和 max 值。
2. FedController 开始计算 clusterA 和 clusterB 资源，在 clusterA 和 clusterB 创立 HPA，并按比例调配集群的 min 和 max。
3. 当集群 clusterA 和 clusterB 触发定义的 cpu 资源下限，clusterA 和 clusterB 开始扩容。
4. Karmada 管制立体的 clusterA 和 clusterB 的 HPA work 对象的 status 里有记录集群扩容正本状况。
5. FedHPAController 感知到 work 的变动，并获取到每个集群实在的正本数，开始更新调度资源 RB 和管制立体的 workload 正本数。保障了管制立体和 member 集群的调度和正本数统一，不会呈现反复调度和正本不统一。反之 cpu 流量上来开始缩容，计算过程一样。
6. 同时增加了资源再度平衡的能力，当集群资源变动时，FedHPAController 会计算集群总资源、节点碎片、是否可调度等状况，重新分配每个集群 HPA 的 min 和 max 值，确保在扩容时候有短缺的资源。

3.2.2 定时伸缩

定时扩缩容是指应在固定工夫点执行利用扩容来应答流量的高峰期。K8s 自身没有这个概念，这里在 Karmada 管制立体定义了 CronHpa 资源，并通过 Karmada-scheduler 对多集群对立调度。防止非联邦化集群在多个 member 集群创立多个 cronhpa。定时性能通过 go-cron 库实现。

CronHpa 流程：

1. 用户依据业务需要，创立 CronHPA。定义扩容工夫和缩容工夫。
2. 到扩容工夫点，CronHPAController 开始扩容 workload。
3. Karmada-scheduler 开始调度，依据每个集群的资源开始正当调配每个集群的正本数。
4. 到缩容工夫点，CronHPAController 开始缩容 workload。

3.2.3 手动和指定扩缩容

手动扩缩容流程：

1. 用户指定 workload，进行扩容或者缩容。
2. Kamrada-scheduler 开始调度，正当调配扩容或者缩容值到每个集群。

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

指定缩容流程：

1. 用户在 clusterA 指定 workload 上面一个 pod 进行缩容，须要在

   ScaleStrategy.PodsToDelete 指定 pod。

2. 须要在 Karmada 实现 openkurise 实现该字段的资源解析，不让它被管制立体笼罩。
3. 并在管制立体更新 workload 的正本和 pp 资源，保障正本数和调度后果统一。
4. member 集群的 openkruise 开始删除指定的 pod。

也能够尝试从 Karmada 管制立体指定删除 pod 和更改调度的后果，这样更加正当些，也不必增加 Karmada 资源解析。

3.3 对立调度

3.3.1 多集群调度

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

workload 调度流程：

1. 用户定义 workload 和策略匹配，生成 RB 资源。
2. doSchedulerBinding 开始对 RB 进行调度，通过预选和优选调度算法抉择适合的集群，以后不会进行资源计算，和 K8s 调度预选和优选不一样。

3. selecClusters 依据筛选的集群，进行正本调配。这里有 2 种模式，次要依据用户配置的策略去抉择。

   a.Static scheduler 只计算所有资源的 request，不思考调度规定。

   b.Dynamic scheudler 会在计算所有 request 的同时，也会思考一部分调度规定。

4. 最终计算出每个集群调配的正本数并更新 RB 资源，调度完结后其它控制器会依据 RB 进一步解决。

故障调度：

1. 比方当集群 clusterA 产生故障，在肯定断定条件内，会触发 Karmada-scheduler 从新调度。
2. Karmada-scheduler 会将故障集群的资源，调度到 clusrerB 和 clusterC。

3.3.2 重调度

重调度的存在次要解决利用下发到 member 集群没有真正的运行起来，导致呈现这样的状况可能是集群资源在一直的变动，利用正在 Karmada-scheduler 多集群调度的时候可能满足，但通过 member 集群二次调度时候无奈调度。

重调度流程：

1. 过滤 RB 资源，发现 RB 调度没有达到预期。
2. 对 workload 发动从新调度。
3. 进过预选、优选等流程，再次调配调度后果。
4. 最终将 workload 的所有 pod 调度起来。

3.3.3 单集群调度模拟器

目前社区单集群的调度估算器，只是简略模仿了 4 种调度算法。和理论的调度算法有很大差距，目前线上有很多自研的调度算法和不同集群须要配置不同算法，这样估算器的精确度就会降落，导致调度呈现 pod pending 的状况。能够对单集群的调度模拟器进行优化。

1. 应用 fake client 去模仿线上集群。
2. fake client 启动 k8s 默认的调度器以及自研的调度算法，批改 binding 接口。并配置到每个 member 集群。
3. podRequest 申请每个集群调度模拟器，运行实在的调度算法，并计算调度后果。

3.4 灰度上线

3.4.1  利用迁徙

对于通过非联邦化资源管理的利用，不能间接删除在创立，须要平滑迁徙到 Karmada 治理，对于用户无感知。

次要流程如下：

1. 管理员通过容器平台，将须要迁徙的利用插入迁徙白名单。
2. 用户通过 cicd 公布，容器平台会进行公布接口调用。
3. isKarmada 模块会查看迁徙名单，在白名单内将资源联邦化，接入 Karmada 治理。不在白名单内放弃原有的动态集群治理。
4. 最终实现利用的公布，用户齐全无感知。放弃 2 种治理形式并行存在。

3.4.2 利用回滚

有了利用迁徙的能力，是否就能够保障整个流程百分百没有问题，其实是无奈保障的。这就必须有利用回滚能力，晋升用户的迁徙满意度。

回滚的必要性总结：

1. 利用公布迁徙的过程中产生了未知的谬误，并且短时间无奈复原。防止阻塞利用失常公布，须要回滚。
2. 利用被 Karmada 接管后产生未知的谬误，须要防止资源联邦化后无法控制，须要回滚。

回滚流程：

1. 管理员通过容器治理平台，将须要回滚的利用从迁徙白名单删除。
2. 并对利用对应的 workload 以及关联的资源打上注解。
3. 批改 exection-controller 源码，exection-controller 发现以上注解，最终调用 update/create 时不做解决。
4. 批改 defaultInterpreter 源码，发现以上注解 ReviseReplica 不批改正本数。
5. 这样就能够阻断 Karmada 管制立体和 member 集群的分割。这里为什么没有间接从 Karmada 删除资源，次要防止删除这种高危操作以及不便前期复原后从新接入 Karmada。

3.4.3 迁徙策略

利用迁徙 Karmada 准则：

1. 先测试、再预发、最初生产
2. 重大变更，分批次灰度，依照 1:2:7 比例灰度迁徙
3. 责任人单方点检验证，并察看监控 5~10 分钟
4. 灰度后确认没有异样后持续迁徙，否则走回滚流程

四、总结

vivo 以后次要通过非联邦多集群治理，联合 CICD 实现了利用动态公布和治理，具备了利用的滚动、灰度、手动扩缩容、指定缩容和弹性扩缩容等能力。绝对于非联邦多集群局部能力有余，如跨集群对立资源管理、调度和故障转移等，在联邦集群进行局部能力的摸索和实际。同时联邦集群减少了整体架构的复杂度，集群之间的状态同步也会减少管制面的额定开销和危险。以后社区在联邦集群还处在一个摸索和不断完善的阶段，企业在应用联邦集群应联合本身需要、建设欠缺的运维保障和监控体系。对于曾经存在的非联邦化的资源须要建设迁徙和回滚能力，管制产生故障的范畴和疾速恢复能力。

参考我的项目：

1. GitHub：kubernetes-retired/federation
2. GitHub：kubernetes-retired/kubefed
3. GitHub：karmada-io/karmada
4. GitHub：clusternet/clusternet
5. GitHub：open-cluster-management-io/ocm
6. GitHub：kubernetes-sigs/cluster-api
7. GitHub：clusterpedia-io/clusterpedia
8. GitHub：submariner-io/submariner
9. GitHub：karmada-io/multi-cluster-ingress-nginx
10. GitHub：istio/istio
11. GitHub：cilium/cilium