本文整顿自 腾讯云云原生产品团队的专家产品经理韩沛 在 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 在混部的撑持层面，如调度加强、资源预测回收、工作避让等机制上的提高。
晋升混部成果的要害是什么？首先，咱们须要明确两个问题。
第一个问题，混部的目标是什么？混部的目标是在保障在线业务服务质量的前提下，实现闲置资源复用，进步整体资源利用率。保障在线业务服务质量是前提，使之不受影响，没有这个前提，利用率晋升再高也毫无意义。
第二个问题，什么样的利用适宜混部？适宜混部的利用有两类：一类是算力要求很高的周期性利用，通常是一些离线计算工作。一类是容易造成资源节约的利用，通常是一些长时间运行的、具备潮汐景象的在线服务。但要留神，有些在线服务会对某些资源有较高的敏感性，这类服务是对混部零碎的最大挑战，因为稍有不慎就会偏离混部的目标，影响了在线服务质量，得失相当。
在确定了这两个问题之后，咱们来看下混部零碎须要有哪些机制。通常分为三层：
一是对混部利用进行特色画像、定级以及分配资源配额的利用管理层。这一层定义利用的级别，混部的机会，以及通过配额保障资源分配不失控。
二是对混部集群进行调度、隔离、资源复用和避让的外围零碎。这一层是混部的外围，根本决定了咱们的集群能达到什么样的混部成果。
最初，还须要一整套适配的自动化经营零碎。
混部的基本原理是对闲置资源的再调配。通常，闲置资源有两个起源。集群内会有碎片资源，这是资源分配颗粒度问题导致的，这些碎片资源能够调配给颗粒度更小的利用应用。另外，在线服务申请的资源通常会大于理论应用的资源，配合利用画像，预测出这部分服务的波峰波谷，能够将这部分闲置资源分配给其余利用。
基于这个背景，引申出混部最外围的两个子模块：资源复用和工作避让。顾名思义，资源复用就是把上述两种闲置资源通过预测、回收的机制，实时再调配给混部利用应用。而工作避让，就是检测外围在线服务是否收到了混部的影响。一旦产生烦扰，马上触发抵触解决机制，进行压抑和再调度等操作。
能够这么说，这两个模块决定了混部的成果和可混部的利用范畴。除了实践上的问题，还有一些重要的点必须思考：为了保障混部成果，频繁对集群实时状况进行预测和资源回收，对集群自身带来了额定的累赘，如何在尽可能资源复用和尽量升高资源预测回收频率之间找到均衡？还有，为了保障在线服务的品质，工作回避通常不可避免，这就升高了次优先级利用的执行效率，高负载时可能导致工作的频繁重试和沉积，进而可能连累整个集群。
为了解决这些问题，腾讯云云原生团队做了始终在思考和尝试，目前较先进的一种形式是通过 serverless 容器即弹性容器，来拓展整个混部集群的资源池。
弹性容器是腾讯云推出的无服务器容器产品。它反对一种能力，相似开源 virtual kubelet 的形式，但又相比开源计划能力更强、更适宜生产。它反对在一个既有 K8s 集群中通过部署虚构节点的形式把 pod 调度为弹性容器。调度为弹性容器的 pod 与原集群中的其余 pod 网络互通，如果关联了 service，service 间也可互通。
所以无论是已有 workload 的扩容、还是新的 workload，都能够以一种平滑的形式进行调度。且该能力对集群不会产生额定的保护老本。
这个能力对混部的外围价值在于：它无老本的扩大了集群资源池，升高了资源抵触的危险，晋升了混部集群的冗余度和适用性。另外，在检测到资源有余之类的抵触时，在很多场景能够不停止次优先级工作，而是视状况扩容或再调度，在弹性容器上持续运行工作，秉持尽量不打断已启动工作的准则，晋升整个零碎的效率。
这类混部集群的几个典型场景：
1、低负载时进行工作填充，运行更多任务，晋升集群资源利用率。
2、万一产生了在线服务烦扰，封闭相干节点，驱赶次优先级工作到虚构节点，让其持续运行。
3、产生集群资源缓和时，封闭相干节点，视状况，如果是可压缩资源缓和，比方 CPU、IO 等，则压抑次优先级工作；如果是不可压缩资源缓和，如内存、存储等，则驱赶次优先级工作到虚构节点；在此状况下所有新增 Pod 均调度到虚构节点，不再对集群固定资源减少任何压力，防止产生雪崩。
这 3 个例子还不能笼罩所有的混部场景，但曾经晋升了原生 K8s 集群混部的适用范围。咱们也在继续摸索其余的门路来做到更好。也欢送有想法的敌人下来一起探讨和分享。
最初，混部是一个继续优化的过程。各家大厂都对混部投入了相当长的工夫钻研，才开始放量铺开。随着技术的倒退，K8s 混部的成果会越来越好，实用的场景也会越来越多。谢谢大家！
Kubernetes 混部与弹性容器（本文）PPT 下载方式，请在公众号腾讯云原生后盾回复关键字“EKS”获取。
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！