PromQL for top 5 CPU-consuming pods

WHAT THIS TESTS This verifies practical PromQL skill, especially that you know cumulative counters must be turned into rates before aggregation.

A GOOD ANSWER COVERS container_cpu_usage_seconds_total is a monotonically increasing counter of CPU seconds consumed, exported per container by cAdvisor. Reading it raw is meaningless because it only ever grows. You first apply rate over a window: rate(container_cpu_usage_seconds_total[15m]) yields the per-second increase, which equals CPU cores used. Because a pod can have multiple containers, you aggregate with sum by (pod): sum by (pod) (rate(container_cpu_usage_seconds_total[15m])). Finally you select the busiest with topk: topk(5, sum by (pod) (rate(container_cpu_usage_seconds_total[15m]))). The rate function also gracefully handles counter resets when a container restarts. You might add a label filter like namespace= to scope it, or use irate for spikier instantaneous values, but rate over 15m matches the average-over-15-minutes ask.

COMMON WRONG ANSWERS Using the bare counter without rate gives ever-growing totals, not usage. Using avg instead of sum by pod across containers can understate a multi-container pod. Forgetting to aggregate, so topk returns top containers not top pods. Mismatching the window in brackets with the intended period.

LIKELY FOLLOW-UPS Difference between rate and irate. Why counters reset and how rate copes. How to convert cores to a percentage of limits.

ONE CONCRETE EXAMPLE topk(5, sum by (pod) (rate(container_cpu_usage_seconds_total[15m]))) returns the five pods burning the most CPU cores on average over the last 15 minutes, the right answer for a CPU hot-spot investigation.