腾讯云Serverless如何应对K8s在离线场景下的资源供

小提示：您能找到这篇{腾讯云Serverless如何应对K8s在离线场景下的资源供}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的腾讯云Serverless如何应对K8s在离线场景下的资源供内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">本文整理自腾讯云云原生产品团队的专家产品经理韩沛在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混部的效果会越来越好，适用的场景也会越来越多。谢谢大家！