Resource Monitoring with kubectl top

In one line

kubectl top gives you real, live CPU and memory usage for nodes and pods — the fastest way to answer 'is something actually using too much' without needing a full observability stack set up.

0/4 · 0%

Key ideas

01
kubectl top nodes and kubectl top pods show ACTUAL, real-time CPU and memory usage — distinct from the CONFIGURED requests/limits (Phase 4.1), which only describe what's been reserved or capped, not what's genuinely being consumed right now. Comparing the two together (actual usage vs configured request/limit) is the core diagnostic technique this topic is built around.
02
Both commands depend on the METRICS-SERVER component being installed and running in the cluster — without it, kubectl top fails outright with a clear error rather than silently showing wrong data; confirming metrics-server is running (kubectl get deployment metrics-server -n kube-system) is the first troubleshooting step if top isn't working at all.
03
kubectl top nodes reveals whether a NODE is running hot overall — genuinely useful context before investigating any individual pod's OOMKilled or CPU-throttling symptoms, since a node under genuine pressure from OTHER workloads can affect pods that are themselves perfectly well-behaved and correctly configured.
04
kubectl top pods --sort-by=memory (or cpu) sorts the output, immediately surfacing the biggest consumers across a namespace or cluster — genuinely the fastest way to answer 'what's actually using the most resources right now' without needing to eyeball a long, unsorted list manually.
05
kubectl top pods --containers breaks usage down PER CONTAINER within multi-container pods (Phase 0.3's sidecar pattern) — essential when a pod's TOTAL usage looks high, but you need to know specifically whether the main application or a sidecar container is actually responsible for it.
06
This topic's tools are genuinely useful for quick, live, point-in-time investigation, but they show only the CURRENT moment — they have no memory of what usage looked like an hour or a day ago. A real production setup pairs kubectl top's live snapshot with a genuine metrics pipeline (Prometheus and Grafana, covered in the DevOps roadmap's own Observability sections, beyond this Kubernetes-focused course) for actual historical trends and alerting.

Code & diagrams

top-diagnostics.shmarkdown

The fastest real diagnostic loop for 'what's using too much, right now.'

# Confirm metrics-server is actually installed and running
kubectl get deployment metrics-server -n kube-system

# Is any NODE under real pressure overall?
kubectl top nodes

# Which PODS are using the most, right now, cluster-wide?
kubectl top pods -A --sort-by=memory
kubectl top pods -A --sort-by=cpu

# Break down usage per container in a multi-container pod
kubectl top pod my-app-with-sidecar --containers

# Compare a specific pod's ACTUAL usage against its CONFIGURED request/limit
kubectl top pod my-app-7f8b9
kubectl get pod my-app-7f8b9 -o jsonpath='{.spec.containers[0].resources}'
# if actual usage is consistently near or above the limit, that's your OOMKilled/throttling candidate

Explain it without notes

Why does kubectl top fail with an error on some clusters, rather than just showing zero or wrong usage numbers?

You suspect one specific pod is responsible for a node running unusually hot. What's the fastest way to confirm or rule this out?

Practice

Run kubectl top nodes and kubectl top pods -A --sort-by=memory on any cluster you have access to, and identify the single largest consumer.

For that largest-consuming pod, compare its actual usage (from top) against its configured request and limit (from kubectl get pod -o jsonpath) — is it over, under, or right at its configured values?

Trade-offs

↔
kubectl top is fast, requires minimal setup (just metrics-server), and needs zero additional infrastructure — but it only ever shows the CURRENT moment, with no historical record, no alerting, and no way to see a trend over time; for genuinely production-grade observability (catching a slow memory leak over days, alerting automatically before a real OOMKilled event happens), a real metrics pipeline (Prometheus/Grafana) is necessary, with kubectl top remaining a fast, complementary tool for live, in-the-moment investigation even after that's in place.

Done when you can

I can use kubectl top nodes and kubectl top pods to see real, live resource usage.
I know kubectl top depends on metrics-server being installed and running.
I can compare a pod's actual usage against its configured request/limit to judge whether it's correctly sized.