基于PromQL查询OpenShift中Pod的资源请求与限额历史均值

核心逻辑 #

以4-5周（30-35天）的历史监控数据为基础，通过分位数统计确定合理阈值：

• 资源请求（request）：取P90/P95分位数，平衡资源保障与利用率，避免过度分配
• 资源限额（limits）：取P99.9/P99.99分位数，覆盖绝大多数峰值场景，减少Pod因资源超限被驱逐的概率

CPU资源查询 #

1. 单Pod级CPU使用分位数（按服务分组） #

histogram_quantile(0.90, sum(rate(container_cpu_usage_seconds_total{namespace="你的命名空间", pod=~"你的服务Pod前缀.*"}[5m])) by (pod, le))

• 替换0.90为0.999即可得到CPU限额参考值
• 在Prometheus查询界面设置时间范围为30d或35d

2. 服务级CPU聚合分位数 #

histogram_quantile(0.90, sum(rate(container_cpu_usage_seconds_total{namespace="你的命名空间", pod=~"你的服务Pod前缀.*"}[5m])) by (le))

聚合同服务下所有Pod的CPU数据，适合为整个服务设置统一的资源基准

内存资源查询 #

1. 单Pod级内存使用分位数（按服务分组） #

histogram_quantile(0.90, sum(rate(container_memory_usage_bytes{namespace="你的命名空间", pod=~"你的服务Pod前缀.*"}[5m])) by (pod, le))

• 替换0.90为0.999得到内存限额参考值
• 时间范围同样设置为30-35天

2. 服务级内存聚合分位数 #

histogram_quantile(0.90, sum(rate(container_memory_usage_bytes{namespace="你的命名空间", pod=~"你的服务Pod前缀.*"}[5m])) by (le))

聚合同服务所有Pod的内存数据，便于批量配置服务资源

实用提示 #

• 替换查询中的你的命名空间和你的服务Pod前缀为实际值；若需批量查询所有服务，可移除pod=~"..."过滤条件，仅保留namespace过滤
• OpenShift自带监控的指标可能略有差异，比如kube_pod_container_resource_usage_cpu_cores或kube_pod_container_resource_usage_memory_bytes，可根据实际监控指标调整
• 分位数可根据业务容忍度微调：请求值优先选P90-P95，限额值选P99.9-P99.99；可搭配avg_over_time(container_cpu_usage_seconds_total{...}[30d])辅助验证长期均值

内容的提问来源于stack exchange，提问作者user804401