三年全面上云，腾讯自研业务超千万核资源的容器管理实践

作者 | 王涛

仅用三年时间，基于腾讯云 TKE 底座，腾讯自研业务容器化规模已达到千万核级别的 CPU 资源规模。面对如此海量的异构资源和复杂多样的业务场景，腾讯是如何做到资源利用率 65% 的？在调度编排、弹性伸缩、应用管理、稳定性保障等方面，腾讯又有哪些秘籍？在 ArchSummit 2022 全球架构师峰会（深圳站）上，腾讯云自研上云容器平台负责人王涛发表了题为《如何管理超千万核资源的容器规模》的演讲，为大家逐一揭秘。

腾讯自研业务容器化上云历程

腾讯自研业务容器化上云的技术路线经历了多个阶段。最开始是一个虚拟机只调度一个容器的上云实验阶段，我们叫胖容器阶段；再到富容器，一个节点多个 Pod，Pod 中有多进程的阶段；然后是单 Pod 单进程的微服务容器阶段；现在在腾讯内部也有大规模的容器使用 TKE Serverless，再往后为业务提供 FaaS 的能力。整个阶段都在夯实混部技术，包括离线混部、在线业务混部。Service Mesh 也得到了一定规模的实践。

上图是自研上云涉及的相关产品的简单架构。最底层是 IaaS 腾讯云计算网络存储，往上层的基础服务主要是 Kubernetes、ETCD、Helm，再往上是腾讯云的产品化服务，包括腾讯 TKE 产品、TKE Serverless、Edge、TKE-STACK。TKEx 容器平台服务腾讯内部业务，内部入口可以直接是容器平台或者研效平台。

经过三四年的大规模自研业务上云过程，我们已经在各个技术领域沉淀了很多最佳实践和技术方案组件，诸如容器调度、弹性伸缩、有状态服务、容器化、资源管理、稳定性提升、业务运维效率提升等都是我们沉淀或重点关注的技术。

上云阶段不止是把业务容器化上云，更重要的是怎样衡量上云上得好不好。这里我们有腾讯云原生的成熟度规则来考核腾讯自研业务以及对应的容器平台做得好不好，主要从四个维度考核，最大的权重维度是资源利用率，指业务容器利用率、平台资源利用率。还有弹性伸缩能力、容器可调度能力，以及申请的 Pod 资源是不是小核心的资源。从规模与成熟度曲线可以看出，最近两年时间我们实现了非常大的规模增长，云原生成熟度得分也逼近 90 分。

各种混部场景下利用率提升方案

在线离线混部集群

在线离线混部集群是公司面临的主要混部场景。之所以要做在离线混部，是因为在线业务都会面临利用率较低、利用率有潮汐分布状态的状况。而离线作业很多是碎片型资源，可以容忍一定失败率，执行时间较短。我们的在离线混部是面向 K8s，设计原则包括通用性，方便未来开放到社区和外部客户；符合云原生方式；降低对应用依赖；兼容 K8s 和 Hadoop 生态。而我们的目标包括保证在线业务的 SLO，离线作业要在负载利用率高峰期快速上下线，离线作业成功率也有一定保障，保证服务质量前提下尽可能提升资源利用率。

腾讯内部在离线混部的技术方案名为 Caelus。它面向业务提供基于业务优先级的定义，接下来就当节点或集群出现负载或者干扰时，可以根据优先级来 驱逐 或抑制，对于不可压缩资源只能驱逐到负载较低的集群。高优的离线作业不会直接 Kill，而是降低容器的配置。方案最核心的是节点上 Caelus 的组件，主要做干扰检测数据的采集、分析，再决策做离线抑制还是调度。

Caelus 的主要流程包括：

数据指标的采集，包括来自于业务监控系统的业务自定指标。

采集到的指标统一存储在对应的 Store 组件，再从 Store 拉取指标做在线资源的业务预测、离线业务的健康检测。如果出现资源超发或高负载情况会做对应的抑制或者驱逐。

这里提供本地预测和中心式预测两种方式，中心预测主要通过 descheduler 的方式，先采集分析得到全维度的应用负载，做驱逐时考虑工作负载是不是做了多副本、对应的服务是否做了动态路由接入等，重调度时去衡量这些工作负载的配置，确保业务的服务质量。

更重要的是本地干扰检测和快速驱逐的能力，因为这里只关注节点本身的资源使用情况，能做出更快的离线业务的驱逐避让。

干扰检测的指标一部分来自于应用注册的业务自定义指标，还有一部分来自平台自身获取的操作系统、节点提供的指标。处理的方式一种是直接把离线的 Kill 掉，一种是直接做限流操作。驱逐时一定要考虑业务的优先级以及业务有没有做多副本、高可用，考虑是不是已做过容灾措施。根据监控数据，我们的在离线混部的集群节点负载已经到了将近 70% 的资源利用率。

在线混部集群

腾讯也有一些集群只能部署在线业务。这种集群要提升资源利用率会涉及不一样的技术挑战。

全部是在线业务，意味着无法定义每个任务或者业务的优先级，每个业务的优先级都是一样的。那么首先要做超卖、动态 Pod 的资源压缩。在线业务混部意味着集群的负载、节点的负载可能出现分布不均匀的情况，所以要解决集群节点负载均衡的问题。高负载时要及时、快速扩容资源，所以要提供极速的集群伸缩能力。还有一个关键动作是，平台或者容器的资源总是有限的，一定要有面向应用的业务配额动态管理。

弹性伸缩这一层，我们自己做的方案叫做二级弹性资源池能力。第一层，平台会把各地域闲置的 CVM 放在闲置紧急 Buffer 资源池里，可以秒级地从节点把 CVM 加入集群里，实现集群秒级扩容。这里的关键是节点所有初始化流程、标准化建设都已经准备就绪，可以轻松应对集群负载突发情况。第二层就是去腾讯云申请 CVM，CVM 要做初始化流程，这一层弹性能力是分钟级的。当紧急 Buffer 池没有资源时才能找腾讯云接口创建对应的资源加到集群里。

面向业务的弹性伸缩，我们把 K8s 的 HPA Controller 剥离出来，自己做了 HPAPlus Controller。因为我们的应用规模非常大，一个集群里可能有几万个 Workload，意味着几万个 HPA。我们自研的 HPAPlus-Controller 做了足够的性能优化，以支持如此单集群的 HPA 性能。

HPA 这里，我们还做了动态调整 HPA 最大副本数的特性。业务配的最大副本数通常是一个很主观的不可信的值，当业务 HPA 达到 maxReplicas 后仍然有持续扩容的趋势，HPAPlus 会提供 更大弹性 Buffer 能力给业务，maxReplcas 能动态的自增长，还会发告警让业务赶快判断是否正常。这种 HPA 行为，我们会预留业务一定时间处理超出预期的业务流量，当然也有机制去限制 maxReplicas 的无限制自增长。我们还有 HPA 和 CronHPA 的联动决策，支持业务计划内的定时扩容，即便实际流量超过预估流量也能自动扩容。另外 VPAPlus-Controller 是用来支持有状态服务无感知垂直扩缩容场景，而不需要重建 Pod。

我们的动态调度器是解决节点负载不均衡的问题。它会根据负载给节点打分，让节点关键资源在集群节点中均衡分布。我们还有自研的热点动态补偿算法，避免调度热点问题，控制好节点的 单位时间 Pod 装箱数量。

我们的在线业务混部利用率提升方案，让集群 CPU 平均利用率提升到 30-40% 的水平。在使用动态调度器之前节点负载是不均衡的，上线动态调度器后负载相对比较均匀。

我们的在离线混部、在线混部方案最后都通过 Crane 对外开源了全套技术。

稳定性面临的挑战及其破解之法

负载上升之后会面临很多稳定性问题，我们主要关注平台层、集群层、节点层以及业务层的稳定性。

平台和集群稳定性层面有两个实践案例。第一是监控，要提升稳定性一定要有全面的监控体系。我们通过 Prometheus + Thanos + Kvass 方案，提供高可用部署以及 Prometheus 的横向扩缩容能力。

我们集群规模往往很大，每个集群组件很多，意味着配置项非常多。为了对每个集群的所有组件配置做好统一，确保每个集群都是标准的，不能因为某个组件没配对导致行为不一致，就需要做一些组件标准化的监控。我们研发了组件探测能力，可以看到每个组件版本是否统一，是否在做组件灰度发布，几百个集群中哪些组件出现了异常，都可以通过监控实时获取。

节点稳定性是 K8s 生产环境遇到最多的问题，这里也举几个例子。第一个例子是针对一些节点上的核心组件、内核状态做对应的指标监控、节点自愈。我们基于 NPD 组件扩展了指标，通过这个组件对节点稳定性做监控，用对应的决策树做自愈。这个组件也在腾讯云 TKE 组件里。

节点规模大了之后会遇到各种各样的内核问题，要升级内核或者打补丁时，必须要跟踪好每个补丁是不是正常打好，对应的内核版本是不是我们当前的基线版本内核，这都需要监控、标准化和自动化。比如某些节点少打了一些补丁，我们需要自动把遗漏的补丁打上。

业务稳定性方面，我们在内核层面做了很多工作，业务出现稳定性问题要看 Pod 对应内核指标是不是有异常，如果出现异常要快速调度。

同一节点上的 Pods 共用内核、资源抢占的问题层出不穷，最终还是依靠演进到 Serverless K8s（TKE Serverless）这个容器产品，能够给 Pod 做到虚拟机级别的隔离能力，最终彻底解决这一类稳定性问题。

从面向集群到面向应用的调度编排

前两三年大家更多关注的是怎样面向用户提供 K8s 的能力。接下来要重点解决的是从面向集群到面向应用的调度编排问题。这意味着用户不用再关注集群，不用关注底层资源，只需关注应用本身。

有一个例子，一个业务全网有一万个工作负载，有五万个 Pod ，分布在全球十七个地域，八十多个集群。如果我要对这个业务做一次全网变更，按照以前面向集群的方式效率非常低。所以要抽象出面向应用的能力，首先是跨集群应用的统一变更，要有一个统一的看板跟踪发布是否正常。业务部署后还要能从视图看到部署的容灾是不是合理的，所以要有多地域的容灾检测。所有这些能力我们都是基于腾讯云的 Clusternet 开源项目来建设。

Clusternet 有 2 个极其重要的多集群能力，一个是动态拆分调度，主要根据集群容量、位置拓扑来做决策。比如用户要求两地三中心，接下来在两地三中心选集群，每个集群容量不一致时要根据容量做评估。

另一个是多集群协同弹性伸缩。多集群 HPA Coordinator Controller 做多集群 HPA 协同 的事情，可以根据集群容量、集群的可用性做 HPA 协同，保证业务扩容时不会因为某一个集群的资源不足扩不出来，自动调度到其他可用集群。

腾讯在大规模资源上云过程中沉淀了这么多技术能力，服务了大量业务场景，包括音视频、游戏、电子商务、社交、办公协同、出行等，我们正在做的是把这里积累的各种业务场景的最佳实践，都输出到云原生应用管理平台这个公有云产品中，比如应用的标准化检测、业务的 QoS 定义、应用多集群灰度发布、应用多集群自愈等等，最终将容器平台上升到应用管理维度，同时服务腾讯内部和外部客户。

作者简介：

王涛，腾讯云 TKEx 容器平台负责人，8 年 K8s 生产经验，从 0 到 1 建设 TKEx 平台，全程支持腾讯海量自研业务容器化上云。

电子书推荐

2022 年，数字化转型成为了全行业关注的焦点，数字经济的价值进一步凸显。云计算作为数字时代的关键要素之一，在行业数字化解决方案、产业链数据流转、资源动态配置、业务创新等方面正产生着难以估量的价值。

为了帮助更多中国互联网行业的同仁一窥云计算领域最前沿趋势与实践，腾讯云连续两年推出《腾讯云技术实践精选集》，收录了腾讯云最新实践经验和研究成果。2022 年的技术实践精选集覆盖云原生、大数据、数据库、中间件、基础设施等热门技术领域，近 100,000 字的技术汇编，26 位专家的真知灼见，倾囊相授！扫描二维码，即可获取全部精彩内容！