一、引言

曩者，吾参于腾讯全球数字生态之会。

今朝，当与诸君共述吾之所得，即明多集群之器。

治软件开发者，当皆闻 Kubernetes 之名。此乃容器管理之器，本甚繁复。

由此推之，兼理多 Kubernetes 集群之器，必更繁难。然吾此次察之，多集群实甚易明。

时，会有讲演，论腾讯新服，涉多集群管理，名曰 TKE AppFabric，言浅显，吾立时洞彻。

下文，吾将竭力以简言，释 Kubernetes 之为何，多集群之器何用，及其至简之用法。

二、自 Docker 而起

欲明 Kubernetes，必自 Docker 而论之Docker始。

癸巳岁，Docker 降世，创制奇术，将软件之运行境与源码并包，成容器之像（image）。

此像乃二进制之文，可径直发布。他机但装 Docker，即能运此文件。使软件行于虚拟之境（名曰"容器"），故运行境与开发境无别，避配置之扰、启动之谬诸般烦事。

尤甚者，容器之像，乃一规范之文，无论软件以何语言开之，终成容器，皆同此式。故可一器统之，以应诸容器之发布，不辨其语焉。

盖 Docker 之提供标准化、一站式之软件运行流程，故为后来通用之"容器应用管理工具"辟其途也。

今 Docker 已为软件部署之圭臬。无论软件以源码之形，抑或以容器镜像之态面世，终皆运行于 Docker 之中。

三、微服务架构

Docker兴，软件之布，大简其制，唯运镜像而已。是故，匠者思之，能否将巨制单体，析为数器（即数镜）而布之？

昔之企业级巨构，多为一统之大软件，内含诸般功能之组件。纵改其一，亦需重整全软件而部署之。

今之实践，乃将大功能组件拆解，每组件皆为独立之服务，以 Docker 容器为载体，各自发布部署。

是故也。单体软件化而为多 Docker 容器所成之系统，此即今世所尚之"微服务架构"(microservices)也。软件含众微服务，每微服务各应一Docker容器。

四、容器管理之器 Kubernetes

微服务者，每度发布，皆牵涉众容器，理之则难。故容器管理之器，应运而生焉。

诸般容器管理之器，声名最隆者非Kubernetes(克鲁斯忒斯)莫不属也。

此乃谷歌所创之开源软件，因首字K和词尾s其间有八字符，故常书为K8s。已为事实之容器管理标准。

具体而言，其功能主要有此数端。

（1）一统之硬件接口。开发者不须究底层数据之微，无论底层数据何等殊异，皆被化约为同一操作之途。

（2）自增之能其能因软件之负载，速成水平之拓展。

（3）高可用性。若某器有失，则自能重启易之，以保流注于可用之节点。倘软件发布有碍，亦能自回滚之。

（4）他功能。兼有服务之发现、负载之均衡、资源之监控等众相关之能，且附广袤之插件与延展，并有活跃之社群。

五、何谓多集群？

Kubernetes 之底，实乃众服务器，上运行多器。每 Kubernetes 之实例，即谓之集群（cluster）。

寻常之软件应用，一集群足矣。然，因下文所述之故，企业级应用，往往需布于多集群。

多集群者，可居一馆，亦可分处数馆。然其实用之境，多如后者，即散布异馆。若集群所出，非同云商，或云之质相异，则谓之"多云"（multicloud）。

多集群之要旨，略述如下。

（一）容灾。一集群若罹难，犹有他集群在，可保其用。

（二）隔离。集群间可致极强之物理隔绝，遂能成上层用户（租户）之别。

（三）灵便。多云可减供应商之缚，依所需择最宜之基设与服。

（四）合规。方域殊异，规约或有不同，众集群立，可各施精微之安策与控访。

。六、众集群之挑战

。众集群虽有利，然繁复亦倍增，于用者多生艰阻。

。（一）配置与管理之繁。众集群须致配置与布署如一，务消其异。

。（二）网络之联与迟滞。如何保异域集群之联安且稳，而迟滞至微。

。（三）服务之发现与均负。某服务如何识异集群中之他服务，及如何致众集群负之均。

。（四）监察。凡集群之指标与日志，宜聚于一处，以便集中监控。

（5）安全与访问之控。多集群之安全策略、访问控制、凭证管理，皆趋繁复，须审慎立规，逐一设之。

七、多集群之工具及其弊

为解前述之挑战，遂有专司多集群管理之工具，如 Argo CD、Rancher Fleet、Karmada 等。

此等工具，可视为开发者与 Kubernetes 间之中介，以解集群管理之繁难。

然其弊在于，欲用之，必先习 Kubernetes，复学此等工具本身。此乃巨大学习之成本，故多集群之工具非为应用开发者设，实为集群管理员设。

世中，众集群乃精专之域，他业之匠莫能解。匠成其工，则付应用于群主，使彼部署焉。

此诚双方之困也。一则，开发者不得自主其部署之策，亦不明其下资源之状，甚或须亲历容器之管理。二则，集群之吏亦被驱入应用之层，若下资源有变，仍须告诸开发者，令其参与，以保应用之运。

八、应务多群之助 TKE AppFabric

如何使开发者更易用多集群？

腾讯云之方略，即增设一面向应用之中间层，隐多集群工具之层，降其使用之阈。此服务名曰 TKE AppFabric。

其名中，TKE者，指"腾讯云容器服务"(Tencent Kubernetes Engine)；AppFabric者，谓将应用容器若织锦般交织也。

其面向应用开发者，定位即"上以善治应用，下以善御集群，可视作应用之众集群之辅。

以包藏众群之器，故无繁奥之辞，甚易明晓。开发者可速解而习之，不须忧底层数源，乃至不知"群"之谓也。

其简易之状，见于数端。

首，其以"可用区"（availability zone）示之，使开发者易解。部署应用时，惟需指明所区（如广州一区、上海一区），即部署之位，足矣。

其事皆向应用，与 Kubernetes 解离。此中，一则利开发者专精于务，二则使云商得尽调其资，以增其用。且集群之升与维，上位者亦无觉焉。

次之，其设简明，采宣言式，但撰宣言之文足矣，复降习之难。

复次，其裹 Kubernetes 与应用行相关之能，使其易用，诸监控之标与日志亦聚于一处，更易察之。

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

腾讯健康即建于 TKE AppFabric 之上，吾等循此，观其何以用多集群设大务。

下图即腾讯健康之后台架构。

上图之中，网关者，访问之入口也。其下并置三可用区：zone1，zone2，zone3。此三者，分设于异处之机房焉。

此三可用区无别，每区各置一系统实例。每系统实例含三层层相倚之应用：app1恃app2，app2恃app3。此三应用，各为容器组（app pods）。

此架构有三利，可保高可用与负载均衡。

（1）灾备之设若一可用区有故障，可迁至他可用区（如 zone1 之 app2 有故障，可迁至 zone2 之 app2），以保可用。

（2）道之御也自动为用户配近便可用之区，以增速其访。

（三）灰度发布。新功能可先于一区灰度验证，验毕则全区发布，以降风险。

据现场演讲，腾讯内部资源上云者，如 QQ、腾讯会议、音视频业务，皆将部署于 TKE AppFabric 之上。今季第四，对外试运行，明季首季则正式开放。

十、总结

凡采"微服务架构"之企业应用，若业务要紧，需高可用，则多集群 Kubernetes 几乎必择。

若公司有专司团队，可自为多集群管理；否则，可考云服务商之工具。

吾信云服务者众，后或并供二器：一者，本集群之器，专供达者；二者，如 TKE AppFabric，向应用而隐集群之细，供常人。

欲知多集群或 TKE AppFabric 之友，可微信扫下方码，览产品之册。

（竟）