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

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

关注『阿里巴巴云原生』公众号，回复关键词“1010”，可获取本文 PPT。

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

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

• 在预防维度，我们可以进行全链路的压力测试，并且提前通过科学的手段预判应用需要的副本数和资源量。如果没法准确预算资源，那就只采用冗余分配资源的方式了；

• 在兜底维度，我们可以在大规模访问流量抵达后，对不紧要的业务做服务降级并同时对主要应用进行临时扩容。

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

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

• 其中 api server 用于服务外界对于 policy engine 运行状态的查询和设置的请求；

• command center 根据实时的容器画像和物理机本身的负载以及资源使用情况，作出 Pod 资源调整的决策；

• Executor 再根据 command center 的决策，对容器的资源限制进行调整。同时，executor 也把每次调整的 revision info 持久化，以便发生故障时可以回滚。

• 插件化：所有的规则和策略被设计为可以通过配置文件来修改，尽量与核心控制流程的代码解耦，与 data collector 和 data aggregator 等其他组件的更新和发布解耦，提升可扩展性；

• 稳定，这包括以下几个方面：

• 控制器稳定性。指挥中心的决策以不影响单机乃至全局稳定性为前提，包括容器的性能稳定和资源分配稳定。例如，目前每个控制器仅负责一种 cgroup 资源的控制，即在同一时间窗口内，Policy engine 不同时调整多种资源，以免造成资源分配震荡，干扰调整效果；
• 触发规则稳定性。例如，某一条规则的原始触发条件为容器的性能指标超出安全阈值，但是为避免控制动作被某一突发峰值触发而导致震荡，我们把触发规则定制为：过去一段时间窗口内性能指标的低百分位超出安全阈值；如果规则满足，说明这段时间内绝大部分的性能指标值都已经超出了安全阈值，就需要触发控制动作了；
• 另外，与社区版  Vertical-Pod-Autoscaler 不同，Policy engine 不主动驱逐腾挪容器，而是直接修改容器的 cgroup 文件；

• 自愈：资源调整等动作的执行可能会产生一些异常，我们在每个控制器内都加入了自愈回滚机制，保证整个系统的稳定性；

• 不依赖应用先验知识：为所有不同的应用分别进行压测、定制策略，或者提前对可能排部在一起的应用进行压测，会导致巨大开销，可扩展性降低。我们的策略在设计上尽可能通用，尽量采用不依赖于具体平台、操作系统、应用的指标和控制策略；

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

• 避开硬编码，组件微服务化，不仅便于快速演进和迭代，还有利于熔断异常服务。

• 尽可能不要调用类库中还是 alpha 或者 beta 特性的接口。例如我们曾经直接调用 CRI 接口读取容器的一些信息，或者做一些更新操作，但是随着接口字段或者方法的修改，共建有些功能就会变得不可用，或许有时候，调用不稳定的接口还不如直接获取某个应用的打印信息可能更靠谱。

  
  

• 基于 QoS 的资源动态调整方面：如我们之前所讲，阿里集团内部有上万个应用，应用之间的调用链相当复杂。应用 A 的容器性能发生异常，不一定都是在单机节点上的资源不足或者资源竞争导致，而很有可能是它下游的应用 B、应用 C，或者数据库、cache 的访问延迟导致的。

  
  

  由于单机节点上这种信息的局限性，基于单机节点信息的资源调整，只能采用“尽力而为”，也就是 best effort 的策略了。在未来，我们计划打通单机节点和中心端的资源调控链路，由中心端综合单机节点上报的性能信息和资源调整请求，统一进行资源的重新分配，或者容器的重新编排，或者触发 HPA，从而形成一个集群级别的闭环的智能资源调控链路，这将会大大提高整个集群维度的稳定性和综合资源利用率。

• 资源 v.s. 性能模型：可能有人已经注意到，我们的调整策略里，并没有明显地提出为容器建立“资源 v.s. 性能”的模型。这种模型在学术论文里非常常见，一般是对被测的几种应用进行了离线压测或者在线压测，改变应用的资源分配，测量应用的性能指标，得到性能随资源变化的曲线，最终用在实时的资源调控算法中。

  在应用数量比较少，调用链比较简单，集群里的物理机硬件配置也比较少的情况下，这种基于压测的方法可以穷举到所有可能的情况，找到最优或者次优的资源调整方案，从而得到比较好的性能。但是在阿里集团的场景下，我们有上万个应用，很多重点应用的版本发布也非常频繁，往往新版本发布后，旧的压测数据，或者说资源性能模型，就不适用了。

  另外，我们的集群很多是异构集群，在某一种物理机上测试得到的性能数据，在另一台不同型号的物理机上就不会复现。这些都对我们直接应用学术论文里的资源调控算法带来了障碍。所以，针对阿里集团内部的场景，我们采用了这样的策略：不对应用进行离线压测，获取显示的资源性能模型。而是建立实时的动态容器画像，用过去一段时间窗口内容器资源使用情况的统计数据作为对未来一小段时间内的预测，并且动态更新；最后基于这个动态的容器画像，执行小步快跑的资源调整策略，边走边看，尽力而为。

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

• 闭环控制链路：前面已经提到，单机节点上由于缺乏全局信息，对于资源的调整有其局限性，只能尽力而为。未来，我们希望能够打通与 HPA 和 VPA 的通路，使单机节点和中心端联动进行资源调整，最大化弹性伸缩的收益；

• 容器重新编排：即使是同一个应用，不同容器的负载和所处的物理环境也是动态变化的，单机上调整 pod 的资源，不一定能够满足动态的需求。我们希望单机上实时容器画像，能够为中心端提供更多的有效信息，帮助中心端的调度器作出更加智能的容器重编排决策；

• 策略智能化：我们现在的资源调整策略仍然比较粗粒度，可以调整的资源也比较有限；后续我们希望让资源调整策略更加智能化，并且考虑到更多的资源，比如对磁盘和网络 IO 带宽的调整，提高资源调整的有效性；

• 容器画像精细化：目前的容器画像也比较粗糙，仅仅依靠统计数据和线性预测；刻画容器性能的指标种类也比较局限。我们希望找到更加精确的、通用的、反映容器性能的指标，以便更加精细地刻画容器当前的状态和对不同资源的需求程度；

• 查找干扰源：我们希望能找到在单机节点上找到行之有效的方案，来精准定位应用性能受损时的干扰源；这对策略智能化也有很大意义。