Kubernetes 集群运维中有一个非常普遍的现象：节点资源长期处于高申请、低使用的状态。通过 kubectl describe node 查看，Allocated resources 一栏可能显示 CPU 已经分发了 90% 以上，但实际的 CPU 使用率却常年徘徊在 10% 到 20% 之间。这中间的巨大落差，本质上是因为绝大多数工作负载的 requests 和 limits 是开发者凭感觉填写的，而不是基于真实负载数据得出的。资源画像（Resource Profiling）就是解决这个问题的核心手段，通过对历史运行数据的采集、统计和建模，为每个工作负载刻画出真实的资源需求曲线，进而给出科学的 right sizing 建议。
为什么资源配置不能靠拍脑袋
requests 的含义是调度器承诺给容器的资源保底量，它直接决定了 Pod 会被调度到哪个节点、节点还能塞下多少负载。如果 requests 设置得远高于实际使用，会造成两个后果：一是节点资源被大量闲置锁死，集群算力被白白浪费；二是水平扩容时明明节点还有空闲 CPU，调度器却因为可分配额度不足而拒绝调度，导致 Pod Pending。
反过来，requests 设置过低同样有风险。CPU 属于可压缩资源，requests 低于真实用量时容器会被限流（Throttling），表现为接口延迟抖动、P99 飙升。而内存属于不可压缩资源，一旦实际用量超过 limits，内核的 OOM Killer 会直接杀掉进程，引发非预期的重启。所以画像的核心目标，是为 CPU 和内存分别建立不同的分析策略：CPU 看分位数，内存看峰值并留出安全余量。
资源画像的数据采集与指标计算
做画像的第一步是拿到足够长时间粒度足够细的负载数据。Prometheus 加 node_exporter、kube-state-metrics 是最普遍的组合，核心指标有两个：container_cpu_usage_seconds_total（CPU 累计使用量，rate 之后得到实际核数）和 container_memory_working_set_bytes（内存工作集，这是 OOM 判断依据的口径，不要用 RSS）。
采集周期建议覆盖至少一个完整的业务周期，比如七天，这样能覆盖工作日与周末、高峰与低谷的不同形态。对 CPU 数据，通常计算 P50、P95、P99 三个分位数，观察长期均值和峰值之间的差距；对内存数据，则重点看峰值、均值以及增长趋势，尤其要留意是否存在缓慢的内存泄漏迹象——如果内存曲线呈锯齿状持续爬升，说明问题不在配置而在代码，单纯调大 limits 只是延缓爆炸时间。
下面是一个用 PromQL 统计各容器 CPU P95 用量的示例，可以直接作为画像数据源：
# 每个容器的实时 CPU 用量（核）
rate(container_cpu_usage_seconds_total{container!="",container!="POD"}[5m])
# 按容器聚合后求过去 7 天的 P95
quantile_over_time(0.95,
sum by (namespace, pod, container)(
rate(container_cpu_usage_seconds_total{container!="",container!="POD"}[5m])
)[7d:5m]
)如果你不想自己搭建统计逻辑，Vertical Pod Autoscaler 的 recommender 组件做的事情本质上是相同的：它默认基于 8 天的历史数据，用 P90 分位估算 CPU 建议值，用峰值乘以安全系数估算内存建议值，并将结果写入 VerticalPodAutoscaler 对象中，可以通过 kubectl describe vpa 直接查看建议值而不自动应用。
如何把画像数据转化为 sizing 建议
拿到分位数数据后，需要一套规则把它翻译成配置建议。业界常用的经验公式是：CPU requests 取 P95 到 P99 之间的值再乘以 1.1 到 1.2 的系数；内存 requests 取观测峰值乘以 1.2 到 1.5 的余量，limits 可以与 requests 相等或稍高。对于 Java 等有 GC 行为的应用，还要考虑堆外内存和 GC 期间的瞬时尖峰，余量系数需要进一步放大。
调整必须分批进行，切忌一次性全量修改。推荐的做法是先选择非核心的低风险服务试点，修改配置后观察一到两个业务周期，重点盯两类信号：一是 CPU throttling 指标（container_cpu_cfs_throttled_periods_total 的增长率）是否明显上升，二是 Pod 重启次数和 OOMKilled 事件是否出现。确认稳定后再逐步推广到核心服务。
对于不方便直接改 YAML 的存量服务，可以使用 VPA 的 InPlaceOrRecreate 模式，或者借助 kubectl 的 patch 命令批量调整：
# 批量查看某命名空间下所有容器的当前 requests 与实际用量对比
kubectl top pods -n production --containers --no-headers | \
awk '{printf "%s/%s cpu=%s mem=%s\n", $1, $2, $3, $4}'最后要建立持续画像机制而不是一次性运动。业务负载是动态变化的，建议每月或每季度重新跑一轮画像分析，把 requests 调整纳入常规的容量管理流程。对于短期突发型负载（如大促场景），可以考虑在 HPA 和 VPA 之间做组合：HPA 负责横向伸缩应对流量，VPA 或人工画像负责修正单体资源配置的基线，两者配合才能真正做到既不浪费又不牺牲稳定性。
Kubernetes资源画像资源优化right sizing修改时间：2026-09-12 05:18:29