一、引言

上周，我参加了腾讯全球数字生态大会。

今天，就跟大家分享，我的一点收获，就是理解了多集群工具。

软件开发的同学，应该都听说过 Kubernetes 吧。它是一个容器管理工具，本身很复杂。

可想而知，同时管理多个 Kubernetes 集群的工具，一定更复杂。但是，我这次发现，多集群其实很好理解。

当时，大会有一个演讲，关于腾讯的一个新服务，跟多集群管理有关，叫做 TKE AppFabric，讲得很浅显，我一下就听懂了。

下面，我尽量用最简单的语言，解释什么是 Kubernetes，什么是多集群工具，什么是最简单的使用方法。

二、从 Docker 讲起

为了理解 Kubernetes，需要从 Docker 讲起。

2013年，Docker 诞生，创造性地将软件应用的运行环境与源代码打包在一起，做成一个容器镜像（image）。

容器镜像本身是一个二进制文件，可以直接发布。其他机器只要安装了 Docker，就能运行这个文件。它能让软件运行在一个虚拟环境（称为"容器"）里面，从而保证运行环境和开发环境一致，避免了环境配置、启动报错等等麻烦事。

更重要的是，容器镜像是一个标准化文件，不管软件使用什么语言开发，最后做成容器，都是一个格式。因此，就可以用一个工具去处理所有容器项目的发布，完全忽略开发语言的差异。

正是因为 Docker 提供了标准化、一站式的软件运行流程，才为后来通用的"容器应用管理工具"铺平了道路。

现在，Docker 已经成为软件部署的标准。不管软件是以源码发布，还是以容器镜像发布，最后都部署运行在 Docker 里面。

三、微服务架构

Docker 出现后，大大简化了软件部署，变成只需运行容器镜像。很自然地，开发者就开始考虑，能不能把单体的巨型软件，拆分成为多个组件（即多个容器）部署？

早期的企业级大型应用，通常都是一个巨大的单体软件（monolithic），包含不同功能的多个组件。哪怕只修改一个组件，也需要把整个软件重新部署一次。

现在的实践则是，把较大的功能组件拆分出来，每一个组件都是一个独立的服务，作为一个 Docker 容器单独发布和部署。

于是，单体软件就变成了多个 Docker 容器组成的软件系统，这就是现在流行的"微服务架构"（microservices）。软件包含多个微服务，每个微服务对应一个 Docker 容器。

四、容器管理工具 Kubernetes

微服务意味着，每次发布都涉及大量不同的容器，管理它们就成了一种挑战。容器管理工具就应运而生。

各种容器管理工具之中，名气最大的非 Kubernetes 莫属。

它是谷歌开发的一款开源软件，因为词首K和词尾s之间有8个字符，所以常常写成 K8s。它已经成为事实上的容器管理标准。

具体来说，它主要有以下功能。

（1）统一的硬件接口。开发者不必关注底层的硬件细节，不管底层服务器有什么差异，都被抽象成统一的操作接口。

（2）自动扩展。它可以根据软件负载情况，快速完成水平扩展。

（3）高可用。当某个容器失败时，它会自动重启或替换掉该容器，保证流量流向可用的节点。如果软件发布出现问题，还能自动回滚。

（4）其他功能。它还具有服务发现、负载均衡、资源监控等大量相关功能，同时带有庞大的插件和扩展，以及活跃的社区。

五、多集群是什么？

Kubernetes 的底层就是一组服务器，上面运行着许多容器。每个 Kubernetes 实例，就被称为一个集群（cluster）。

普通的软件应用，只要一个集群就够了。但是，出于下面提到的原因，企业级应用往往需要部署在多个集群。

多集群（multi cluster）可以在同一个机房，也可以在不同机房。实际应用中往往是后者，即分布在不同机房，这时如果集群来自不同的云服务商，或者是不同性质的云，就称为"多云"（multicloud）。

多集群的主要考虑如下。

（1）容灾。如果一个集群出问题，那么还有另一个集群，可以保证可用。

（2）隔离。集群之间可以做到非常强的物理隔离，从而实现上层用户（租户）的隔离。

（3）灵活性。多云有助于减少供应商锁定，可以根据需求选择最合适的基础设施和服务。

（4）合规性。不同地区可能有不同的监管要求，多集群可以为每个集群实施更精细的安全策略和访问控制。

六、多集群的挑战

多集群虽然有上一节的好处，但是复杂性也随之加倍，为使用者带来了许多挑战。

（1）配置和管理复杂性。所有集群需要一致的配置和部署，尽量消除差异。

（2）网络连接和延迟。如何保证不同地理位置的集群，有安全可靠的连接，同时最大限度地减少延迟。

（3）服务发现和负载均衡。某个服务如何发现不同集群中的其他服务，以及如何让不同集群负载均衡。

（4）监控。所有集群的指标和日志，最好汇集在一起，便于集中式监控。

（5）安全和访问控制。多集群的安全策略、访问控制、凭证管理都变得更加复杂，需要仔细规则和逐一设置。

七、多集群工具及其问题

为了解决上面的挑战，就诞生了专门的多集群管理工具，比如 Argo CD、Rancher Fleet、Karmada 等。

它们可以看作是开发者与 Kubernetes 之间的中间层，解决集群管理的复杂性。

问题是，要使用它们，必须先学会 Kubernetes，再去学习这些工具本身。这是巨大的学习成本，所以多集群工具不是针对应用开发者，而是针对集群管理员。

现实中，多集群是高度专业的领域，其他领域的开发者根本看不懂。开发者完成软件开发后，会把应用交给集群管理员，让后者去部署。

这对双方都很麻烦。一方面，开发者不能决定部署策略，也不了解底层资源，许多情况下可能不得不接触容器管理。另一方面，集群管理员会被迫介入应用层，一旦发生底层资源的调整，还需要通知开发者，让其参与进来保证应用的运行。

八、面向应用的多集群助手 TKE AppFabric

怎样才能让开发者更简单地使用多集群呢？

腾讯云的解决方案，就是增加一个面向应用的中间层，把多集群工具这一层隐藏，降低使用门槛，这种服务就起名为 TKE AppFabric。

它的名字中，TKE 指的是"腾讯云容器服务"（Tencent Kubernetes Engine），AppFabric 指的是把应用容器像织物一样编织在一起。

它面向应用开发者，定位就是"向上服务好应用，向下管理好集群"，可以看作是应用的多集群助手。

由于封装了多集群工具这一层，所以它没有复杂的专业术语，特别好懂，开发者能够快速理解和上手，不用关心底层资源，甚至不需要知道"集群"这个概念。

它的简单性，体现在下面几个方面。

首先，它使用开发者更容易理解的"可用区"（availability zone）。应用部署时，你只需要指定在哪几个区（比如广州1区、上海1区），也就是部署位置，就可以了。

整个过程都面向应用，跟 Kubernetes 解耦。这一方面，有利于开发者将更多精力放在业务上面，另一方面使得云服务商可以充分调配资源，提高资源利用率。同时，集群的升级和维护，上层用户也是无感的。

其次，它简化了设置，采用声明式设置，只需要写好声明文件即可，进一步降低了学习成本。

再次，它封装了 Kubernetes 跟应用运行相关的一些功能，让其更易用，各种监控指标和日志也汇集在一个地方，更容易发现。

九、多集群案例：腾讯健康

腾讯健康就架设在 TKE AppFabric 之上，我们通过它，来看看怎么使用多集群架设大型服务。

下图就是腾讯健康的后台架构。

上图中，网关（gateway）是访问入口，下面同时部署了三个可用区：zone1，zone2 和 zone3。它们部署在不同的机房。

这三个可用区是一模一样的，每个区都部署一个系统实例。每个系统实例包含三个层层依赖的应用：app1 依赖于 app2，app2 依赖 app3。这三个应用本身，每一个都是容器组（app pods）。

这样的架构有三个好处，可以保证高可用和负载均衡。

（1）容灾部署。如果一个可用区出现故障，可以切换到另一个可用区（比如 zone1 的 app2 出现故障，可以切换到 zone2 的 app2），保证可用。

（2）路由控制。自动为用户分配就近的可用区，提高访问速度。

（3）灰度发布。新功能可以先在单个可用区进行灰度验证，完成之后再全可用区发布，降低发布风险。

根据现场演讲，所有腾讯内部资源上云的业务，比如 QQ、腾讯会议、音视频业务都会部署在 TKE AppFabric 上面。今年第四季度，它就会对外试运行，明年一季度正式对外开放。

十、总结

对于采用"微服务架构"的企业级应用，如果业务比较重要，需要高可用，那么多个 Kubernetes 集群几乎是必然的选择。

如果公司有专门的团队，你可以选择自己来做多集群管理，否则可以考虑云服务商的工具。

我相信，越来越多的云服务商，以后可能会同时提供两套工具：一套是原始的多集群工具，专门供高级用户使用，另一套就是 TKE AppFabric 那样的面向应用、隐藏多集群细节的助手工具，供普通开发者使用。

对多集群或者 TKE AppFabric 感兴趣的同学，可以微信扫描下面的二维码，查看产品手册。

（完）