将云原生进行到底：腾讯百万级别容器云平台实践揭秘

导读｜基于 K8s 的云原生容器化已经在腾讯内部海量业务中大范围落地实践。业务从传统的虚拟机部署形态无缝切换到容器部署形态，运行在 K8s 上的应用从无状态服务扩展到有状态服务，这个过程经历了哪些改造？同时，K8s 如何经受住业务形态复杂多样、模块数量庞大的考验？遇到哪些新的挑战？如何优化？效果怎么样？腾讯云高级工程师林沐将为你解答。

在线业务资源容器化部署的问题与优化方案

腾讯平台的业务基本都属于在线业务。这些业务以前在虚拟机部署时，是通过物理机操办的方式生产出很多虚拟机，对于业务来说是不感知的。当业务发现虚拟机负载较低时，可将多个在线业务混部来提高资源利用率。

这种资源管理方式到容器化部署时发生了一些变化，主要有四方面的内容。

容器交付。每个 Pod 在交付的同时需要声明规格大小，规格大小要改变时 Pod 必须销毁重建，无法通过混部来新增业务。节点均衡。K8s 每个节点上部署多个 Pod，每个节点上的 Pod 类型、数量也都不相同，要保证节点均衡是一个挑战。K8s 的云原生特性，也就是弹性，是否能够符合在线业务在生产环境中的需求？集群池化。K8s 是按集群维度管理，而平台有上万个业务，这么多业务如何映射到不同的集群实现条带化管理？

针对上述问题，腾讯采取的优化手段是：

第一，资源利用率提升——动态压缩和超卖。我们面临一个痛点是用户配置的容器规模不合理，普遍偏大，这样节点装箱率和负载比较低。所以第一个优化方式就是 Pod 资源动态压缩，Pod 请求双核处理器 4G 内存，在调度时压缩成单核 4G 内存。因为 CPU 属于可压缩资源，内存属于不可压缩资源。这里修改的只是 Request 大小，并不修改 Limit，所以不影响容器实际能使用的上限值。这样能提高节点的装箱率。接下来是 Node 资源动态超卖，根据负载情况超卖更多 CPU 核心。

第二，节点负载均衡——动态调度和重调度。资源压缩超卖能提高节点的装箱率和负载使用率，但 Pod 是共享Node 的，压缩和超卖会加剧它们之间的干扰。于是我们开发了动态调度器，当每一个 Pod 调度时，能够感知存量 Node 当前的实时负载情况，从而对增量 Pod 在 Node 当中均衡处理，掉到一个低负载的节点上。存量 Pod 在节点上也有可能发生高负载，这时我们在节点上部署 Pod-Problem-Detecor、NodeProblem-Detecor，检测出哪个 Pod 会导致节点高负载，哪些 Pod 属于敏感 Pod，通过事件上报告诉API Server，让调度器将异常 Pod、敏感 Pod 重新调度到空闲节点。

第三，K8s 业务弹性伸缩——协同弹性。在线业务最关心业务稳定性。有时业务负载超出预期时，因为最大负载数配置过低，导致业务雪崩。所以我们对 HPA 进行优化，加入 HPAPlus-Controller，除了支持弹性最大副本策略之外，还能够支持业务自定义配置进行伸缩。第二个是 VPAPlus-Controller，可以 Pod 突发高负载进行快速扩容，对有状态的服务也可以进行无感知扩缩容。

第四，集群资源管理——动态配额和资源腾挪。从平台的角度，K8s 集群也是一个重要的维护对象。平台通过动态 Operator 的方式控制业务对集群的可见性以及配额大小，使得各个集群的业务是分布均匀的。集群本身也有规模大小，有节点伸缩，叫做 HNA。HNA 能够根据集群负载情况自动补充资源或释放资源。生产环境中一种情况是，有时候突发活动，在公共资源池里没有特定资源，需要从其他系统里腾挪资源。所以我们开发了弹性资源计划 Operator，它会给每个节点、每个集群下发任务，要求每个集群释放一些Node 出来。这批节点的数量要尽可能符合业务的数量要求，同时要对存量业务的负载质量不产生影响。我们的方式是通过动态规划的方式解决问题，从而在业务做活动，或者紧急情况下，能够使集群之间的资源也能够流转。

容器化对动态路由同步的挑战与解决方案

每一个 Pod 在销毁重建的时候会动态添加或提取路由。一般来说，生产环