本文整理自腾讯云云原生产品团队的专家产品经理韩沛在 Techo 开发者大会云原生专题的分享内容——Kubernetes 混部与弹性容器。本次分享主要分为三部分：基于 K8s 的应用混部、提升应用混部效果的关键、弹性容器对混部集群的价值。
讨论 K8s 的混部这个话题，是因为我们发现，在业务 K8s 化后，混部和资源利用率对运维团队是一个绕不过去的话题，这个话题也一直是我们腾讯云原生团队一直关注的重点。
首先，毋庸置疑，Kubernetes 的系统能力和它作为引擎推动的云原生生态影响力都非常强大，助力了很多先进理念在生产环境的大规模实用化，包括微服务、自动扩缩容、CICD、服务网格、应用混部等。
这其中有些部分在现有 K8s 的系统中即可以得到很好的支持，比如微服务、自动扩缩容。有些则依赖 K8s 与生态能力的集成，比如 CICD、服务网格，就依赖 K8s 和一些社区 DevOps 、servicemesh 系统的打通，不过它们中的大部分在生态系统中已经得到了很好的集成支持，通常不需要我们再做太多的工作。
但我们今天的话题——K8s 架构下的应用混部，则是一个较特殊的领域，一方面大部分的企业基础设施升级为云原生架构后，通常会天然支持一些混部能力，从而带来一些显而易见的收益，比如资源利用率的提升。可以说容器化和 K8s 为整个行业进入应用的大规模混部打开了一扇窗。而另一方面，但当我们真正进这个领域时，即使站在 K8s 的肩膀上，混部依然是对企业架构能力的一个巨大挑战。
在容器化之前，在物理或虚拟服务器上部署应用，资源利用率通常很低，一是很多应用本身具有潮汐现象，二是服务器大部分情况只能部署一个应用，而非 K8s 那样在一个节点上部署多个。但容器化托管到 K8s 集群后，很多时候，我们会发现资源利用率还是不高。
上图，是一个 K8s 集群线上业务的典型资源曲线，最上面的蓝线是容器资源 request 申请值，红色线是容器真实运行的曲线值，我们看到 request 和 usage 之间有很大 gap，这是因为对容器资源的评估不可能完全精准，另外，波峰和波谷也有差别，最终导致平均利用率不高。
那是不是 K8s 不行呢？当然不是，K8s 在助力我们进行应用混部上虽然还没有解决所有的问题，但绝对是最佳的可选平台之一。
优秀的系统能力使 K8s 天然适合进行混部，包括在线服务的混部和现在业内火热的在离线混部。腾讯内部也通过 K8s 化，在很多场景显著提升了资源利用率。
像腾讯这种规模的计算体量，除了大家熟知明星应用，还有海量的算力在进行服务支撑、离线计算等。通过把这部分应用以及一些潮汐现象明显的产品服务进行混部，资源利用率的提升非常显著。
在业内，Google 基于 K8s 的前身 Borg 系统，从 2015 年至今已发布了多篇与混部相关的论文。于去年发布一篇论文中，可以看到 Borg 支持的混部能力已经逼近 60% 的 CPU 资源利用率。对比其 2011 年和 2019 年的混部效果，可以看到，除了利用率的提升，最显著的变化，一是应用分级粒度更细了，二是各级别的应用运行更加平稳了。尤其是第二点，明显感觉到 Borg 在混部的支撑层面，如调度增强、资源预测回收、任务避让等机制上的进步。
提升混部效果的关键是什么？首先，我们需要明确两个问题。
第一个问题，混部的目的是什么？混部的目的是在保证在线业务服务质量的前提下，实现闲置资源复用，提高整体资源利用率。保证在线业务服务质量是前提，使之不受影响，没有这个前提，利用率提升再高也毫无意义。