GitLab Runner Kubernetes集群特定类CPU压力PromQL查询需求

问题背景 #

我们在Kubernetes中按CPU/内存请求划分不同资源类部署GitLab Runner，需要合适的PromQL查询来分析特定Runner类的高CPU压力——通过判断作业的上百分位数/分位数是否超出阈值，确定该类是否需要调整默认CPU/内存请求。

现有尝试的问题 #

我曾尝试两个查询，但都没完全匹配需求：

1. 时间维度分位数查询：

quantile_over_time(0.75,
  avg by (
    gitlab_runner_runner_powerclass,
    gitlab_runner_runner_feature
  )(jobs:cpu:utilization)[12h:]
) > 85

其中jobs:cpu:percent是粒度到作业ID和Runner作业Pod容器的记录规则，但这个查询会先对同一资源类的所有作业做时间维度的平均，再统计分位数，非工作时段无作业的空白数据会拉低整体结果，导致图表被“拉平”，不符合基于实际作业数据点分析的需求。

2. 四分位距查询：

quantile(<0.25 or 0.75>,
  (
    sum by (pod)
    (jobs:cpu:utilization{gitlab_runner_runner_powerclass="large"})
  / 
    sum by (pod)
    (kube_pod_container_resource_requests{resource="cpu"})
  )
)

这个查询能监控Q3-Q1的异常分布，但不是我核心关注的“作业负载分位数是否超阈值”的需求。

符合需求的PromQL方案 #

核心要解决的是：只统计有作业运行的实际数据，避免无作业时段干扰，同时聚焦特定Runner类的作业负载峰值分位数。

方案1：特定Runner类的作业CPU峰值75分位数 #

直接基于每个作业Pod的CPU利用率峰值，统计指定时间窗口内的75分位数，反映75%的作业最高负载水平：

quantile(0.75,
  max_over_time(
    jobs:cpu:utilization{gitlab_runner_runner_powerclass="large"}[1h:]
  ) by (pod)
)

• 细节说明：
  • max_over_time(...) by (pod)：获取每个作业Pod在1小时窗口内的CPU利用率峰值（如果作业运行时间短，可调整为15m），确保每个作业只取其最高负载值，避免重复统计低负载时段数据。
  • quantile(0.75, ...)：对所有符合条件的作业Pod峰值计算75分位数，能直观看到多数作业的最高压力上限。
  • 替换gitlab_runner_runner_powerclass="large"为你要分析的资源类即可。

方案2：利用率占请求比例的75分位数（更直观判断资源是否不足） #

如果需要对比实际负载和资源请求的比例，判断当前请求是否合理：

quantile(0.75,
  (
    max_over_time(
      jobs:cpu:utilization{gitlab_runner_runner_powerclass="large"}[1h:]
    ) by (pod)
  )
  /
  (
    kube_pod_container_resource_requests{resource="cpu", gitlab_runner_runner_powerclass="large"}
    * on(pod) group_left()
    max_over_time(kube_pod_status_ready{condition="true"}[1h:]) by (pod)
  )
)

• 细节说明：
  • 分子是每个作业Pod的CPU利用率峰值，分母是该Pod的CPU请求值，通过max_over_time(kube_pod_status_ready...)确保只统计运行中Pod的请求值，排除无作业Pod干扰。
  • 若结果超过85%，说明75%的作业接近或耗尽了请求的CPU资源，需要考虑调高该类Runner的默认CPU请求。

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