关于云计算:混合云下的-Kubernetes-多集群管理与应用部署

本文是上海站 Meetup 中讲师李宇依据其分享内容梳理成的文章

大家好，很快乐来到今天下午的 Meetup。我先简略做个自我介绍，我叫李宇，目前是 KubeSphere 的一名研发，次要负责多集群方向的工作，我明天带来的分享是混合云下的 Kubernetes 多集群治理与利用部署。
KubeSphere 在开始做 v3.0 之前，曾发动了一个社区用户调研，发现呼声最高的是反对多集群治理和跨云的利用部署，因而 KubeSphere 3.0 重点反对了多集群治理。

单集群下的 Kubernetes 架构

Kubernetes 外部分为 Master 和 Worker 两个角色。Master 下面有 API Server 负责 API 申请，Controller Manager 负责启动多个 controller，继续协调申明式的 API 从 spec 到 status 的转换过程，Scheduler 则负责 Pod 的调度，Etcd 负责集群数据的存储。Worker 则作为工作节点次要负责 Pod 的启动。

单集群下有许多场景是无奈满足企业需要的，次要分为以下几点。

1. 物理隔离。只管 Kubernetes 提供了 ns 级别的隔离，你能够设置每个 Namespace 各自应用的 cpu 内存，甚至能够应用 Network Policy 配置不同 Namespace 的网络连通性，企业依然须要一个更加彻底的物理隔离环境，以此防止业务之间的相互影响。
2. 混合云。混合云场景下，企业心愿能够抉择多个私有云厂商和公有云解决方案，防止受限于繁多云厂商，升高肯定老本。
3. 利用异地多活。部署业务多个正本到不同 region 集群，防止单个 region 的断电造成利用的不可用状况，实现不把鸡蛋放在同一个篮子目标。
4. 开发 / 测试 / 生产环境。为了辨别开发测试生产环境，把这些环境部署到不同的集群。
5. 可拓展性。进步集群的拓展性，冲破繁多集群的节点下限。

其实最简略的形式就是应用多个 Kubeconfig 文件来别离治理不同的集群，前端调动屡次 API 即可同时部署业务，包含其余一些现有的其余产品也是这么做的，然而 KubeSphere 还是想以一种更加 Cloud Native 的形式去治理多个集群，于是 KubeSphere 先调研了一些已有的解决方案。

总体来说分为两个方向：
第一个是偏差管制层的资源散发，比方 Kubernetes 社区的 Federation v1 和 Federation v2 , Argo CD/Flux CD (流水线中实现利用的散发)
第二个是致力于实现多集群之间的 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 的一些毛病。

1. 其引入了独自开发的 API Server，带来了额定的保护老本。
2. 在 Kubernetes 里一个 API 是通过 Group/Version/Kind 确定的，然而 Federation v1 外面对于 K8s 原生 API、GVK 固定，导致对不同版本的集群 API 兼容性很差。
3. 设计之初未思考 RBAC，无奈提供跨集群的权限管制
4. 基于 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 提供了两种形式：

• 间接连贯。这种状况要求 Host 到 Member 集群网络可达，只须要提供一个 kubeconfig 文件可间接把集群退出进来，防止了之前提到的 kubefedctl 的复杂性。

• 代理连贯。
  对于 Host 集群到 Member 集群网络不可达的状况，目前 Kubefed 还没有方法做到联邦。因而 KubeSphere 基于 chisel 开源了 Tower，实现了公有云场景下集群联邦治理，用户只须要在公有集群创立一个 agent 就能够实现集群联邦。

这里展现了 Tower 的工作流程。在 Member 集群外部起了一个 agent 当前，Member 集群会去连贯 Host 集群的 Tower Server，Server 收到这个连贯申请后会间接监听一个 Controller 事后调配好的端口，建设一个隧道，这样就能够通过这个隧道从 Host 往 Member 集群散发资源。

多集群下的多租户反对

在 KubeSphere 外面，一个租户就是一个 Workspace，并且租户 de 受权认证都是通过 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 也提供了联邦资源的监控，进步了其可观测性。

TODO

只管 KubeSphere 基于 Kubefed 简化了多集群之间的联邦，将来也仍有一些须要改良的中央。

1. 目前中心化的 Control Plane 导致资源散发只能 push，这对 Host 集群高可用有肯定要求，这块 Kubefed 社区也在踊跃开发从 Member 集群 pull 资源到 Host 集群的 feature。
2. KubeSphere 是一个十分凋谢的社区，咱们心愿有更过的社区用户退出进来，然而目前多集群的开发门槛较高，开发者须要定义一系列很多的 Types CRD，不够敌对。
3. 多集群的服务发现目前没有比拟好的解决方案，这个原本一开始社区是有做的，然而起初为了更快的发 beta 版本，就弃用了。
4. 多集群的 Pod 正本数调度，这个目前社区是有提供 RSP (Replica Scheduling Preference)，KubeSphere 预计也会在下个版本加进去。

那么，有没有既不引入中心化的 Control Plane，又可能缩小过多的 API 引入实现多集群呢。答案就是 Liqo。在介绍它之前，首先咱们介绍一下 Virtual Kubelet。

Virtual Kubelet 能够帮忙你把本人的服务伪装成一个 Kubernetes 的节点，模仿 Kubelet 退出这个集群。这样就能够程度拓展 Kubernetes 集群。

在 Liqo 外面，集群之间不存在联邦关系，左图里在 Kubefed 架构下 k2、k3 两个集群是 k1 的成员集群，资源下方须要通过一次 k1 的 push，而在左边的图外面，k2、k3 只是 k1 的一个节点，因而在部署利用的时候，齐全不须要引入任何的 API，k2、k3 看起来就是 k1 的节点，这样业务就能够无感知的被部署到不同的集群下来，极大缩小了单集群到多集群革新的复杂性。当初 Liqo 属于刚起步阶段，目前不反对两个集群以上的拓扑，在将来 KubeSphere 也会继续关注开源畛域的一些其余的多集群治理计划。

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