4. 资源画像概念与价值：什么是资源画像？CPU/Memory画像、利用率画像、请求画像的区别与联系
在Kubernetes弹性伸缩与成本优化实践中，资源画像（Resource Profiling）是连接实际负载特征与资源调度决策的核心桥梁。它并非单一指标，而是一组对工作负载资源使用行为的结构化描述与建模方法。理解资源画像，是后续进行多集群Deployment弹性伸缩策略设计与成本优化的认知前提。
4.1 什么是资源画像？
资源画像是对一个工作负载（如Deployment、StatefulSet）在特定时间窗口内，其资源需求特征与实际使用模式的数字化抽象。它回答三个关键问题：
- 需要多少？ —— 请求（Requests）与限制（Limits）的设定值。
- 用了多少？ —— 实际CPU、内存利用率的时间序列。
- 趋势如何？ —— 资源使用的周期性、峰值、均值与波动性。
一个完整的资源画像通常包含静态配置与动态行为两个维度，是集群管理员进行垂直伸缩（VPA）、水平伸缩（HPA）以及成本分配（Cost Allocation）的基础输入。
核心认知： 资源画像不是一次性的“快照”，而是持续演进的“行为模型”。它帮助我们从“黑盒调度”转向“数据驱动调度”。
4.2 三种核心画像类型：定义与特征
在Kubernetes生态中，资源画像通常被细分为三种具体类型，它们从不同视角描述工作负载的资源行为。
| 画像类型 | 核心定义 | 数据来源 | 典型用途 |
|---|---|---|---|
| CPU/Memory画像 | 描述工作负载在规格层面的资源配置，即Pod Spec中定义的requests与limits值。 | Deployment YAML、Pod Spec | 资源配额管理、集群容量规划、成本基准核算 |
| 利用率画像 | 描述工作负载在运行时层面的实际资源消耗，通常以时间序列（如1m、5m均值）呈现。 | Metrics Server、Prometheus、cAdvisor | HPA触发决策、VPA推荐计算、资源浪费识别 |
| 请求画像 | 描述工作负载对外服务请求的流量特征，如QPS、并发数、响应延迟分布。 | Ingress日志、Service Mesh指标、APM | 基于QPS的HPA、流量预测、弹性策略设计 |
4.3 三种画像的区别与联系
这三种画像并非孤立存在，它们构成了从配置层 → 运行时层 → 业务层的递进关系。理解其区别与联系，是构建精准弹性伸缩策略的关键。
4.3.1 核心区别
- 抽象层次不同： CPU/Memory画像属于静态配置层；利用率画像属于系统运行时层；请求画像属于业务语义层。
- 时间粒度不同： 配置画像变化极慢（版本发布时）；利用率画像变化较快（秒级到分钟级）；请求画像变化最快（毫秒级到秒级）。
- 优化目标不同： 配置画像追求合理性与合规性；利用率画像追求效率与饱和度；请求画像追求服务质量与吞吐。
4.3.2 内在联系
- 利用率画像是CPU/Memory画像的“验证器”：如果实际利用率长期远低于requests，说明配置画像存在过度预留。
- 请求画像是利用率画像的“驱动源”：业务请求量的变化直接导致CPU/内存利用率的变化。
- 三者共同构成弹性伸缩的闭环： 请求画像决定“是否需要扩缩”，利用率画像决定“扩缩多少”，CPU/Memory画像决定“扩缩后的资源上限”。
实践要点： 在成本优化场景中，我们通常先通过利用率画像识别浪费，再通过CPU/Memory画像调整requests，最后通过请求画像验证调整是否影响服务质量。
4.4 三种画像的关系架构图
下图展示了三种画像在Kubernetes弹性伸缩体系中的位置与数据流转关系：
4.5 从画像到成本优化的价值链路
资源画像在成本优化中的价值，体现在以下三个递进阶段：
- 可视化阶段： 通过利用率画像，将“看不见”的资源浪费（如CPU闲置、内存超配）转化为可视化的图表与指标。
- 归因阶段： 结合CPU/Memory画像与利用率画像，定位浪费来源——是requests设置过高，还是副本数过多导致低负载。
- 优化阶段： 基于请求画像的周期性特征，设计差异化的弹性策略（如白天高负载、夜间低负载），实现“按需供给”。
常见误区： 只关注利用率画像而忽略请求画像，会导致弹性策略对业务突发流量响应滞后；只关注CPU/Memory画像而忽略利用率画像，则容易陷入“静态配置优化”的局部最优，无法实现真正的动态成本控制。
4.6 三种画像的典型数据对比示例
以下是一个典型Web应用Deployment的三种画像数据对比，展示它们之间的差异与关联：
| 指标维度 | CPU/Memory画像（配置） | 利用率画像（运行时） | 请求画像（业务） |
|---|---|---|---|
| CPU | requests: 500m limits: 1000m |
平均利用率: 120m 峰值利用率: 450m |
峰值QPS: 2000 req/s |
| Memory | requests: 512Mi limits: 1024Mi |
平均利用率: 280Mi 峰值利用率: 600Mi |
平均响应延迟: 45ms |
| 优化结论 | CPU requests过度预留（利用率仅24%） | 内存存在浪费，但峰值安全余量充足 | QPS波动较大，需要基于请求画像配置HPA |
通过上述对比可以清晰看到：配置画像告诉我们“承诺了多少”，利用率画像告诉我们“实际用了多少”，而请求画像告诉我们“为什么用这么多”。三者结合，才能制定出既保障服务质量、又最大化资源效率的弹性伸缩策略。