Find the Busiest Backend Pod 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. kubectl top needs the Metrics API, normally provided by metrics-server.

Read live CPU and memory usage with kubectl top

Requests and limits describe what a container is allowed; kubectl top shows what it is actually using right now. Metrics Server collects that usage from every kubelet and publishes it through the metrics.k8s.io API, and kubectl top reads it from there. Exam questions about "the busiest Pod" are really questions about filtering and sorting this one view correctly.

container ──→ kubelet ──→ metrics-server ──→ metrics.k8s.io API ──→ kubectl top
                       (scrapes about every 15s)

1. Create Pods with different appetites

The burner container spins in a shell loop but has a 250m CPU limit, so its usage should settle near a quarter of a core. Its neighbour only sleeps. Save this as duo.yaml.

apiVersion: v1
kind: Pod
metadata:
  name: duo
  namespace: prepium-tutorial
  labels:
    role: batch
spec:
  containers:
  - name: burner
    image: busybox:1.36
    command: ["sh", "-c", "while true; do :; done"]
    resources:
      limits:
        cpu: 250m
  - name: napper
    image: busybox:1.36
    command: ["sleep", "3600"]

kubectl create namespace prepium-tutorial
kubectl apply -f duo.yaml
kubectl -n prepium-tutorial run calm --image=busybox:1.36 --labels=role=batch -- sleep 3600
kubectl -n prepium-tutorial run front --image=nginx:1.27-alpine --labels=role=web

Give the pipeline a minute or two. Right after a Pod starts, kubectl top may report that metrics are not yet available.

2. Filter first, then sort

kubectl -n prepium-tutorial top pod
kubectl -n prepium-tutorial top pod -l role=batch
kubectl -n prepium-tutorial top pod -l role=batch --sort-by=cpu
kubectl -n prepium-tutorial top pod -l role=batch --sort-by=memory

The selector narrows the list to the Pods you were asked about, so a busy Pod with the wrong label cannot win by accident. --sort-by accepts cpu or memory and orders the rows by that column. Read the numbers to confirm which row is the top consumer rather than trusting position alone, and take a fresh sample just before you record an answer, because the values move.

3. Look inside a multi-container Pod

kubectl -n prepium-tutorial top pod duo --containers

A Pod figure is the sum of its containers. --containers splits it per container, which is how you prove that burner, not napper, is responsible. Expect burner to hover near 250m: once usage reaches the CPU limit the container is throttled rather than allowed more.

4. Read the units correctly

The CPU column is in cores, so 250m means 250 millicpu (also called millicores), a quarter of one core. Memory is a byte quantity; a suffix such as Mi is a mebibyte (1,048,576 bytes), while a lowercase m on memory would mean millibytes. To see the raw values behind the table, query the API directly:

kubectl get --raw /apis/metrics.k8s.io/v1beta1/namespaces/prepium-tutorial/pods/duo

The JSON lists each container's usage, with CPU often in nanocores (n) and memory in Ki, plus the window over which CPU was averaged. Memory is the working set at collection time, not a peak.

Common mistakes

• Reporting requests or limits from kubectl describe when the question asks for measured usage.
• Forgetting -n or the label selector, so the "busiest" Pod comes from the wrong namespace or tier.
• Comparing Pod totals when the question is about containers inside one Pod.
• Asking for metrics seconds after creating a Pod and concluding metrics-server is broken. Wait a scrape cycle and retry; if kubectl top node also fails, then check the metrics-server Pods (usually in kube-system).

Cleanup: kubectl delete namespace prepium-tutorial. References: kubectl top pod, Resource metrics pipeline, Resource Management for Pods and Containers, metrics-server. Next, try requests and limits or autoscaling on CPU.