看腾讯如何提升 Kubernetes 集群利用率？

提到近两年的技术热词，“云原生”觉得是位居前列。从云计算大数据再到如今的云原生时代，一大批新技术涌现，例如当下最火热的系统部署和容器服务平台Kubernetes（K8s），K8s 甚至被不少人认为就是未来云平台基础设施的标准。

网上关于K8s如何使用的案例跟教程已数不胜数，那么在实际使用中，该如何最大性能地提升K8s集群利用率呢？

近日，来自腾讯的宋翔在由信通院、腾讯云、FinOps 产业标准工作组联合策划的《原动力 x 云原生正发声 降本增效大讲堂》第三期直播上就《如何提升Kubernetes集群利用率》进行了实战经验分享，内容非常干货且具备实操性，笔者整理分享给大家。

利用率提升背景

利用率提升的大背景可以归纳为4个字——降本增效。通常来说，集群的利用率低会导致成本居高不下。集群、应用等配置，使用不合理，可能无法持续提升集群资源利用率，导致恶性循环。

资源不合理的原因主要有以下几点：

集群管理员无法准确评估集群规模配置的集群Buffer不合理，Node资源冗余。用户Pod资源配置不合理

Pod实际利用率低，配置要求高，导致集群调度满了，但利用率无法提升。

若想要深入探究集群低负载的原因，可以从两种情况着手分析。

情况1：Pod Resource Setting

如上图所示，Pod QoS分级有三种。

BestEfforts模式下，Pod不设置Request值和Limit值。因为QoS优先级过低，所以在当前的实际应用场景中，几乎都不采用该设置模式；

Guaranteed模式要求用户设置相同的Request值与Limit值，虽然该模式具有较强的稳定性，但无法有效提升集群资源利用率；

最常使用的是Burstable模式，该模式下用户设置Request值与Limit值，同时要求Request值小于Limit值，通过二者数值的调整可以实现实际场景下利用率的提升。

情况2：Node分配Pod资源

一个Node节点具有一定的Capacity，实际上这些资源并不能够全部被Pod所使用。其中Node需要预留部分资源给操作系统和Kubelet。除此以外的Node剩余可调度资源可以提供给Pod进行调度。

通常情况下，Node节点上会剩余一些碎片资源，这些资源无法满足待调度Pod的要求，这便造成了节点资源的浪费。

通过以上两种情况，可以总结出造成节点资源不足的两个原因。

第一，节点Pod调度不充分。

集群Node资源常年冗余，Pod调度不充分；少数HPA扩容场景时，Pod调度水位较高，但是日常又恢复低水位，导致日常预留Buffer过多。

第二，Pod设置不合理。

一般用户难以估算Request/Limit值；用户更倾向过于保守的Request/Limit值；为满足短暂（周期）峰值设置较高的Limit值；

不合理的镜像导致需要较大Request，进而导致Pod本身常年低负载。

常见集群负载优化方案思路1. 用户篇

优化思路

第一，优化Pod配置。

利用历史数据进行Request、Limit调整；

用户在资源分析页面，利用Crane推荐值；

调整Pod类型为相对规整的资源类型；

优化程序和镜像。

第二，设置合理的HPA。

根据历史数据，推荐用户设置合理的HPA范围和阈值；

基于Crane EHPA算法修正HPA触发条件；

梯度扩容减少扩容频率，提高利用效率。

第三，设置合理的CronHPA。

对于周期性明显的业务，可以设置定时周期扩缩容；

在节假日、活动促销时，可以提前设置时间段扩容。

第四，根据用户的策略，设置适当的VPA。

腾讯医疗服务案例

从上图可以看出，上午时段流量上涨迅速且每周五具有HPV疫苗抢购活动，所以需要在该时段进行提前自动扩容设置。

同时，根据低峰期、高峰期、平峰期所需要的节点数（分别为2、18、8），用户可以结合HPA和CronHPA做简单的调整——将实例范围设置为2-30，CPU使用率达到Limit值的50%时触发策略。

通过以上一系列操作，相比未开始HPA时，成本可以有效减少60%，达到“降本”的目的。

2. 平台篇

优化思路

前面已提到，Node资源并不能够全部被Pod所使用，需要预留部分资源给操作系统和Kubelet，同时还会产生无法满足Pod调度要求的碎片资源。那么在这种情况下，该如何充分提高利用率呢？

第一，动态Pod压缩。

如上图所示，我们可以看到Pod被分配至节点A、B、C上，其中Pod A、Pod B的CPU Usage较低，这种情况下可以对Pod A、Pod B进行压缩，将其余待调度的Pod放置在该节点，以实现平均CPU负载提升的目的。

需要特别注意的是，在线业务没有优先级之分，每一个Pod都非常重要，不能因为其中某一个Pod占用多数资源或可能造成其他资源异常就对其进行驱逐。

同时，做资源压缩的前提是用户已设置Request值与Limit值，且二者初始值一般相等。这可以保证用户可使用的最大值不变，在对Request值进行压缩时，一个节点可以容纳更多的Pod。

此外，起初可以设置全局默认压缩比，随后可根据历史数据进行行态调试，以达到最佳值。

第二，Node节点超卖。

如上图所示，假设左侧节点为30核，若能通过一系列的手段让Kubelet、Kubernetes调度器认为该节点为60核，那是不是就能够调度更多的Pod呢？

该如何去做呢？分两个阶段：

设置全局默认超卖比；

根据历史数据、实时数据动态改变超卖比。

第三，碎片整理。

如上图，我们可以看到节点A、B的资源均不满足未调度Pod G的需求，且节点B中的Pod E可以调度到节点A中，腾挪空间。

这种情况下，可以Pod E从节点B调度至节点A ，以此增加节点B的空闲资源来满足未调度的Pod G的需求。这就是碎片资源整理的过程。

第四，在离线混部。

当平台规模较大或在线、离线业务均具有的情况下，一般都需要使用在离线混部的方式提升资源利用率。

其实现逻辑较为简单：当集群资源充足时，动态地将离线任务调度到空闲节点上；当节点资源接近高负载阈值时，优先驱逐离线任务。

负载提升和稳定性优化

通过各种手段提升集群利用率的同时，也会带来相应的负面问题：

引起Node节点高负载，影响服务质量；Node节点负载不均；

剩余剩余资源不足导致Pod 横向度失败。

针对以上负面问题，通常需要使用扩容及稳定性相关的手段来解决。

第一，两级扩容机制。

HNA: 当集群负载（装箱率）达到阈值（如85%）时，会触发节点自动扩缩容，来增加Node节点；

超级节点：当工作负载引发大量扩容、集群资源不足而导致Pod突增时，利用超级节点（通过Virtual Kubelet加入集群的虚拟Node）直接将Pod扩容到Virtual Kubelet节点上，超级节点的底层直接使用腾讯云公有云资源池创建弹性Pod。

第二，两级动态超卖。

通常情况况下，Pod压缩与Node超卖两种手段需同时使用。Pod压缩已实现从静态到动态的优化，其压缩比（Request/limit）可以根据历史状态进行动态修改。

同样，Node超卖也实现了由静态向动态的升级，Node节点可以根据实时负载进行动态调整，以防止节点负载过高。

第三，动态调度。

动态调度机制可以实现保证Node节点的资源均衡，避免不同Node节点负载不均的现象。

上图可以看到，原生调度为静态调度且Node2空闲资源较多，那么根据静态调度策略，会将新的Pod调度到Node2节点中。但经过动态调度的算法优化，实际上会将Pod调度到Node1节点上，这是什么原因呢？

这是因为Node1节点的真是利用率更低所致的，将Pod调度至Node1上会提高Node的Pod利用率，进而使各节点的平均负载相近。

上图是动态调度机制的原理，Extend NodeScorer会根据不同时段的信息参数对Node进行打分，Kube-scheduler调度器可获取这些参数信息进而将新增Pod调度至实际内存使用更低的节点上。

第四，动态驱逐。

当Node负载不均或Node利用率过高时，大概率会对节点上运行的Pod资源产生影响。这种情况下，我们可以根据节点当前的状态信息以及节点上Pod的实际利用率对Pod进行动态驱逐。这里的参考维度是多样的，一般包括：CPU、Memory、FD、Inode等，且不同业务针对参数的权重与指标也存在差异。

上图是某一在线业务集群的状态，可以清晰看到在经过超卖及压缩后，该集群的节点平均利用率可达38.7%。

节点负载分布（未采用动态调度及动态驱逐）

节点负载分布（采用动态调度及动态驱逐）

通过以上两图对比，我们可以看到：在未采用动态调度及动态驱逐时，节点负载不均衡同时方差值较大。而在采用了动态调度及动态驱逐后，节点负载便会趋于稳定，异常Node数目减少，资源利用率得到有效提高。

总结本文结合腾讯应用实践，分享了Kubernetes集群利用率提升的思路和实现方式，包括两级扩容机制、两级动态超卖、动态调度、动态驱逐。作者简介：

栏目介绍：