资源画像，看得见的容器资源优化助手

关注

原创 2022-09-30 11:19:11 1.1k 阅读 AI 写同款· GEO 优化 ›

作者：张佐玮（佑祎）

背景介绍

K8s 为集群资源提供了良好的抽象，用户可以直接根据应用的资源需求填写容器资源规格，这种方式有效提升了集群资源的管理效率。然而，一直以来，容器资源规格填写的难题一直都让应用管理员们无法摆脱，过高的资源规格会导致资源浪费，而过低的规格又会为应用带来潜在的稳定性风险。

往期文章《资源画像，让容器资源规格的填写不再纠结》中我们介绍了阿里云容器服务 Kubernetes 版（Alibaba Cloud Container Service for Kubernetes，以下简称 ACK）提供的资源规格智能推荐功能，用户可以通过 ack-slo-manager 组件提供的 CRD 对象查询到容器的资源推荐值。

日前，ACK 控制台在此基础上正式发布了资源画像功能，为用户提供了可视化的交互页面，便于管理员快速分析应用资源规格的合理性，并进行资源规格配置的变更。该功能目前已经正式开放公测，ACK 用户可以直接申请白名单试用。

容器资源配置

K8s 使用了 request 和 limit 来描述容器对 CPU 和内存资源的需求，reqeust 影响 Pod 的节点分配结果，调度器会使用节点的“资源容量”（capacity）进行匹配，确保容量充足，而 limit 决定了容器在节点运行时可以使用的资源上限，当容器尝试超用资源时会被约束（throttled）甚至终止（kill）。

一直以来，容器资源规格 request 和 limit 的填写都让 K8s 的用户饱受困扰，一方面，应用管理员需要预留相当数量的资源冗余来应对上下游链路的负载波动，保障线上应用的稳定性；而另一方面的现实是，在大部分在线服务的生产环境中，集群的资源利用率处于相当低的水平，存在大量的资源浪费。

应用的资源画像数据可以提供有效帮助，所谓资源画像，指的是应用 CPU、内存等资源的使用特征，如果我们能够将资源使用的历史数据收集起来，并进行汇总分析，在设置容器资源规格时就可以做到有的放矢。ACK 控制台资源画像功能的发布，就旨在解决这一难题，帮助运维人员优化容器资源规格，提升管理效率，保障应用稳定运行的同时，充分提升集群资源使用率。

资源画像

ACK 资源画像会持续收集容器的资源用量进行汇总分析，为每个容器生成资源规格的推荐值，控制台会针对工作负载原始的资源请求量（request）给出调整建议，包括“升配”、“降配”、以及”保持“三种，若工作负载有多个容器，控制台会优先使用偏差幅度最大的容器作为推荐。应用管理员可以通过该页面直接筛选出需要调整的应用，并在详情页进行修改。

在这里插入图片描述

策略管理

资源画像支持按需开启的的管理策略，可以指定命名空间和应用类型范围。策略同时还支持为应用配置资源消耗冗余，所谓资源消耗冗余，对应的场景是管理员在评估应用业务容量时（例如 QPS），通常不会将物理资源使用到 100%。原因既包括超线程等物理资源的局限性，也包括应用自身需要考虑留有余量以应对高峰时段的负载请求。当资源画像的推荐值与原始资源请求的差距超过安全冗余时，才会提示降配建议。

在这里插入图片描述

资源用量分析

在资源画像控制台主页，点击工作负载名称，可以进入对应的画像详情页面，在画像详情页可以对应用的资源消耗数据做进一步的详细分析。详情页的资源曲线分别展示了各容器的资源限制值（limit）、资源请求值（request）、资源画像功能提供的推荐值（recommend），以及应用各副本资源使用量的平均值和最大值（average/max usage）。

通过应用的画像详情页，用户可以对资源使用情况进行直观的分析，评估容器当前的资源规格（request/limit）是否合理。

在这里插入图片描述

资源配置变更

画像详情页面底部还同时提供了资源变配的功能，变配窗口内默认展示了各容器当前的所需资源（request）和限制资源（limit），以及资源画像为容器生成的推荐值，推荐值来自于对容器资源消耗历史数据的聚合分析，确保推荐值可以尽量满足容器资源消耗的需求。这里同时还展示了策略管理中为应用配置的冗余系数，方便应用管理员在修改资源规格配置时参考。

在这里插入图片描述

填写完成后点击确定按钮，将执行资源规格更新操作并自动跳转到工作负载详情页。资源规格更新后，控制器会对工作负载进行滚动更新并重新创建 Pod。

使用建议

资源冗余配置

资源画像的变配建议是比较推荐值与当前应用资源申请量（request）得到的，当推荐值高于 request 时，说明容器实际的资源用量已经超过了申请量，应提高请求规格；而当推荐值低于 request 时，说明容器实际的资源用量低于请求量，但这并不代表着一定要降低请求规格。

原因是应用管理员在填写资源申请时，通常都会在原始的资源需求基础上额外增加一定程度的资源冗余，用于应对流量高峰，或是做例如“同城多活”这类高可用场景的切换。此外，部分应用还对资源较为敏感，无法在宿主机负载较高时平稳运行，这也需要在基础值上调高规格。

因此资源画像的变配建议会参考用户在策略管理中配置的冗余系数，只有当推荐值显著低于请求量时才会提示“降配”操作。冗余系数只影响资源变配的提示，不影响推荐值算法的计算过程，原因是资源画像提供的推荐值是对应用当前资源需求情况的总结，管理员在使用时应结合应用自身特性，在推荐值的基础之上进行加工。

在这里插入图片描述

应用适用类型

目前资源画像的推荐值会优先考虑满足容器的资源使用，确保可以覆盖绝大部分历史数据样本，因而更适用于在线类型的应用，因为它们通常以服务的形式部署，对响应时间（RT）会有严格的约束，要求资源必须及时得到满足。

与“在线”相对应的是“离线”应用，通常为批处理类型的任务，其更关注数据处理的整体吞吐量，可以接受一定程度的资源竞争，以提高集群资源的整体利用率，因此当前资源画像的推荐值对于离线应用来说会显得有些保守。此外，集群内还会有一些关键的系统组件，通常以“主备”的形式部署多个副本，处于“备份”角色的副本长期处于资源闲置状态。这些“备份”角色的资源用量样本数据会对画像算法产生一定程度的干扰，影响推荐值的准确性。

针对这些场景，管理员应基于应用特点对资源画像的推荐值二次加工后再使用，后续我们也将开放更多能力，提供更加精细的资源画像策略管理。

数据累积时长

资源画像推荐值的算法涉及一套多维度的数据模型，核心关注以下几个方面：

算法会持续不断的收集容器的资源用量数据，取 CPU 和内存的聚合统计值作为推荐。
针对样本数据的时间因素进行了优化，在聚合统计时，较新的数据采样点会拥有更高的权重。
算法参考了容器出现 OOM 等运行状态信息，可以进一步提高推荐值的准确性。

通过以上原理可以看出，资源画像结果的准确性会随着数据样本的累积逐渐提升，因此在初次使用时建议至少保持一天以上的数据累积。原因是当前互联网类型的在线应用会受到人们生产生活习惯的影响，流量负载的峰谷会在不同时间段出现，例如出行类应用会有早晚高峰，文娱类应用会在工作日和节假日的呈现不同特征。因此最好的使用方式，是确保工作负载稳定运行一段时间，收集的数据完整覆盖了流量的波峰波谷之后再使用。