Find the CPU-Heavy Workload with kubectl top

Original Prepium guide · Written for Kubernetes v1.35 and checked against the official documentation on 6 October 2026. Use a disposable practice cluster. Metrics Server is not part of a default Kubernetes install, so confirm it is running before you start.

Measured usage versus requests: reading kubectl top correctly

A resource request is a promise the scheduler plans around; it says nothing about what a container is burning right now. Measured usage comes from a separate pipeline: Metrics Server scrapes each kubelet (every 15 seconds by default) and serves the results through the Metrics API, metrics.k8s.io, which kubectl top and the HorizontalPodAutoscaler read. When two workloads have identical requests, only kubectl top can tell you which one is busy.

kubelet (each node) ──→ metrics-server ──→ API server /apis/metrics.k8s.io ──→ kubectl top, HPA
Pod spec requests   ──→ scheduler (placement only, never "usage")

1. Confirm the pipeline is up

kubectl get apiservices | grep metrics.k8s.io
kubectl -n kube-system get deployment metrics-server
kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes | head -c 300; echo

The APIService should report as available. On v1.35 the Metrics API is served as v1beta1, so that raw path works; current upstream docs already show v1 for later releases, which is why the first command is the safer probe. If kubectl top errors, fix this layer first; nothing below will produce numbers.

2. Create two workloads with identical requests

kubectl create namespace prepium-tutorial
kubectl -n prepium-tutorial create deployment steady --image=nginx:1.27-alpine
kubectl -n prepium-tutorial set resources deployment steady --requests=cpu=50m,memory=32Mi --limits=cpu=200m,memory=64Mi
kubectl -n prepium-tutorial run cruncher --image=busybox:1.36 \
  --overrides='{"spec":{"containers":[
    {"name":"spin","image":"busybox:1.36","command":["sh","-c","while true; do :; done"],
     "resources":{"requests":{"cpu":"50m","memory":"32Mi"},"limits":{"cpu":"200m","memory":"64Mi"}}},
    {"name":"nap","image":"busybox:1.36","command":["sleep","86400"],
     "resources":{"requests":{"cpu":"50m","memory":"32Mi"},"limits":{"cpu":"200m","memory":"64Mi"}}}]}}'

Every container asks for the same 50m. Looking at the specs, or at the Allocated resources section of kubectl describe node, which sums requests and limits, you could not pick the busy one. Wait a minute or two: the documentation warns that a new Pod may have no metrics for the first few minutes.

3. Read Pod and container usage

kubectl -n prepium-tutorial top pods
kubectl -n prepium-tutorial top pods --sort-by=cpu
kubectl -n prepium-tutorial top pods --containers --sort-by=cpu

The first output has NAME, CPU(cores) and MEMORY(bytes) columns. With --sort-by=cpu, kubectl orders Pods from highest to lowest CPU. Expect cruncher near its 200m limit (CPU limits are enforced by throttling) and steady close to zero. With --containers a POD column is added and each container gets its own row; spin carries almost all of its Pod's usage while nap sits near zero. Note how the sort works here: Pods are ranked by their totals and containers are sorted inside each Pod, so in a namespace with several multi-container Pods the first row is not automatically the single busiest container. Read the numbers.

4. Read node usage

kubectl top nodes
kubectl top nodes --sort-by=memory --no-headers

Node rows show CPU(cores), CPU(%), MEMORY(bytes) and MEMORY(%). The percentages are relative to allocatable by default; --show-capacity switches them to raw capacity. Two runs a few seconds apart will rarely match exactly, because each value is a fresh sample.

Common mistakes

• Answering "which Pod is heaviest" from requests or limits. Those are configuration, not measurement; identical specs can hide very different usage.
• Running kubectl top seconds after creating a Pod and concluding it uses nothing, or getting an error that metrics are not yet available. Give the pipeline time.
• Assuming --containers --sort-by=cpu puts the busiest container first across the whole namespace. It ranks Pods first.
• Treating Metrics Server as a monitoring system. Its project page says it is built for autoscaling and kubectl top; trends and history need a dedicated monitoring stack.

Cleanup: kubectl delete namespace prepium-tutorial stops the CPU loop. References: Resource metrics pipeline, kubectl top pod, Resource management for Pods and containers, metrics-server. Next, try CPU-based autoscaling or resource requests under a quota.