云计算的竞争旷日持久，表面看来格局初定，内里却在酝酿巨变。

具有先发优势的玩家，好不容易取得了看似不可撼动的地位，不曾想到有朝一日会中途被拉到同一起跑线，更换新的“CloudOS”重新出发。这个局面恐怕连 Kubernetes 早期创始人都会觉得不可思议。他当初只是想改变现状，在亚马逊的主导地位下，让谷歌取得一战之力。

2014 年，谷歌开源了 Kubernetes，红帽、腾讯、阿里、华为等国内外一众厂商开始力出一处，共同推进 Kubernetes 的采用。2017 年底，就连亚马逊也推出了 Kubernetes 产品，这也是 Kubernetes 成为标准化技术的最大信号之一。

(资料图)

这最终改变了整个云计算。

大家都开始基于 Kubernetes 技术生态去构建公有云产品，基于统一的标准以避免“深度绑定”，但这也让云原生行业严重同质化，因为各个云厂商所提供的功能和服务并没有太大的不同。对一些厂商来说，那些当年引以为豪的自研技术突破，那些树立在公司门口的纪念碑，那些专有性产品优势，都被抹平，这是一件非常残酷的事情。

同时这又是一些公有云厂商重塑格局的机会。锚定 Kubernetes 进行云原生改造，相当于给公有云更换“技术底座”，并由此构建出一些新的竞争力，从而赢取更多用户。

这场技术改造，难点在哪里?

对于腾讯来说，这不仅仅是一次技术“改造”，还兼带着腾讯全体系“自研业务上云”的战略任务。

在谷歌 GKE 之后，腾讯云于 2017 年推出了 TKE。但腾讯云对外服务时，还是会面临客户的质疑：“为什么腾讯自己的业务没有使用腾讯公有云，是不是不敢用?”

腾讯这次“云原生改造 + 上云”的价值就藏在客户的拷问中。腾讯在这二十年里，发展出了包括社交、音视频、游戏在内的多种业务，每种业务又都拥有海量的用户。全面上云腾讯不是第一家，但腾讯是拥有最复杂的业务场景的一家，在这个过程中，需要结合业务制定各种各样的技术方案，来满足不同的业务诉求。可以理解为，每个业务的痛点都有局部最优解，而全面上云，则是在云上寻求通用最优解。如果这些痛点都能解决，那这样的云服务是能有信心服务好客户的。

要运行这么多业务，云原生底座也不能有短板，必须承载得了微信、QQ、音视频、游戏等自研业务所有需求和核心能力，并最终将这些业务的技术积累和技术优势反向复制到到公有云上，服务于外部用户。

除此之外，云原生改造还对组织能力提出了考验。

在移动互联网时代，腾讯发展出了自己的技术哲学：每个业务都有自己的技术团队，每个团队都要打胜仗，这就要求“小、快、灵”，要有闭环。在自研业务上云之前，腾讯的每一个业务都有自己完整的技术栈，内部业务在一定程度上形成了“部门墙”效应。并且因为技术栈不同，员工从一个业务转岗到另一个业务，需要重新学习一遍技术，这跟换公司没什么区别。

根据财报数据，腾讯员工已超十万人，其中超过 7 成是技术人员，这是一次集体向云的迁移，就像一次“搬家”，但又不仅仅是将行李打包那么简单，它是将具有一二十年历史的不同特色的多个“大建筑”，制定“平移”方案迁移到新环境中继续安然运行，难度可谓前所未有的高。考虑到花费的时间、涉及到的人员规模、技术深度，这个项目可能是在世界范围内也很难找到的超级“软件工程”实践。这样的改造，过程中既有高层的推进、动员，也有执行层的博弈、妥协，最终实现了用一个点调动全局，让全公司的技术团队得到了一次很好的穿透对齐，让分散的技术能力得以统一。

有人说，评估腾讯云水平如何，应该参看自研业务上云后的整体水平和运转情况。

去年，腾讯自研业务初步完成了全部的云原生技术改造，腾讯云将所有的底层资源合并到一起进行统一管理和调度，自研业务上云规模突破 5000 万核，TKE 的在离线业务混部能力使服务器资源利用率从 30%提升至 65%，远远高于改造之前。2020年，线上会议需求爆发，腾讯云组织了几十号人，花了8天紧急扩容100万核，创下了中国云计算史上的一个记录。而全部上云之后，放到现在这个阶段，利用一键扩缩容，腾讯会议再要去扩容 100 万核，那就是几十分钟的事情。

所以，这次云原生改造的好处显而易见：对外，在垂直场景沉淀下来的技术能力，让腾讯云原生获得了差异化的产品能力，能真正解决用户在各种场景下的业务痛点;对内，让腾讯在云端整体的资源利用率有了一个大幅提升，这本身就是巨大的降本增效。

然而，这个过程却是经过了千辛万苦。

“像下一盘棋”

2018 年，云原生行业发展趋势初定。

随着云原生技术的兴起，腾讯内部几万研发人员的技术焦虑逐渐加深。早期腾讯积累了大量的技术架构理念，技术人员有非常强烈的自豪感，但是越是成功的组织惯性就越大，腾讯内部很多技术理念和流程还停留在上一个时代。据称，那时候腾讯内部讨论平台“乐问”上充满了技术人员的吐槽和争议。

除了“部门墙”的存在，每个业务部门为了应对突发的流量，在升级服务器资源时会留出资源缓冲区，当所有的缓冲区叠加在一起，就形成了大量的闲置资源浪费。所以，无论是从技术还是资源的角度来看，上云并进行统一的调度在当时已经是不得不做的事情。

2018 年底腾讯开了一次高层决策会议，决定将公司内部所有平台合到一起推行 K8s，开始进行彻底的技术更新换代。

这个事情一开始由邹辉领导的 TKE 团队牵头。TKE 团队主要由一批资深技术人员构成，成员基本都在 30 岁以上，资历以 10 级、11 级为主，团队对成员的技术能力和业务理解能力要求很高。

决策已定，但是在执行过程中，尤其是 TKE 团队，前半年时间并不是真正的去做技术工作，而是跟腾讯内部几个事业群的平台技术团队去聊需求聊具体的改造方案，他们发现还是存在很大的技术阻力。

腾讯云事业部门在 2016 年下半年的时候就启动基于 K8s 的 TKE 项目，但腾讯内部不同 BG 存在不同的路线，有的基于 Docker，有的基于 Mesos。现在要将所有东西都统一到标准的公有云 TKE 上去，其实内部技术团队难免会心生疑惑：你们是不是要过来抢我们的活?

为了减轻这些问题带来的阻力，当时腾讯没有采取调整团队人员和效仿建立技术中台的方式，而是制定了开源协同技术战略，把公司内部所有做相似事情的团队整合在一起，采取类似于外部开源运作的方式协同工作。这样既解决了技术浪费的问题，又可以去中心化，保持快速响应，还能更好地满足业务需求。腾讯内部把这种模式称为 OTeam。OTeam 挂在公司技术委员会下面。由这七八个平台组成的 K8s OTeam 就是一个典型的例子，它是腾讯首批三个开源协同项目之一。

在解决了技术团队的顾虑之后，腾讯从高层开始推进，说服自研业务团队上云，同时打通职级晋升体系，通过设置公司级的专项大奖、普及云原生知识、改造进度榜单晾晒等，从多个方面入手提高大家积极性，依照三年规划，有步骤地进行云原生改造和上云。

如何用好开源技术?

其实在上云决策制定之前，腾讯云已经花了两三年时间做了一个 TKE“原型”，也踩过了不少坑。

K8s 本身只是一个主要做容器编排调度的开源项目，TKE 底层是基于标准的 K8s，再在上面进行产品化，将 K8s 和网络能力、存储能力、日志监控等能力对应的网络产品、计算产品、日志产品、监控产品对接整合，给用户提供一个开箱即用的 K8s 产品，所以 TKE 对接了腾讯底层的各种 IaaS 产品能力。

2016 年腾讯开始做 TKE 的时候，国内都还没上 K8s 服务，业界比较好的产品设计也就是谷歌的 GKE，一切都是摸索着来。最开始，TKE 团队试图在云上提供一站式的 K8s 服务，将 K8s 的概念进行了一些简化，希望通过帮用户降低使用 K8s 的成本、让用户愿意直接接入 K8s，但最终发现这条路线是错的。

他们发现 K8s 不是直接面向终端用户的，而是面向一个企业内的 Infra 平台团队的。应该由 Infra 团队基于 K8s 构建自己的 PaaS 平台，提供给公司使用。“它是个 Kernel，是云的操作系统的内核、不是 PaaS。”于 2016 年加入 TKE 团队，一直负责 K8s 产品化相关工作的于广游表示。“我们没有意识到这样一个核心设计的本质。最开始，我们对它的理解有偏差，所以我们犯了一个错误，走了一些弯路。早期的时候为了面向业务有一些改动，意识到错误后，在 17 年底、18 年初的时候就纠正了。后来才变成了我们现在 TKE 的形态，我们也因此做了一次产品改名，从 CCS 改名为 TKE(Tencent Kubernetes Engine)。”

到了 2018 年，腾讯启动开源协同之后，因为这七八个不同的容器平台团队，各自都有各自的优势，如果要融成一个标准 K8s 技术，该怎么做?TKE 要么选择都不接收、全部“作废”重来，要么选择将所有的历史包袱都背起来。K8s OTeam 在一起讨论之后，选择了后者。

这也是为了上云而做出的妥协。整个公司“像下一盘棋”，下棋是核心矛盾，往 K8s 里贡献不好维护的代码是当时的次要矛盾。据邹辉和于广游回忆，当时很快每一个团队都用上了 K8s，大家也都更加深刻地理解 K8s 了，理解到往 K8s 里面去改太多的逻辑，不是最优的方式。有了这个共识之后，K8s OTeam 团队在不更改 K8s 主线代码情况下，差不多用了一年时间，真的就把七八个平台所有的功能、核心技术特长全部融入到了 TKE 容器平台上。

大家在 K8s 基础上去添加功能，且无需向用户暴露 K8s 的基本概念，那么“零 K8s 基础”的用户也能快速部署应用并管理其监控、日志、服务注册在内的整个生命周期。后来腾讯创建了一套应用模型 Tencent Application Definition(简称TAD)，直接使用应用管理平台，用户不需要去感知 K8s 细节，极大地降低了容器使用门槛。同时也引入了插件机制，复用了 K8s 的框架，可以像写 K8s 插件一样写 TKE 插件，方便第三方开发。

腾讯云原生底座的“养成”计划

相比公有云外部客户的业务，腾讯自研业务的体量更大，技术积累更深厚，测试标准也更全面和严苛，业务也千差万别。

一开始，K8s 很多能力不支持，业务很难平滑切换。在 2019 年之前，大部分业务还是基于虚拟机的方式去上云，因为自己的 IDC 物理机切到云上的虚拟机之后，这个过程业务基本上没有感知，整个架构和代码不需要任何的改造。但是业务上虚拟机违背了上云本质诉求，即希望利用云原生的快速弹性伸缩能力，和统一资源池的其他一些能力去提升各个业务团队的研发效能，所以最终 TKE 团队还是需要帮助业务从虚拟机切到容器化，并提供相应的产品能力。

TKE 平台在初期选择的更多还是一些无状态的业务，先让这些无状态的业务能够快速搬到云上完成改造。团队选择了一些平台的核心能力去解决业务痛点，比如说“发布”的问题。

在公有云场景下大家使用的是 K8s 基本的发布能力，比如基于滚动的发布。滚动发布过程可控性很差，遇到了问题后回滚，整个发布就会中断。腾讯自研业务需要满足灰度发布的要求，灰度发布对业务来说也是非常关键的一项能力。为了保证服务的质量，业务团队要求能够非常精准地控制发布频率、节奏和容错，做到发布过程一切尽在掌控之中。针对这样的需求，TKE 在自定义工作负载基础之上发布了一套灰度发布策略，业务可以指定要发布的 Pod，可以按照一定的百分比进行发布，也可以设置升级失败的比例来实现暂停或回滚。

同时 TKE 也给业务提供了一些虚拟机提供不了的能力，比如动态路由能力，在容器销毁时，平台会将对应路由去掉，在容器起来后，平台会自动将容器加到路由中。使用虚拟机，业务需要自己去配置，使用容器之后，就不需要去管理业务的路由了，通过 K8s Operater 的机制已经实现自动化。如此一来，大家开始初步感知到容器带来的效率价值。

另外一个好处则是弹性伸缩和健康感知。之前使用虚拟机部署业务时，需要用户先购买虚拟机，再在虚拟机里去部署业务的包，再确认业务进程健康拉起运行，最后对路由进行管理......这个流程在接入容器之后可以大幅简化，通过配置自动扩缩容的能力，或者手动触发，修改副本数后，后面所有的流程都是自动化的，可以做到秒级创建一批 Pod、自动感知实例健康状态并添加到服务路由里去，业务扩容非常丝滑。

还有就是成本上的优势，尤其是这几年，所有业务成本压力都比较大。容器在的优势是按量计费，Pod 销毁了就不收费了，计费粒度是秒级的，但虚拟机不一样，它的生命周期更重一些，弹性能力也比容器差，计费粒度也更粗。

此外，腾讯垂直业务场景也会给容器平台提出不一样的需求，为了满足这些需求，TKE 反之也给自己带来了差异化能力，这些最终都转变为了腾讯云原生产品的竞争力。

从垂直场景走出来的通用产品竞争力

从 2020 年下半年开始，腾讯游戏共有十多款产品陆续推动云原生改造，转向微服务架构。游戏是腾讯所有业务里软件结构比较特殊的一个，游戏服务的镜像一般比较大，有的甚至达到十几 GB。而我们每启动或更新一个容器，就需要将对应的应用程序从远端拉到本地的机器上启动，这么大的镜像，在部署的时候，并发对网络要求很高，源端就成了一个瓶颈。

为了解决这个问题，Oteam 团队在 会议上讨论了很多次，商量出了一套“镜像分发系统”的解决方法，类似 P2P 下载网状结构，避免源端成为瓶颈点。据腾讯游戏介绍：“云原生架构里基于容器的快速扩缩容，是以分钟级、秒级来实现的，以前我们只能以十分钟为单位。”

提高镜像分发的效率，不仅仅是有益于游戏场景。在一些 AI 训练场景中，镜像甚至更大，几十 GB 也不少见，如果是需要发布成千上万个 Pod，那就需要几十分钟，甚至更长时间，所以现在这种解决方案同样也可以适用于大规模训练场景。

而在腾讯会议以及其他社交场景中，也有一些特殊要求，这种服务往往含有大量的会话信息，很多是长连接，有些业务还会大量使用共享内存，这些都属于有状态的服务。

无状态的容器扩缩容相对简单，但有状态的服务要去享受容器化的灰度发布、弹性伸缩能力，难度很大，需要对业务架构进行大量改造。因为业务不可能在短时间内做存算分离，把存储层下沉、上层逻辑层做成一个无状态的服务。所以容器就必须扛起这个责任，基于业务的这些特殊需求，在容器层适配有状态服务。

在有状态的服务中，如果在升级过程中对应容器的中断时间达到秒级，用户通话就会出现延迟和卡顿，所以在升级过程中就要保证 Pod 容器的中断时间控制在一秒以内。TKE 团队实现了一种自定义工作负载，将新版本业务镜像提前下载到 Pod 里，通过文件锁和容器状态探测机制来控制老版本和新版本之间的快速切换，将升级的中断时间控制在毫秒级别。

另一个不得不提的是原地升级的能力，比如说容器扩容的时候，不是通过销毁重建的方法扩容，而是通过原地无感知的提升扩容。比如一般公有云对 4 核 8G 的容器进行扩容，会将其销毁重新创一个 8 核 16G 的，这种对业务是有感知的。TKE 实现了更快速的原地升配，可以将 4 核 8G 的容器原地变成 8 核 16G，但业务对此是无感的，除此之外，还支持分批原地更新 Probe、Image 等能力。

另外，这几年腾讯会议经常遇到用户人数突然暴增的情况，比如每年 9 月 1 号秋季开学的时候，腾讯会议的用户量就会涨好几倍。腾讯会议应用程序内部有大大小小几百个模块，一个应用下面可能就包含几十个模块，运维人员需要做大量的紧急扩充容，手动完成一次对应用的扩缩容，针对这几十个模块进行操作，可能要投入很多的人力，需要很长的时间。

为了减轻运维负担，TKE 团队实现了基于 PCU，即同时最大在线人数，这么一个指标去做一键扩缩容的功能。比如说现在腾讯会议在第一天的同时最大在线人数 PCU 是一千万人，以此预测，第二天可能就是两千万人，那意味着腾讯会议的上下游整个链路基本上要扩容一倍。之前运维要去做这个事情，得去找整个腾讯会议几万个 Workload，然后对每个 Workload 将副本数扩一倍。为了提升这里的效率，腾讯自研了云原生全局一键扩缩容的产品能力，将整个腾讯会议关联的这些 Workload 构建成一个或者若干个业务拓扑，同一个业务拓扑内的 Workloads 支持等比例的一键扩缩容。

“我记得在早期的时候，腾讯会议这几百个模块，扩容几十万核可能要花个近半天时间，但我们把这个能力实现后，当大家再面对这种扩缩容场景时，20 分钟左右就能完成这几百个模块的共计几十万核的扩缩容。”

这种基于业务拓扑的全局扩缩容能力其实是一种普适性的大规模业务诉求，很多业务做活动都会基于一个北极星指标来进行容量评估。针对这个通用的需求，TKE 团队将之提炼成一个通用的产品能力，在 TKE 平台上形成了一个全局的(跨地域、跨集群)、基于业务拓扑的一键扩缩容的产品功能。

通过上面这些一个个的贴近真实业务的“小细节”，我们可以看出腾讯做云原生的思路是希望让用户的付出和痛苦最小、收益最大，尽量减少业务架构的改造，减少运维的压力。而且这些动态路由、无感升级等功能，王涛表示不仅仅是内部自研业务需要，“我发现很多外部客户平时都有类似的这种需求，他们也急需要这样的一些产品能力，这也推动着我们将这些能力从内部推到公有云上去，提供给外部客户。所以，我们在腾讯自研业务上打磨的这些能力也变成了腾讯云产品的一个优势。”

深水区的那些痛

腾讯花了一年半的时间，将无状态业务搬到了云原生平台，几乎把能踩的坑都踩了一遍，为后续其他业务上云铺平了道路。这也证明了上云是可行的，给了业务团队更大的信心，后面就有更多业务滚雪球式地自发接入了。到了 2020 年底，上云的自研业务已经达到了三四百万核心的规模，平台也运行得非常稳定，所以 TKE 团队开始通过提升资源利用率、降低成本，来证明云原生确实能够给业务和公司带来很多实实在在的好处。

经过 2021 年整整一年时间，通过一系列的技术手段，团队把一些混部集群的利用率提升到了 65%。

同时在一些业务层面，一些有状态的业务，比如说像 Redis 数据库、中间件、一些大数据的套件，也做了原生改造，逐步搬到了整个云原生平台上来，腾讯内部数据库团队进一步开发了“云巢”云原生有状态服务平台。这个阶段差不多也用了一年时间，最终到 2022 年，也就是到去年为止，整个腾讯内部的资源业务基本上完成了上云，整体资源达到了 5000 万核，3 年累计节省 30 亿。腾讯云包含了混部解决方案的开源项目 Crane 也经过认证，成为 FinOps 全球首个认证降本增效开源方案。

在这个过程中，TKE 团队在调度层面做了大量的工作。

在统一资源池中，资源分散在不同的 K8s 集群里，不同 K8s 集群的资源利用率参差不齐;资源需要在不同 K8s 集群之间流转，将闲置机器腾挪到繁忙的集群中，让每个集群的资源率都非常高，这个工作是特别困难的。

最开始，TKE 团队尝试优化每一个集群的资源利用率，同时通过在离线混部，把每一个集群中的额外的资源抽离到另外的算力平台中，进行统一的调度。这虽然缓解了很多问题，但随着利用率越来越高，干扰的问题还是会存在。为了解决这个问题，TKE 团队引入了新的统一调度方案，让 K8s 不再负责调度，只负责 Pod 的管理，真正去分配资源的时候，是将请求给到了 Serverless 调度器进行统一调度，解决资源使用不均的问题。

同时，因为 K8s 自带的原生 HPA 控制器，在这种大规模场景下，扩缩容会有非常大的性能问题，比如在业务流量的洪峰来临时来不及扩容，或流量出现抖动。所以腾讯将原来的控制器从 K8s 里剥离出来，单独部署，这样就可以进行单独的一些管理，如高可用、容灾等，同时对控制器里的内部实现逻辑做一些性能优化，来满足这种大规模场景下业务需要的秒级的弹性扩缩容的能力。

沉淀多集群管理能力

前两三年云原生行业都在“卷”单集群规模，通过优化 ETCD、API Server、Controller 调度器的性能，将单集群的节点规模做大，达到上万节点。但最后瓶颈还是很明显，做到 5K 个节点集群跟一万节点的集群，本质上没有带来很大的业务价值，反而一旦单集群出现故障，爆炸半径会很大。

所以，在腾讯看来，一味地去突破单集群性能不是一个正确的技术路线。

最近整个社区，包括腾讯主要投入做多集群的管理。单集群做得更小，比如说两千个节点，甚至几百个节点就行;但是让更多的集群组合在一起，通过多集群的调度管理，让它看起来像一个集群，通过这种方式去扩展整个底层资源池的规模。

TKE 沉淀了各种多集群管理的能力，让上层的这种多集群管理能够去统一调度管理跨分区、跨地域的多集群资源。在此基础上，再重点解决了从面向集群到面向应用的调度编排问题。

这在部署全球化的业务时非常有帮助。原生 K8s 是面向集群的一套编排调度系统，用户感知的是集群里面的 K8s 对象，没有提供基于可用区容量感知调度、副本分配策略决策这些调度能力。比如一个业务全网有一万个工作负载、五万个 Pod，分布在全球十七个地域，共八十多个集群。如果要对这个业务做一次全网变更，按照以前面向集群的方式效率非常低。

所以腾讯云原生团队抽象出了面向应用的能力，对跨集群应用的统一变更，提供了一个应用管理平台，用统一的看板跟踪发布是否正常。业务部署后还要能从视图看到部署的容灾是不是合理的，所以要有多地域的容灾检测。平台也可以根据用户定义好容灾部署策略进行巡检，出了异常可以自动告警。在面向全球化上，用户还可以利用全局一键扩缩容能力，对海外和国内的多集群进行等比例扩缩容。所有这些多集群编排能力都是基于腾讯云的 Clusternet 开源项目来建设。

进一步提升资源利用率，难度也不断加大

在过去三年多，腾讯统一了资源池，能够在一个大的资源池中调度虚拟机、容器和函数，最大化地利用物理机的资源。业界很少有这么大规模的资源池，当规模足够大，底层的环境足够复杂时，总会遇到一些别人遇不到的真实问题。

在不断提升资源利用率时，你会发现，这其中大部分的时间都必须跟内核打交道。

当利用率提升了之后，整个节点里面的内核资源抢占的问题会越来越严重。同一个节点上面部署了不同的业务，甚至上十个业务，这些业务都在一个节点上，利用率高的时候会出现网络带宽、内核锁等各种各样的问题。每次遇到问题的时候，TKE 团队都需要和内核团队一起去分析，经常需要内核团队经常提供热升级补丁，或者在下一个升级版本中去做优化;然后为了减少“抢占”，也需要通过内核优化资源隔离能力;还需要完善内核资源的监控力度。比如说内存的分配时间，CPU 在队列里面的等待时间，这些很详细的内核稳定性指标，会由内核暴露出来，给到容器。容器结合这些内核的稳定性指标再去做调度决策，以提升整个节点的稳定性。

在大规模资源池里追求极高利用率的场景下，还需要考虑几十万个节点的内核版本的管理，也就是说一定要把这么多节点的内核版本给收敛起来，不然太过零散，这些内核问题永远都处理不完，一定要有一套自动化收敛节点内核版本的机制。所以 TKE 团队做了一个基于业务无感知调度腾挪能力，去自动化升级节点内核的系统，可以在业务低峰期的时候，比如每天凌晨的时候，自动化地分批次挑选最合适的节点，升级这个节点的内核版本，逐步地、自动地将整个平台的节点内核版本收敛起来。

另外，因为腾讯是一家一二十年的老企业了，当将所有资源都合并到一起后，就会存在有机型代次差异的不同服务器硬件，而不同代次的机型，算力是不一样的，如果同一个工作负载的不同 Pod 位于不同代次的机器上，这就可能导致不同 Pod 的负载极其不均衡。为此，TKE 研发了基于机型的性能动态修改每一个 Pod 对应的路由权重的能力。当一个 Pod 底层用的是一些很老的机型的时候，会自动调低对应的路由权重;当 Pod 底层的机型比较新的时候，对应的权重会更大。通过这种方式，打平了不同 Pod 之间的负载，用户看到的每一个 Pod 的负载都是均衡的，最终达到对业务屏蔽机型差异的目的。

另外，不同可用区域的资源余量也不一样。为了解决资源问题，业务往往需要在不同可用区域之间来回腾挪。为了让业务更加充分地利用不同可用区域的资源，能够灵活地在不同可用区之间调度，甚至做到业务不感知可用区域的属性。TKE 应用管理平台提供模糊可用区的能力，彻底屏蔽 K8s 节点、集群、可用区的概念，让大部分业务完全不感知这些资源的属性，充分利用不同可用区的资源，同时让业务具备跨区域容灾能力。

云原生路线图

如果要总结腾讯云原生的特色，那可能主要有三点。

第一点是超大规模，这种体量规模至少在国内没有第二家。第二点是业务场景极其丰富，包括社交、音视频、游戏、支付、腾讯地图等等业务场景。第三点，这些腾讯自研业务对稳定性、容灾要求非常高。

王涛总结说，“我们做这个事情最大的压力是要保证容器化之后业务的稳定性，如果不小心把一个集群搞挂了，或者出现大面积的节点宕机，影响业务运行，这个后果就非常严重。也就是说我们从一开始就理解到业务对稳定性要求极高，大家都是如履薄冰，做事情在细节上会考虑非常完善，因此 TKE 服务腾讯自研业务这么长时间，平台没有遇到过大的故障。”

如今 TKE 平台在腾讯内部已经成功承载了数以亿计的容器，支撑众多海量业务平稳运行，这个持续三年的改造项目，用邹辉的话来讲，它不是一锤子买卖，而是一个持续迭代、持续更新的过程。

腾讯根据自研业务以及目前一些外部企业使用 TKE 进行云原生改造的经验，设计了一个五阶段的路线图，希望能够给其他企业带来参考。