KubeSphere 多集群管理大招：使用 QKE 管理多个 ACK 集群

多集群管理最常见的使用场景包括服务流量负载均衡、隔离开发和生产环境、解耦数据处理和数据存储、跨云备份和灾难恢复、灵活分配计算资源、跨区域服务的低延迟访问以及避免厂商锁定等。KubeSphere 旨在解决多集群和多云管理（包括上述使用场景）的难题，为用户提供统一的控制平面，将应用程序及其副本分发到位于公有云和本地环境的多个集群。KubeSphere 还拥有跨多个集群的丰富可观察性，包括集中监控、日志系统、事件和审计日志等。

本文是根据 KubeSphere 2020 年度 Meetup 上，北京红亚华宇科技有限公司的 CTO 卢兴民的分享内容整理而成。

各位社区的小伙伴，大家好。我是红亚科技的 CTO 卢兴民，今天给大家分享一下我们公司的团队在使用 KubeSphere 进行多集群管理，还有应用发布上的实践工作。

基于 KubeSphere 部署青椒课堂 —— 业务架构

先介绍一下我们应用的架构。我们独立出来的这一部分服务，主要是用来为青椒课堂的学生和老师提供虚拟化的操作环境，是一个虚拟化资源调度服务。它包含了 API server、proxy、jobrunner，还有 image registry mirror。它本身有调度容器和虚拟机的能力，而调度虚拟机是直接跟 IAAS层（比如阿里云）去做的对接。

最初我们的副本只在北京有一个集群，所以也就没有必要考虑用一个更方便的形式去部署多个集群。当时就是一个可视化的 PAAS 平台，人工操作即可。但是随着我们用户的数量变多，服务遍布全国，我们就必须做如图所示的这种多可用区的架构。

青椒课堂 region 服务部署在 KubeSphere 上，应用特点如下：

1. 我们把服务部署在多个地域，比如北京、广东、上海

2. 但是各个副本之间不需要进行通讯，只是简单的一个多副本。

3. 直接受主业务的调度，就是提供一个 API server 被主业务去调度。

4. 当业务需要变更的时候，比如增删组件，或者组件配置的变更，我们需要在多个副本里面同时进行。这个时候就我们用可视化的 PAAS 平台就会有一个问题，我们需要人工在各个地域进行手工调整。当有几个的时候我们还能接受，但当有十几个的时候，就很难接受这样的手工调整的过程。并且人工操作会有很大概率出现问题，例如组件变更在不同的可用区内没有做到同步调整，导致业务出现故障。

希望达成的目标

我们做多集群的管理，想达成的目标如下：

1. 我们希望有一个开箱即用的 KubeSphere 服务。在 KubeSphere 3.0 发布之后，我进行了很多测试，KubeSphere 提供了很好的安装方式，包括 KubeKey 这些形式，但我还是认为过于麻烦了。因为我们只需要一个可用的生产级别的控制台，从而不需要投入太多的人工去部署。

2. 我们不希望迁移原有的业务。因为我们原有的服务有一些依赖阿里云，所以我们希望Member集群都维持在原有的阿里云的集群不变。

3. 操作简单一些。在纳管 member 集群的过程中，不需要打通 VPC 等之类的操作，降低部署复杂度。

所以我们选择了 KubeSphere，满足我们所有的需求。而且在上线 QKE 3.0 之后，我们几乎可以通过点几下鼠标，在分钟级的时间内创建出来生产级别的 KubeSphere 集群、Host 集群。

使用现状

这个是我们目前的使用状况。目前我们在 KubeSphere 上接入了三套阿里云 ACK 集群，进行统一纳管。目前还有一些机器没有迁移过来，我们在逐步的进行迁移工作。

应用打包与规范定义

我们原有的应用是在一个可视化 PAAS 平台，所以我们没有使用 kubernetes 原生的这种包管理工具。

那么我们在做应用打包的时候为什么会选择 helm 呢？主要是基于以下几点。

1. helm 确实是一个应用非常广泛的 kubernetes 包管理工具。

2. 我们对 KubeSphere 3.0 中的多集群应用非常感兴趣，应用市场也是支持 helm 的。

3. 我们需要将应用的变更，应用定义的过程进行版本化。用 helm 这种打包的方式就可以很好实现。

应用部署

在应用部署上我们尝试了几个方案，最终选择了 Spinnaker 作为我们的应用发布的方案，主要是基于以下几点。

1. 制品绑定的功能非常有用，我们可以在不修改 helm 包内部配置的情况下，跟制品库形成联动，直接去对每一个组件的 image 进行选择和切换，这在发布的过程中非常方便。

2. 我们可以将多个集群的部署定义在一个流程内，增加前后依赖关系、人工确认等流程，这使我们的配置不再繁琐。

3. Spinnaker 支持将集群差异化的配置放到同一个流程里。当然 KubeSphere 多集群应用也能实现这样的功能。

如上图所示，这是我们做好了制品绑定之后达到的效果。通过修改发布流程的启动参数，每一个组件在部署的时候都可以去选择它所对需要部署的镜像版本，以及用到的 helm 版本和所要发布的集群。

上图是我们整个应用定义的过程，首先是确定应用部署所使用的 helm 包，选取部署过程中需要使用的镜像。

右上方的第二张图的 Bake 阶段可以用来做不同集群之间的配置、差异化的管理。比如说我们在生产环境加载 values-prod.yaml 配置文件，但是每一个集群之间会有一定的差异化配置，都可以在 Bake 阶段使用 values 覆盖去进行配置。

Bake 阶段相当于是 helm 包生成一组部署到 kubernetes 集群里面的 yaml 文件，然后在 deploy 阶段进行制品绑定之后，就可以将 image 字段自动进行一个替换，部署你想要的镜像版本。

以上就是分享的全部内容，欢迎一起交流。

KubeSphere 团队在招聘 DevOps/Serverless/应用管理/边缘计算/容器存储和网络等方向的人才，欢迎有兴趣的朋友给我们投递简历（点击阅读原文）！

KubeSphere 团队(青云QingCloud) 全职开源职位等你加入！^[1]

脚注