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

作者：张佐玮（佑祎）

背景介绍

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）会有严格的约束，要求资源必须及时得到满足。

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

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

数据累积时长

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

1. 算法会持续不断的收集容器的资源用量数据，取 CPU 和内存的聚合统计值作为推荐。

2. 针对样本数据的时间因素进行了优化，在聚合统计时，较新的数据采样点会拥有更高的权重。

3. 算法参考了容器出现 OOM 等运行状态信息，可以进一步提高推荐值的准确性。

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

未来计划

ACK 资源画像控制台后续的产品功能已经在规划中，未来我们将提供更为精细化的管理策略以及更为便捷的使用方式，敬请期待！

往期文章《Koordinator 0.6：企业级容器调度系统解决方案，引入 CPU 精细编排、资源预留与全新的重调度框架》中我们介绍了云原生混部开源系统 Koordinator 的一系列功能，近期 Koordinator 刚刚发布了最新的 0.7 版本，欢迎大家访问官网"koordinaotr.sh"查阅。

接下来我们将逐步把资源画像相关的技术能力也贡献到开源社区，帮助更广大的行业人士改善云原生工作负载运行的效率、稳定性和计算成本。

Koordinator 是一个开放的社区，非常欢迎广大云原生爱好者们通过各种方式一起参与共建，无论您在 K8s 领域是初学乍练还是驾轻就熟，我们都非常期待听到您的声音！

Github 地址：https://github.com/koordinator-sh/koordinator

欢迎扫描下方微信二维码加入 Koordinator 微信群：

您也可以使用钉钉扫描下方二维码或搜索群号 33383887 加入 Koordinator 社区钉钉群：

点击此处，即可查看阿里云 ACK 资源画像控制台的详细介绍和使用方法！