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

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

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

云服务已经成为水电一样的基础设施，对于用户来说，一旦出现安全事件，将造成严重损失。

• 2018 年 3 月，Facebook 数据泄露丑闻爆发，股价大跌 7%，市值蒸发 360 多亿美元。
• 2020 年 2 月，万豪酒店 520 万客人信息被泄露。
• 2020 年 2 月，微盟的“删库”事件，影响业务 136 小时，拖累微盟业绩，赔付总额达到 1.16 亿元，微盟股价累计跌幅超 20%。
• 2020 年 5 月，泰国最大的移动运营商泄露 83 亿条用户数据记录。

对于云厂商来说，一旦出现问题，将影响到千万用户。

• 2019 年 2 月，阿里云代码托管平台的项目权限设置仅仅因为有歧义，用户在上传代码时，可设置 private、internal 和 public。很多开发者以为选择“internal”，就是安全的，于是选了此选项。因此包含万科、咪咕音乐、51 信用卡等 40 家企业在内的 200 多个项目代码被泄露。
• 2020 年 5 月，有黑客声称获取微软公司存储在 Github 私人仓库中的大量源代码片段，源码大小高达 63.2GB，涉及 Azure、Office 和 Windows。
• 2021 年 3 月，欧洲云计算巨头 OVH 位于法国斯特拉斯堡的机房发生严重火灾，导致 350 万家网站下线，部分客户数据丢失无法恢复。

今年 2 月，Hashicorp 对 300,000 名 HashiCorp 邮件订阅用户进行了关于“云战略现状”的调查，最终收到了来自世界各地技术从业人员和技术决策者的 3,205 份回复。约 3/4 的调查受访者已经采用了多云架构（多个云，公有云或私有云）。预计两年后，几乎 90% 的企业都会采用多云架构。

企业选择混合多云架构的原因：

1. 基于自身安全的因素考虑
2. 监管部门的要求
3. 出于享受不同云厂商的服务特性
4. 出于避免单一厂商绑定，优化成本原因
5. 出于未来技术革新驱动力
6. 企业自身的业务要求等因素

混合多云场景下 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 类似) ，下面是被管控的集群，多集群的资源分发需要在上面集群创建，然后最终被分发到下面的各个集群去。

上图是一个在 Federation v1 里面创建 Replicaset 的示例，与普通的 Replicaset 区别就是多了一些 Annotation，里面主要存了一些分发资源的逻辑，从中我们也能看到 v1 的一些缺点。

• 其引入了单独开发的 API Server，带来了额外的维护成本。
• 在 Kubernetes 里一个 API 是通过 Group/Version/Kind 确定的，但是 Federation v1 里面对于 K8s 原生 API、GVK 固定，导致对不同版本的集群 API 兼容性很差。
• 设计之初未考虑 RBAC，无法提供跨集群的权限控制。
• 基于 Annotation 的资源分发让整个 API 过于臃肿，不够优雅，是最被诟病的一点。

Federation v2

正是由于 v1 的这些缺点，Kubernetes 社区逐渐弃用了 v1 的设计，吸取了 v1 的一些教训，推出了 v2 也就是 Kubefed 这个项目。Kubefed 最大的特点就是基于 CRD 和 Controller 的方式替换掉了 v1 基于 Annotation 分发资源的方案，没有侵入原生的 K8s API，也没有引入额外的 API Server。

上图是 v2 的架构图，可以看到一个 CRD 资源主要由 Template、Override、Placement 三部分组成，通过结合 Type Configuration，可以支持多个版本的 API，大大提高了集群之间的版本兼容性，并且支持了所有资源的 Federation，包括 CRD 本身。同时 Kubefed 在设计之初也考虑到了多集群的服务发现、调度等。

下面是一个联邦资源的示例，Deployment 在 Kubefed 中对应 FederatedDeployment，其中 spec 里面的 template 就是原来的 Deployment 资源，placement 表示联邦资源需要被下放到哪几个集群去， override 可以通过不同的集群配置不同集群的字段，例如 deployment 的镜像的 tag 各个集群的副本数等。

当然 Kubefed 也不是银弹，也有其一定的局限性。从前面可以看到，其 API 定义复杂，容易出错，也只能使用 kubefedctl 加入和解绑集群，没有提供单独的 SDK。再就是它要求控制层集群到管控集群必须网络可达，单集群到多集群需要改造 API，旧版本也不支持联邦资源的状态收集。

KubeShere On Kubefed

接下来我们看看 KubeSphere 基于 Kubefed 如何实现并简化了多集群管理。

图片里面定义了两个概念，Host 集群指的是装了 Kubefed 的集群，属于 Control Plane，Member 集群指的是被管控集群，Host 集群与 Member 集群之间属于联邦关系。

在图片这里用户可以统一管理多个集群，KubeSphere 单独定义了一个 Cluster Object，拓展了 Kubefed 里面的 Cluster 对象，包含了 region zone provider 等信息。

在导入集群的时候 KubeSphere 提供了两种方式：

1、直接连接

这种情况要求 Host 到 Member 集群网络可达，只需要提供一个 kubeconfig 文件可直接把集群加入进来，避免了之前提到的 kubefedctl 的复杂性 。

2、代理连接

对于 Host 集群到 Member 集群网络不可达的情况，目前 Kubefed 还没有办法做到联邦。因此 KubeSphere 基于 chisel 开源了 Tower，实现了私有云场景下集群联邦管理，用户只需要在私有集群创建一个 agent 就可以实现集群联邦。

这里展示了 Tower 的工作流程。在 Member 集群内部起了一个 agent 以后，Member 集群会去连接 Host 集群的 Tower Server，Server 收到这个连接请求后会直接监听一个 Controller 预先分配好的端口，建立一个隧道，这样就可以通过这个隧道从 Host 往 Member 集群分发资源。

多集群下的多租户支持

在 KubeSphere 里面，一个租户就是一个 Workspace，并且租户的授权认证都是通过 CRD 来实现的。为了减少 Kubefed 对 Control Plane 的依赖，KubeSphere 把这些 CRD 通过联邦层下放，在 Host 集群收到 API 请求后直接转发到 Member 集群，这样假如 Host 集群挂了，原来的租户信息在 Member 集群仍然存在，用户依然可以登陆 Member 集群的 Console 来部署业务。

多集群下的应用部署

Kubefed 的 API 前面我们也看到过，手动去定义是十分复杂并且容易出错，因此 KubeSphere 在部署应用的时候，可以直接选择需要部署的集群名称以及各自集群的副本数，也可以在差异化配置里面配置不同集群的镜像地址以及环境变量，例如集群 A 位于国内，拉不到 gcr.io 的镜像，就可以配成 DockerHub 的。

联邦资源的状态收集

对于联邦资源的状态收集，前面我们提到 Kubefed 之前是没有实现的。因此 KubeSphere 自研了联邦资源的状态收集，在例如创建 Pod 失败的场景下可以很方便的去排查对应的 event 信息，另外 KubeSphere 也提供了联邦资源的监控，提高了其可观测性。

应用实践

接下是分享一个案例，红亚科技，成立于 2012 年，是一家聚焦于IT教育服务的创新型科技公司，目前为 600+ 高校提供服务，其产品包括，信息技术实训平台、大数据竞赛平台、网络安全类竞赛平台、青椒课堂-教学辅助平台。

以青椒课堂为例，它提供了 IT 课堂的辅助教学服务，教师可以共享桌面，分享课件

一键部署课堂测试环境，远程操作指导，还可以通过标准备课库进行 IT 课程备课等。

平台主要是提升教学效率，解决了 IT 教学中、师生交互、IT 环境部署的问题

目前青椒课堂业务以容器方式，部署在多个云平台上。

基于客户当时情况，对容器平台有如下要求，最终选择了青云 KubeSphere、阿里 ACK 作为业务容器平台，客户选择平台的要求有：

1. 不被某个云服务商所绑定
2. 开源解决方案
3. 可以接受能力范围内的商业化订阅（服务支持付费）
4. 部署难度低
5. 统一认证
6. 操作简便

Host 集群使用 KubeSphere (QKE) 部署在青云QingCloud 公有云，作为多集群的集中控制管理平面，Member 集群有：青云 QKE 集群、阿里云 ACK 集群、自建 K8s 集群，作为 M 集群接入。Host 与 Member 使用 Tower 代理连接，实现多集群网络互通，满足应用跨多云和多集群的分发部署。

可以看到业务架构，主站业务的后端，已部署在多云、多个集群，根据业务需要，可以随时再调用云平台的云主机、容器资源。

用户还根据自己情况，为社区贡献了 Kubesphere IDaaS 插件，用户公司规模不大，没有域控，用户结合钉钉认证源，引入 IDaaS 的作为 Oauth provider，为 Kubesphere 整个集群进行统一授权和认证服务。目前客户已经贡献开源代码，有需要的朋友也可以去社区下载。

作者

孙天易 青云科技互联网部解决方案架构师

本文由博客一文多发平台 OpenWrite 发布！