一、引言
上周,我参加了腾讯全球数字生态大会。
今天,就跟大家分享,我的一点收获,就是理解了多集群工具。
软件开发的同学,应该都听说过 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 感兴趣的同学,可以微信扫描下面的二维码,查看产品手册。
(完)
我就是大名鼎鼎的 说:
阮老师开新话题了但是好短
2024年9月12日 10:39 | # | 引用
无名 说:
单容器(无负载均衡)微服务部署有个问题,假如A依赖B,B依赖C,如果要重新部署B或C,则A会出错对吗?所以单容器感觉有依赖的时候微服务并没有什么优势,用了微服务就要多容器+负载均衡了,是不是这样的?
2024年9月12日 13:55 | # | 引用
东东 说:
实际生产环境的应用,不会只部署一个单容器的,必须是集群模式部署,必须保证服务不中断和高可用
2024年9月12日 16:41 | # | 引用
examango 说:
感觉这东西就是在炫技????
2024年9月12日 18:08 | # | 引用
lendo 说:
k8s,在信创上有争议
2024年9月12日 18:18 | # | 引用
打雷喽 说:
搜不到腾讯云上的AppFabric,不过AWS AppFabric倒是一搜一大把
2024年9月12日 20:54 | # | 引用
吾系心动 说:
第九节有误,单个k8s集群本身就是可以跨区的。一般来说只要区域之间IP可直连(比如深圳A,B,C可用区),那么会把他们放在一个集群里面,这样管理起来会简单很多。而IP不可直连时(比如深圳A与北京B可用区),才会考虑做多集群,而且会在顶部通过DNS来根据用户所在地区进行导流,而不是图中的Gateway。
2024年9月18日 20:22 | # | 引用
Ben 说:
面向应用的话,直接用severless会更省心力吧,比如阿里云的函数计算,亚马逊的Lambda?
如果要用集群层面的东西,公司都会有些定制化吧,开发按照自己文档会少很多坑
2024年9月27日 13:31 | # | 引用