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

企业为什么要抉择混合多云模式，其中比拟次要的一个起因就是因为平安问题，这里我列举了一些国内外的安全事件，就一个产生比拟近的事件来说，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 公布！