混合多云场景下的 Kubernetes 多集群管理

企业选择混合多云的驱动力

企业为什么要选择混合多云模式，其中比较主要的一个原因就是因为安全问题，这里我列举了一些国内外的安全事件，就一个发生比较近的事件来说，2021 年 3 月，欧洲云计算 OVH，位于法国的机房发生火灾，导致 350 万家网站下线，部分客户数据永久性丢失。最近国内也发生了数据泄露敏感事件，安全问题确实给企业带来麻烦，大家的解题答案惊人的一致：不能把鸡蛋放在一个篮子里，要将鸡蛋放到不同的篮子中，是驱动企业使用混合多云的根本原因。

混合多云场景下 Kubernetes 多集群应用场景

云原生确实是最近比较热门的话题之一，广义云原生本身是一种方法论，因云而生的软件、硬件、架构，充分发挥云的优势和宏利而狭义的原生技术，代表容器、服务网格、微服务、不可变基础设施和声明式API。这些云原生技术推动了混合多云的发展速度，如使用 Kubernetes，可以让企业在混合多云场景下，快速构建、扩容自己的应用。

Kubernetes 通过三个方面推动了混合架构的升级

• 屏蔽了 IaaS 的差异性，使得应用可以真正的做到“一次定义，到处部署”。
• Kubernetes 标准化，尤其声明式 API 简化了应用部署，让应用交付变得越来越统一化，支持在不同云上使用相同的手段管理编排应用。
• 服务网格，可以跨多个集群 Kubernetes，统一流量管理和服务治理，使得混合多云下客户的应用能在一个控制平面进行管理。

1.异地多活，容灾备份

图中是两个集群，一个集群部署在公有云，另外一个部署在 IDC，通过高速网络或专线打通，数据库进行同步复制，如果其中一个集群挂掉后，另外一个集群还可以正常对外提供服务。

2.业务就近访问，降低延迟

它与第一个场景类似，将每个集群分布在不同的地区部署，用户可以根据自己所在的地区，访问最近的集群获取服务，这样有效降低用户的访问延迟，为客户提供良好的用户体验。

3.不同业务、部门间的隔离
基于用多集群的方式将不同业务、或者部门隔离，当然隔离方式有很多种，比如按时间、职能、产品，区域、技术等等，将不同业务部署在不同 Kubernetes 集群中，可以从物理层面彻底隔离，比 NS 隔离更加彻底。

4.可以有效降低故障的影响范围
多集群的业务场景，可以将事故限制在单个集群，避免整体的损失。

5.避免被单一厂商锁定
多集群的应用，不仅可以有效的避免被单一厂商的锁定，还能享受不同厂商服务特色。在企业购买云服务时，将议价权利牢牢掌握在自己手中。

多集群解决方案

目前 Kubernetes 社区的多集群解决方案，总体来说分为两个方向：

• 1. 偏向控制层的资源分发，比如 Kubernetes 社区的 Federation v1 和 Federation v2 , Argo CD/Flux CD (流水线中实现应用的分发)。
• 2. 致力于实现多集群之间的 Pod 网络可达，例如 Cilium Mesh、Istio Multi-Cluster、Linkerd Service Mirroring，由于这些项目同特定的 CNI 以及服务治理组件绑定了，因此接下来我会详细介绍一下 Federation v1 和 Federation v2 两个项目。

Federation v1

上面是 Federation v1 的架构图 可以看到有额外的 API Server (基于 Kube-Apiserver 开发) 和 Controller Manager (同 Kube-Controller-Manager 类似) ，下面是被管控的集群，多集群的资源分发需要在上面集群创建，然后最终被分发到下面的各个集群去。

相关文章：
混合多云场景下的 Kubernetes 多集群管理

为者常成，行者常至