白话多集群:工具和应用助手

白话多集群:工具和应用助手

阮一峰的网络日志

一、引言

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

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

软件开发的同学,应该都听说过 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 感兴趣的同学,可以微信扫描下面的二维码,查看产品手册。

(完)

文档信息
  • 版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证
  • 发表日期: 2024年9月11日


Generated by RSStT. The copyright belongs to the original author.

Source

Report Page