既要稳也要省，容器资源该怎么分配？ _容器

众所周知，假期出行，热情高涨，需求增多也使得稳定性保障压力大。当各个服务流量激增时，资源负载压力将会显著提升。微观上，单台物理机的 CPU 利用率会大幅提升，单机上各个容器之间的争抢会增加，性能受到影响。宏观上，整个弹性云的热点机器会增加，可供调度的资源会降低，容器调度和扩容的失败率会上升。
今年，在降本增效的大前提下，不额外增加计算型服务器采购，如何保障资源供给以及确保高压场景下的容器稳定性，对弹性云而言是个巨大的挑战。为了提供更稳定的容器服务，弹性云全面梳理了容器服务资源保障的每一个环节，提出了新分级保障体系，提供了明确的容器资源保障等级，在此基础上，针对不同优先级的容器提供相应的资源和稳定性保障。
早期弹性云容器体系带来的超卖隐患弹性云早期分级体系提供了1/2/3级容器等级，只是对容器的优先级进行了简单的区分，并未将容器优先级与底层的资源保障关联在一起。容器服务在使用过程中，会遇到以下问题：

资源争抢严重
业务延迟较高，毛刺较多
扩容失败概率较高
业务容量评估不准
物理机数量难以评估

之所以会存在这些问题，实际上还是因为在资源层面没有相应的保障。从单机资源看，部分物理机的 CPU 使用率峰值过高，并且容器的 CPU 资源存在不同程度的超卖。
从集群资源来看，旧体系下 quota 与物理机资源缺乏关联，导致业务申请的 quota 仅仅停留在数字层面，不指导物理机资源的准备。此外，quota 还缺乏管控，导致 quota 的申请与实际需求严重脱节。

文章插图
【既要稳也要省，容器资源该怎么分配？】造成上述诸多问题很重要的一个原因就是弹性云资源整体上是超卖的，且比较严重。
所谓的资源超卖，指的是资源的申请量>供给量，表现为单机 & 集群方面均超卖。

单机层面，一台物理机上运行的所有容器的规格相加大于物理机所能提供的资源总量。
集群层面，服务资源的 quota 总和大于集群物理机资源总量。

文章插图

从上图中可以看到，单是1级服务申请的资源量，就已经超过了物理机的总资源量。在集群和单机都超卖的情况下，早期的分级体系并没有确立明确的超卖规则，使得旧体系容器运行环境整体处于无序和不确定的状态下。
两大超卖解决思路带来的四大收益思路一：核心服务链路不超卖所有的核心服务链路上的服务均1:1对应物理机资源，不超卖。通过对机房1和机房2进行简单的统计, 发现核心服务链路中网约车+两轮车+代驾服务的申请量总和占据了所有服务总申请量的大约一半，且机房1核心服务的申请量已经超过总CPU数，机房2核心服务的申请量基本接近总CPU数。所以，核心服务不超卖受限于资源，方式不可行。

文章插图

思路二：核心服务链路中最重要的服务不超卖受限于资源，无法做到所有的核心服务链路中的服务都不超卖，那退一步，在物理资源有限的情况下，保障核心服务链路中最重要的服务不超卖，并在此基础上，对于剩余的服务制定合理的超卖规则。
因此，弹性云需要重新制定分级保障体系，同时为新分级体系制定明确的超卖规则。超卖规则如下：

核心服务中20% -> S级服务：不超卖
老1级 -> A级服务：2倍超卖
老2/3级 -> B级服务：4倍超卖

文章插图
在新的超卖规则下，可以看到，机房1和机房2的总物理CPU量是基本能满足需求的（机房2的资源申请量略微超出, 可以通过新增机器或是缩容来满足要求）。
这样的重新设计下，我们在2022年元旦前完成所有S级服务的接入， 2022年国庆前完成网约车核心服务／两轮车核心服务／代驾核心服务接入新体系。总体来看，这样的改变带来了四大收益：