超大规模商用 K8s 场景下，阿里巴巴如何动态解决容器资源的按需分配问题？

引言
==

不知道大家有没有过这样的经历：当我们拥有了一套 Kubernetes 集群，然后开始部署应用的时候，我们应该给容器分配多少资源呢？

这很难说。由于 Kubernetes 自己的机制，我们可以理解容器的资源实质上是一个静态的配置。

*   如果我发现资源不足，为了分配给容器更多资源，我们需要重建 Pod；
*   如果分配冗余的资源，那么我们的 worker node 节点似乎又部署不了多少容器。

试问，我们能做到容器资源的按需分配吗？接下来，我们将在本次分享中和大家一起进行探讨这个问题的答案。

生产环境中的真实挑战
==========

首先请允许我们根据我们的实际情况抛出我们实际生产环境的挑战。或许大家还记得 2018 年的天猫双 11，这一天的总成交额达到了 2135 亿。由此一斑可窥全豹，能够支撑如此庞大规模的交易量背后的系统，其应用种类和数量应该是怎样的一种规模。

在这种规模下，我们常常听到的容器调度，如：容器编排，负载均衡，集群扩缩容，集群升级，应用发布，应用灰度等等这些词，在被“超大规模集群”这个词修饰后，都不再是件容易处理的事情。规模本身也就是我们最大的挑战。如何运营和管理好这么一个庞大的系统，并遵循业界 dev-ops 宣传的那样效果，犹如让大象去跳舞。但是马老师曾说过，大象就该干大象该干的事情，为什么要去跳舞呢。

Kubernetes 的帮助
==============


大象是否可以跳舞，带着这个问题，我们需要从淘宝、天猫等 APP 背后系统说起。

这套互联网系统应用部署大致可分为三个阶段，传统部署，虚拟机部署和容器部署。相比于传统部署，虚拟机部署有了更好的隔离性和安全性，但是在性能上不可避免的产生了大量损耗。而容器部署又在虚拟机部署实现隔离和安全的背景下，提出了更轻量化的解决方案。我们的系统也是沿着这么一条主航道上运行的。假设底层系统好比一艘巨轮，面对巨量的集装箱---容器，我们需要一个优秀的船长，对它们进行调度编排，让系统这艘大船可以避开层层险阻，操作难度降低，且具备更多灵活性，最终达成航行的目的。

理想与现实
=====

在开始之初，想到容器化和 Kubernetes 的各种美好场景，我们理想中的容器编排效果应该是这样的：

*   从容：我们的工程师更加从容的面对复杂的挑战，不再眉头紧锁而是更多笑容和自信；
*   优雅：每一次线上变更操作都可以像品着红酒一样气定神闲，优雅地按下执行的回车键；
*   有序：从开发到测试，再到灰度发布，一气呵成，行云流水；
*   稳定：系统健壮性良好，任尔东西南北风，我们系统岿然不动。全年系统可用性 N 多个 9；
*   高效：节约出更多人力，实现“快乐工作，认真生活”。

然而理想很丰满，现实很骨感。迎接我们的却是杂乱和形态各异的窘迫。

杂乱，是因为作为一个异军突起的新型技术栈，很多配套工具和工作流的建设处于初级阶段。Demo 版本中运行良好的工具，在真实场景下大规模铺开，各种隐藏的问题就会暴露无遗，层出不穷。从开发到运维，所有的工作人员都在各种被动地疲于奔命。另外，“大规模铺开”还意味着，要直接面对形态各异的生产环境：异构配置的机器、复杂的需求，甚至是适配用户的既往的使用习惯等等。


除了让人心力交瘁的混乱，系统还面临着应用容器的各种崩溃问题：内存不足导致的 OOM，CPU quota 分配太少，导致进程被 throttle，还有带宽不足，响应时延大幅上升...甚至是交易量在面对访问高峰时候由于系统不给力导致的断崖式下跌等等。这些都使我们在大规模商用 Kubernetes 场景中积累非常多的经验。

直面问题
====

稳定性
---

问题总要进行面对的。正如某位高人说过：如果感觉哪里不太对，那么肯定有些地方出问题了。于是我们就要剖析，问题究竟出在哪里。针对于内存的 OOM，CPU 资源被 throttle，我们可以推断我们给与容器分配的初始资源不足。


资源不足就势必造成整个应用服务稳定性下降。例如上图的场景：虽然是同一种应用的副本，或许是由于负载均衡不够强大，或者是由于应用自身的原因，甚至是由于机器本身是异构的，相同数值的资源，可能对于同一种应用的不同副本并具有相等的价值和意义。在数值上他们看似分配了相同的资源，然而在实际负载工作时，极有可能出现的现象是肥瘦不均的。


而在资源 overcommit 的场景下，应用在整个节点资源不足，或是在所在的 CPU share pool 资源不足时，也会出现严重的资源竞争关系。资源竞争是对应用稳定性最大的威胁之一。所以我们要尽力在生产环境中清除所有的威胁。

我们都知道稳定性是件很重要的事情，尤其对于掌控上百万容器生杀大权的一线研发人员。或许不经心的一个操作就有可能造成影响面巨大的生产事故。

因此，我们也按照一般流程做了系统预防和兜底工作。

*   在预防维度，我们可以进行全链路的压力测试，并且提前通过科学的手段预判应用需要的副本数和资源量。如果没法准确预算资源，那就只采用冗余分配资源的方式了。
*   在兜底维度，我们可以在大规模访问流量抵达后，对不紧要的业务做服务降级并同时对主要应用进行临时扩容。

但是对于陡然增加几分钟的突增流量，这么多组合拳的花费不菲，似乎有些不划算。或许我们可以提出一些解决方案，达到我们的预期。

资源利用率
-----

回顾一下我们的应用部署情况：节点上的容器一般分属多种应用，这些应用本身不一定，也一般不会同时处于访问的高峰。对于混合部署应用的宿主机，如果能都错峰分配上面运行容器的资源或许更科学。


应用的资源需求可能就像月亮一样有阴晴圆缺，有周期变化。例如在线业务，尤其是交易业务，它们在资源使用上呈现一定的周期性，例如：在凌晨、上午时，它的使用量并不是很高，而在午间、下午时会比较高。

打个比方：对于 A 应用的重要时刻，对于 B 应用可能不那么重要，适当打压 B 应用，腾挪出资源给 A 应用，这是个不错的选择。这听起来有点像是分时复用的感觉。但是如果我们按照流量峰值时的需求配置资源就会产生大量的浪费。


除了对于实时性要求很高的在线应用外，我们还有离线应用和实时计算应用等：离线计算对于 CPU 、Memory 或网络资源的使用以及时间不那么敏感，所以在任何时间段它都可以运行；实时计算，可能对于时间敏感性就会很高。

早期，我们业务是在不同的节点按照应用的类型独立进行部署。从上面这张图来看，如果它们进行分时复用资源，针对实时性这个需求层面，我们会发现它实际的最大使用量不是 2+2+1=5，而是某一时刻重要紧急应用需求量的最大值，也就是 3 。如果我们能够数据监测到每个应用的真实使用量，给它分配合理值，那么就能产生资源利用率提升的实际效果。

对于电商应用，对于采用了重量级 Java 框架和相关技术栈的 Web 应用，短时间内 HPA 或者 VPA 都不是件容易的事情。

先说 HPA，我们或许可以秒级拉起了 Pod，创建新的容器，然而拉起的容器是否真的可用呢。从创建到可用，可能需要比较久的时间，对于大促和抢购秒杀-这种访问量“洪峰”可能仅维持几分钟或者十几分钟的实际场景，如果我们等到 HPA 的副本全部可用，可能市场活动早已经结束了。

至于社区目前的 VPA 场景，删掉旧 Pod，创建新 Pod，这样的逻辑更难接受。所以综合考虑，我们需要一个更实际的解决方案弥补 HPA 和 VPA 的在这一单机资源调度的空缺。

解决方案
====

交付标准
----

我们首先要对解决方案设定一个可以交付的标准那就是—— “既要稳定性，也要利用率，还要自动化实施，当然如果能够智能化那就更好”，然后再交付标准进行细化：

*   安全稳定：工具本身高可用。所用的算法和实施手段必须做到可控；
*   业务容器按需分配资源：可以及时根据业务实时资源消耗对不太久远的将来进行资源消耗预测，让用户明白业务接下来对于资源的真实需求；
*   工具本身资源开销小：工具本身资源的消耗要尽可能小，不要成为运维的负担；
*   操作方便，扩展性强：能做到无需接受培训即可玩转这个工具，当然工具还要具有良好扩展性，供用户 DIY；
*   快速发现 & 及时响应：实时性，也就是最重要的特质，这也是和HPA或者VPA在解决资源调度问题方式不同的地方。

设计与实现
-----


上图是我们最初的工具流程设计：当一个应用面临很高的业务访问需求时，体现在 CPU、Memory 或其他资源类型需求量变大，我们根据 Data Collector 采集的实时基础数据，利用 Data Aggregator 生成某个容器或整个应用的画像，再将画像反馈给 Policy engine。 Policy engine 会瞬时快速修改容器 Cgroup 文件目录下的的参数。

我们最早的架构和我们的想法一样朴实，在 kubelet 进行了侵入式的修改。虽然我们只是加了几个接口，但是这种方式确实不够优雅。每次 kubenrnetes 升级，对于 Policy engine 相关组件升级也有一定的挑战。


为了做到快速迭代并和 Kubelet 解耦，我们对于实现方式进行了新的演进。那就是将关键应用容器化。这样可以达到以下功效：

*   不侵入修改 K8s 核心组件；
*   方便迭代&发布；
*   借助于 Kubernetes 相关的 QoS Class 机制，容器的资源配置，资源开销可控。

当然在后续演进中，我们也在尝试和 HPA，VPA 进行打通，毕竟这些和 Policy engine 存在着互补的关系。因此我们架构进一步演进成如下情形。当 Policy engine 在处理一些更多复杂场景搞到无力时，上报事件让中心端做出更全局的决策。水平扩容或是垂直增加资源。


下面我们具体讨论一下 Policy engine 的设计。Policy engine 是单机节点上进行智能调度并执行 Pod 资源调整的核心组件。它主要包括 api server，指挥中心 command center 和执行层 executor。

*   其中 api server 用于服务外界对于 policy engine 运行状态的查询和设置的请求；
*   command center 根据实时的容器画像和物理机本身的负载以及资源使用情况，作出 Pod 资源调整的决策；
*   Executor 再根据 command center 的决策，对容器的资源限制进行调整。同时，executor 也把每次调整的 revision info 持久化，以便发生故障时可以回滚。

指挥中心定期从 data aggregator 获取容器的实时画像，包括聚合的统计数据和预测数据，首先判断节点状态，例如节点磁盘异常，或者网络不通，表示该节点已经发生异常，需要保护现场，不再对Pod进行资源调整，以免造成系统震荡，影响运维和调试。如果节点状态正常，指挥中心会策略规则，对容器数据进行再次过滤。比如容器 CPU 率飙高，或者容器的响应时间超过安全阈值。如果条件满足，则对满足条件的容器集合给出资源调整建议，传递给executor。

在架构设计上，我们遵循了以下原则：

*   插件化：所有的规则和策略被设计为可以通过配置文件来修改，尽量与核心控制流程的代码解耦，与 data collector 和 data aggregator 等其他组件的更新和发布解耦，提升可扩展性；
*   稳定，这包括以下几个方面：
   
    *   控制器稳定性。指挥中心的决策以不影响单机乃至全局稳定性为前提，包括容器的性能稳定和资源分配稳定。例如，目前每个控制器仅负责一种 cgroup 资源的控制，即在同一时间窗口内，Policy engine 不同时调整多种资源，以免造成资源分配震荡，干扰调整效果；
    *   触发规则稳定性。例如，某一条规则的原始触发条件为容器的性能指标超出安全阈值，但是为避免控制动作被某一突发峰值触发而导致震荡，我们把触发规则定制为：过去一段时间窗口内性能指标的低百分位超出安全阈值；如果规则满足，说明这段时间内绝大部分的性能指标值都已经超出了安全阈值，就需要触发控制动作了；
    *   另外，与社区版  Vertical-Pod-Autoscaler 不同，Policy engine 不主动驱逐腾挪容器，而是直接修改容器的 cgroup 文件；

*   自愈：资源调整等动作的执行可能会产生一些异常，我们在每个控制器内都加入了自愈回滚机制，保证整个系统的稳定性；
*   不依赖应用先验知识：为所有不同的应用分别进行压测、定制策略，或者提前对可能排部在一起的应用进行压测，会导致巨大开销，可扩展性降低。我们的策略在设计上尽可能通用，尽量采用不依赖于具体平台、操作系统、应用的指标和控制策略。

在资源调整方面，Cgroup 支持我们对各个容器的 CPU、内存、网络和磁盘 IO 带宽资源进行隔离和限制，目前我们主要对容器的 CPU 资源进行调整，同时在测试中探索在时分复用的场景下动态调整 memory limit 和 swap usage 而避免 OOM 的可行性；在未来我们将支持对容器的网络和磁盘 IO 的动态调整。

调整效果
----


上图展示了我们在测试集群得到的一些实验结果。我们把高优先级的在线应用和低优先级的离线应用混合部署在测试集群里。SLO 是 250ms，我们希望在线应用的 latency 的 95 百分位值低于阈值 250ms。

在实验结果中可以看到：

*   在大约90s前，在线应用的负载很低；latency 的均值和百分位都在 250ms 以下；
*   到了  90s后，我们给在线应用加压，流量增加，负载也升高，导致在线应用 latency 的 95 百分位值超过了 SLO；
*   在大约 150s 左右，我们的小步快跑控制策略被触发，渐进式地 throttle 与在线应用发生资源竞争的离线应用；
*   到了大约 200s 左右，在线应用的性能恢复正常，latency 的 95 百分位回落到 SLO 以下。

这说明了我们的控制策略的有效性。

经验和教训
=====

下面我们总结一下在整个项目的进行过程中，我们收获的一些经验和教训，希望这些经验教训能够对遇到类似问题和场景的人有所帮助。

1.  避开硬编码，组件微服务化，不仅便于快速演进和迭代，还有利于熔断异常服务。
2.  尽可能不要调用类库中还是 alpha 或者 beta 特性的接口。 例如我们曾经直接调用 CRI 接口读取容器的一些信息，或者做一些更新操作，但是随着接口字段或者方法的修改，共建有些功能就会变得不可用，或许有时候，调用不稳定的接口还不如直接获取某个应用的打印信息可能更靠谱。
3.  基于 QoS 的资源动态调整方面：如我们之前所讲，阿里集团内部有上万个应用，应用之间的调用链相当复杂。应用 A 的容器性能发生异常，不一定都是在单机节点上的资源不足或者资源竞争导致，而很有可能是它下游的应用 B、应用 C，或者数据库、cache 的访问延迟导致的。由于单机节点上这种信息的局限性，基于单机节点信息的资源调整，只能采用“尽力而为”，也就是 best effort 的策略了。在未来，我们计划打通单机节点和中心端的资源调控链路，由中心端综合单机节点上报的性能信息和资源调整请求，统一进行资源的重新分配，或者容器的重新编排，或者触发 HPA，从而形成一个集群级别的闭环的智能资源调控链路，这将会大大提高整个集群维度的稳定性和综合资源利用率。
4.  资源v.s.性能模型：可能有人已经注意到，我们的调整策略里，并没有明显地提出为容器建立“资源v.s.性能”的模型。这种模型在学术论文里非常常见，一般是对被测的几种应用进行了离线压测或者在线压测，改变应用的资源分配，测量应用的性能指标，得到性能随资源变化的曲线，最终用在实时的资源调控算法中。在应用数量比较少，调用链比较简单，集群里的物理机硬件配置也比较少的情况下，这种基于压测的方法可以穷举到所有可能的情况，找到最优或者次优的资源调整方案，从而得到比较好的性能。但是在阿里集团的场景下，我们有上万个应用，很多重点应用的版本发布也非常频繁，往往新版本发布后，旧的压测数据，或者说资源性能模型，就不适用了。另外，我们的集群很多是异构集群，在某一种物理机上测试得到的性能数据，在另一台不同型号的物理机上就不会复现。这些都对我们直接应用学术论文里的资源调控算法带来了障碍。所以，针对阿里集团内部的场景，我们采用了这样的策略：不对应用进行离线压测，获取显示的资源性能模型。而是建立实时的动态容器画像，用过去一段时间窗口内容器资源使用情况的统计数据作为对未来一小段时间内的预测，并且动态更新；最后基于这个动态的容器画像，执行小步快跑的资源调整策略，边走边看，尽力而为。

总结与展望
=====

总结起来，我们的工作主要实现了以下几方面的收益：

*   通过分时复用以及将不同优先级的容器（也就是在线和离线任务）混合部署，并且通过对容器资源限制的动态调整，保证了在线应用在不同负载情况下都能得到足够的资源，从而提高集群的综合资源利用率。
*   通过对单机节点上的容器资源的智能动态调整，降低了应用之间的性能干扰，保障高优先级应用的性能稳定性
*   各种资源调整策略通过 Daemonset 部署，可以自动地、智能地在节点上运行，减少人工干预，降低了运维的人力成本。

展望未来，我们希望在以下几个方面加强和扩展我们的工作：

*   闭环控制链路：前面已经提到，单机节点上由于缺乏全局信息，对于资源的调整有其局限性，只能尽力而为。未来，我们希望能够打通与 HPA 和 VPA 的通路，使单机节点和中心端联动进行资源调整，最大化弹性伸缩的收益。
*   容器重新编排：即使是同一个应用，不同容器的负载和所处的物理环境也是动态变化的，单机上调整 pod 的资源，不一定能够满足动态的需求。我们希望单机上实时容器画像，能够为中心端提供更多的有效信息，帮助中心端的调度器作出更加智能的容器重编排决策。
*   策略智能化：我们现在的资源调整策略仍然比较粗粒度，可以调整的资源也比较有限；后续我们希望让资源调整策略更加智能化，并且考虑到更多的资源，比如对磁盘和网络IO带宽的调整，提高资源调整的有效性。
*   容器画像精细化：目前的容器画像也比较粗糙，仅仅依靠统计数据和线性预测；刻画容器性能的指标种类也比较局限。我们希望找到更加精确的、通用的、反映容器性能的指标，以便更加精细地刻画容器当前的状态和对不同资源的需求程度。
*   查找干扰源：我们希望能找到在单机节点上找到行之有效的方案，来精准定位应用性能受损时的干扰源；这对策略智能化也有很大意义。

Q & A
=====

**Q1：**直接修改 cgroup 容器一定会获得资源吗？ 
**A1：**容器技术隔离的技术基础就是 cgroup 层面。在宿主机腾出足够资源的情况下，给 cgroup 设置更大的值可以获取更多的资源。同理，对于一般优先级不高的应用，设置较低的 cgroup 资源值就会达到抑制容器运行的效果。

**Q2：**底层是如何区分在线和离线优先级的？ 
**A2：**底层是无法自动获取谁是在线，谁是离线，或者谁的优先级高，谁的优先级低的。这个我们可以通过各种 Kubernetes 提供的扩展实现。最简单的是通过 label，Annotation 标识。当然通过扩展 QoS class 也是一种思路。社区版本的 QoS class设置太过于保守，给予用户发挥的空间不大。我们通过这些方面也进行了增强。在合适的时候或许会推向社区。自动感知是个方向，感知谁是干扰源，感知谁是某种资源型应用，这块我们还在研发中。做到真正的动态，肯定是具备自动感知的智能系统。

**Q3：**“与社区版  Vertical-Pod-Autoscaler 不同，Policy engine 不主动驱逐腾挪容器，而是直接修改容器的 cgroup 文件”，想问一下，不主动驱逐的话，如果 Node 的资源达到上线了会怎么处理？ 
**A3：**这是一个好问题。首先这里要先区分是哪种资源，如果是 CPU 型的，我们可以调整低优先级容器的 cgroup 下 cpu quota 的值，首先抑制低优先级的容器对于 CPU 的争抢。然后再适当上调高优先级容器的相关资源值。如果是内存型资源，这个不能直接去缩小低优先级容器的 cgroup 值，否则会造成 OOM，对于学习内存型资源的调整，我们会在其他分享中继续讨论。这个技术比较特殊。

**Q4：**只修改 cgroup，怎么保证 K8s 对单个物理机能够分配更多的容器？ 
**A4：**文字直播有了一定说明，容器的资源消耗并非是一成不变的，很多时候它们的资源消耗呈现潮汐现象，相同的资源条件下部署更多应用，完成更多作业就是达到资源利用的最大化的效果。资源出现超卖才是我们这个主题讨论的最大价值。

**Q5：**也就是说，低优先级的容器，request 设置的比 limit 小很多，然后你们再动态的调整 cgroup？ 
**A5：**在现有 QoS 场景下，你可以理解被调整的 Pod 都是 burstable 的。但是我们并不是直接调整 Pod 元数据的 limit 的值，而是调整 limit 在 cgroup 反映的值，这个值在资源竞争缓和的时候还会被调整回去的。我们并不建议单机的 cgroup 数据和 etcd 的中心数据割裂太久。如果长期偏离，我们会像 VPA 发出警报，联动 VPA 做调整。当然在容器运行的高峰期，任何重建容器的操作都是不明智的。

**Q6：**整体的理解就是你们开始就让物理机超配了一定比例的 pod，然后通过策略动态调整容器的 cgroup 值？ 
**A6：**如果资源完全是富足冗余的，这个动态调整也有一定意义。就是并非资源用满场景下，高优先级应用会被干扰，实际上，当主机的 CPU 达到一定比例，打个比方例如 50%，应用的时延就变大。为了完全确保高优先级应用的 SLO，牺牲低优先级的 CPU 正常运行也是有价值的。

**Q7:**Policy engine 有没有考虑开源？ 
**A7：**有计划进行开源，Policy engine 更多的是和自身的应用属性相关，电商应用或者大数据处理应用的策略都是不相同的，我们开源会首先开源框架和附带一些简单的策略，更多的策略可以用户自定义。

**Q8：**我之前遇到的大部分应用都无法正确感知 cgroup 的配置，因此很多情况都需要在启动参数里面根据 cpu 或者 mem 设置参数，那么也就是说即使改变了 cgroup 对于他们来说都无效，那么使用场景也就有限了 
**A8：**限制容器的资源使用这个还是有价值的。限制低优先级应用本身也可以提升高优先级应用的 SLO，虽然效果没有那么明显。稳定性的考量同样也很重要。

**Q9:**Policy engine 目前在阿里的使用如何？在生产上有多上的规模使用这种方式进行动态调整？是否和社区的 HPA VPA 配合使用？ 
**A9: **Policy engine 在阿里某些集群已经使用。至于规模暂时无法透漏。涉及到很多组件之间的联动，社区的 HPA 和 VPA 目前都不太能满足我们的需求。因此阿里的 HPA 和 VPA 都是我们自行开发的，但是和社区的原理是一致的。阿里 HPA 的开源可以关注 Openkruise 社区。VPA 开源计划我这里还没有确切消息。

 
**Q10：**当单机节点资源不足以提供容器扩容时，目前是否可以进行 HPA 或 VPA 扩容呢？ 
**A10：**单机节点不足的时候，应用可以通过 HPA 进行增加副本应对。但是 VPA 如果选择原节点进行更新的话，是失败的。只能调度到其他资源丰富的节点。在流量陡升的场景下，重建容器未必能满足需求，很可能导致雪崩，即重建过程中，整个应用其他未升级的副本接受更多流量，OOM 掉，新启动的容器再瞬间被 OOM，所以重启容器需要慎重。快速扩容（HPA）或者快速提升高优先级资源，抑制低优先级容器资源的方式效果更明显。

本文作者：张晓宇（衷源）  阿里云容器平台技术专家

[原文链接](https://link.zhihu.com/?target=https%3A//yq.aliyun.com/articles/719845%3Futm_content%3Dg_1000079633)

本文为云栖社区原创内容，未经允许不得转载。