Kubectl Top Pod: Monitor CPU and Memory Usage in Kubernetes

TLDR: kubectl top pod gives you a live snapshot of CPU (millicores) and memory (Mi/Gi) usage per pod, powered by the Metrics Server. Use it to spot resource-heavy pods, sort by --sort-by=cpu/--sort-by=memory, break usage down per container with --containers, and compare actual usage against configured requests/limits to catch over- or under-provisioning before it causes throttling or OOM kills.

In this article:

• Prerequisites for Using kubectl top pod
• Basic kubectl top pod Syntax
• kubectl top pod Use Cases
• How to Read kubectl top pod Output
• Best Practices for Using kubectl top pod

How to Read kubectl top pod Output

The output of kubectl top pod provides a snapshot of current CPU and memory usage for pods. Understanding the meaning of each column helps identify resource-heavy workloads and troubleshoot performance issues.

Example output:

NAME                      CPU(cores)   MEMORY(bytes)
nginx-6d4cf56db6-xk8rt    2m           15Mi
api-server-7f89c7d9d      25m          120Mi

The columns represent:

• NAME — The name of the pod
• CPU (cores) — Current CPU usage
• MEMORY (bytes) — Current memory consumption

CPU values are typically shown in millicores (m):

• 1000m equals 1 CPU core
• 250m equals 0.25 CPU cores

For example:

• 2m means the pod is using a very small amount of CPU
• 500m means the pod is consuming half a CPU core

Memory values are displayed using binary units:

• Ki = kibibytes
• Mi = mebibytes
• Gi = gibibytes

The values shown are current usage metrics collected by the Metrics Server. They are not historical averages and may change between command executions. Because of this, kubectl top pod is best suited for quick operational checks rather than long-term monitoring.

Outputs for containers:

When using the --containers flag, the output includes metrics for each container inside the pod:

kubectl top pod nginx-6d4cf56db6-xk8rt --containers

Example output:

POD                       NAME    CPU(cores)   MEMORY(bytes)
nginx-6d4cf56db6-xk8rt    nginx   2m           15Mi

Using top pod output to diagnose pod issues:

After identifying unusual resource consumption, compare actual usage against configured requests and limits. This helps determine whether pods are correctly sized or require tuning to improve performance and resource efficiency.

Best Practices for Using kubectl top pod

Here are some useful practices to consider when using this command.

1. Confirm Metrics Server Is Installed and Healthy

Before relying on kubectl top pod, verify that the Metrics Server is installed and functioning correctly in your cluster. You can check its status with kubectl get deployment metrics-server -n kube-system and inspect the logs for errors.

If the Metrics Server is misconfigured or unhealthy, kubectl top pod may return incomplete data or fail entirely. Regularly monitor the health of the Metrics Server to ensure resource metrics reflect the current state of your workloads.

Example:

kubectl --namespace=kube-system get deployment metrics-server

Output:

NAME             READY   UP-TO-DATE   AVAILABLE   AGE
metrics-server   1/1     1            1           45d

Verify metrics collection:

kubectl top nodes

Output:

NAME             CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
worker-node-1    420m         21%    3120Mi           39%
worker-node-2    365m         18%    2875Mi           36%

2. Always Check the Right Namespace

Kubernetes clusters often host multiple namespaces, each containing different workloads or environments. When using kubectl top pod, specify the correct namespace with the -n flag if you are not working in the default one.

Failing to specify the namespace can lead to missed issues or incorrect conclusions about resource usage. For example, you might overlook a resource spike in a staging environment if you only check the default namespace.

Example:

kubectl --namespace production top pod

Output:

NAME                        CPU(cores)   MEMORY(bytes)
frontend-76d9c7f7f5-qn9p8   65m          210Mi
backend-5c8b7d9f67-jh2wt    220m         580Mi
redis-0                     15m          140Mi

3. Sort by CPU or Memory to Find Noisy Pods Faster

Sorting pods by CPU or memory usage highlights those consuming the most resources. Use --sort-by=cpu or --sort-by=memory to bring the most resource-intensive pods to the top of the output. Reviewing pods based on resource consumption helps address bottlenecks and supports capacity planning.

Example:

kubectl top pods -n production --sort-by=memory

Output:

NAME                          CPU(cores)   MEMORY(bytes)
analytics-worker-7f4b7d5c8d   320m         1850Mi
api-server-6b8f4d5f4d         140m         720Mi
frontend-76d9c7f7f5           60m          220Mi

4. Compare Usage Against Requests and Limits

To interpret resource metrics, compare the actual usage reported by kubectl top pod to the requests and limits defined in pod specifications. If a pod frequently approaches its resource limits, it may experience throttling or eviction. Consistently low usage relative to requests suggests over-provisioning. This comparison helps teams adjust resource allocations and avoid issues such as OOMKills or CPU throttling.

Example:

View current usage:

kubectl -n production top pod api-server-6b8f4d5f4d

Output:

NAME                     CPU(cores)   MEMORY(bytes)
api-server-6b8f4d5f4d    850m         920Mi

Check configured resources:

kubectl -n production describe pod api-server-6b8f4d5f4d

Output (excerpt):

Limits:
  cpu:     1
  memory:  1Gi
Requests:
  cpu:     500m
  memory:  512Mi

In this example, the pod is approaching both CPU and memory limits and may require tuning.

5. Use Labels for Workload-Level Checks

Kubernetes labels enable you to filter and group pods by application, environment, or custom key. By combining kubectl top pod with the -l flag, you can monitor resource usage for a specific workload, team, or microservice.

Example:

Retrieve pods with a specific label:

kubectl -n production get pods -l app=web

Output:

NAME                       READY   STATUS
web-6d7f9d8f8b-7xt2m       1/1     Running
web-6d7f9d8f8b-kq4pn       1/1     Running

Check resource usage for those pods:

kubectl top pod -n production | grep web

Output:

web-6d7f9d8f8b-7xt2m   35m   120Mi
web-6d7f9d8f8b-kq4pn   42m   135Mi

This allows operators to quickly evaluate the resource consumption of a specific application or service without reviewing unrelated workloads.

How to Continuously Right-Size Pod Resources with PerfectScale

While kubectl top pod gives you a live snapshot of CPU and memory usage, turning those readings into the right requests and limits across hundreds of workloads is a constant, manual effort. PerfectScale's performance optimization solution enhances Kubernetes performance by autonomously right-sizing workloads, preventing downtime, and optimizing resource use for 99.99% availability, so the usage patterns you spot with kubectl top pod translate directly into safe, data-driven configuration changes.

Key capabilities of PerfectScale:

• Automatic issue remediation: Instantly identifies and fixes resiliency risks, including resource under-provisioning issues such as OOM, CPU throttling, and eviction, to maximize uptime and eliminate latency.
• Autonomous CPU and memory right-sizing: Continuously analyzes your workloads and right-sizes CPU and memory requests and limits based on actual demand, reducing throttling risk while cutting cloud cost, addressing the over- and under-provisioning that kubectl top pod helps you detect.
• Infrastructure hardening: Provides holistic visibility across your nodes to proactively surface misconfigurations, prevent node over-commitment with precise memory limit recommendations, validate node affinities and taints, and select the most suitable node types for your pods.
• Impact-driven prioritization: Resolves critical issues in real time with auto-prioritization, aligns alerting with your SLA/SLOs, sends instant notifications through channels like Slack, MS Teams, or Datadog, and escalates issues into a ticket with one click.

Ready to move from manual snapshots to autonomous optimization? Learn how PerfectScale boosts Kubernetes performance.

FAQ

Why does kubectl top pod return "Metrics API not available"? The Metrics Server isn't installed or isn't healthy in your cluster. Check with kubectl get deployment metrics-server -n kube-system, and install it from the official components manifest if it's missing.

What does the CPU(cores) column actually mean? It's shown in millicores (m). 1000m equals one full CPU core, so 250m is a quarter of a core and 2m is a negligible amount of CPU.

Is kubectl top pod good for long-term monitoring? No. It's a live snapshot from the Metrics Server, not a historical average, so it's best for quick operational checks rather than trend analysis. Use Prometheus/Grafana or similar for long-term monitoring.

How do I see per-container metrics instead of per-pod? Add the --containers flag: kubectl top pod <pod-name> --containers.

How do I find the noisiest pods in a namespace? Use kubectl top pod -n <namespace> --sort-by=cpu or --sort-by=memory to sort pods by consumption, highest first.

How do I know if a pod is under- or over-provisioned? Compare the live usage from kubectl top pod against the pod's configured requests and limits (visible via kubectl describe pod). Usage consistently near the limit suggests under-provisioning risk; usage far below the request suggests over-provisioning.