Introduction

If you want near-real-time CPU and memory usage for a pod in Kubernetes, the standard first tool is kubectl top. Behind the scenes, that depends on Metrics Server or another metrics pipeline collecting resource usage from the cluster.

The Fastest Check: kubectl top

Once Metrics Server is installed and working, this command shows current pod usage:

kubectl top pod my-pod -n my-namespace

For all pods in a namespace:

kubectl top pod -n my-namespace

Typical output includes:

• CPU in millicores
• memory in MiB or GiB

This is the quickest answer for operational spot checks.

What "Real-Time" Really Means

Kubernetes metrics are near-real-time summaries, not nanosecond-accurate live traces. Metrics Server provides recent usage suitable for autoscaling and manual inspection, but it is not a full historical observability platform.

That means:

• good for current or recent pod usage
• not ideal for deep history or long-term trend analysis
• not enough for every performance investigation

If you need historical charts, alerting, or fine-grained time series, you usually move to Prometheus and Grafana.

Install or Verify Metrics Server

If kubectl top fails, Metrics Server is often missing or unhealthy.

Check whether it is installed:

kubectl get deployment metrics-server -n kube-system
kubectl get apiservices | grep metrics

If the service is working, the metrics.k8s.io API should be available. Without that API, kubectl top has nothing to query.

Node and Container Context

A pod may contain multiple containers. kubectl top pod shows usage aggregated at the pod level. If you need container-level detail, use:

kubectl top pod my-pod -n my-namespace --containers

That matters when one sidecar is using most of the resources and the main application container looks innocent from the pod total alone.

When You Need More Than kubectl top

Use Prometheus-based monitoring when you need:

• historical graphs
• alerting rules
• per-container trends over time
• correlation with application metrics
• dashboards for many workloads

Prometheus typically scrapes kubelet or cAdvisor-derived metrics and lets you query them with PromQL. Grafana then visualizes the data.

For example, a PromQL query for container CPU rate may look like:

sum by (pod) (
  rate(container_cpu_usage_seconds_total{namespace="my-namespace", pod="my-pod"}[5m])
)

That is a different layer of tooling from kubectl top, but it solves more advanced monitoring needs.

Resource Usage vs Resource Limits

Do not confuse observed usage with configured requests and limits. You often need both views:

kubectl describe pod my-pod -n my-namespace

That shows the configured requests and limits, which helps explain whether current usage is close to throttling or eviction thresholds.

Common Pitfalls

The biggest mistake is expecting kubectl top to work in every cluster automatically. It depends on Metrics Server being installed and healthy.

Another issue is treating pod-level numbers as container-level truth. Multi-container pods can hide the real source of resource consumption unless you use the container breakdown.

Teams also sometimes assume kubectl top provides durable historical monitoring. It does not. For history and alerting, use Prometheus or another full metrics backend.

Finally, do not interpret CPU usage without also checking requests, limits, and throttling context. A raw number alone can be misleading.

Summary

• Use kubectl top pod for quick near-real-time CPU and memory checks.
• Metrics Server must be installed for kubectl top to work.
• Use --containers when you need per-container resource usage.
• Use Prometheus and Grafana for history, alerting, and deeper analysis.
• Compare observed usage with requests and limits to interpret the numbers correctly.