How to check Kubernetes resource usage

Resource pressure in Kubernetes is easiest to inspect when the cluster exposes recent CPU and memory samples through the Metrics API. kubectl top reads that API and shows which nodes, Pods, or containers are using capacity at the moment of the scrape.

kubectl top depends on Metrics Server or another implementation of metrics.k8s.io. It reports recent usage, not declared requests, long-term history, or Prometheus metrics, so the values fit live triage and autoscaling checks rather than billing or trend analysis.

Start with the node view when the cluster feels constrained, then narrow to the namespace, Pod, and container level. Compare a busy workload with its declared resource requests before changing limits or autoscaler targets, because usage without request context can hide scheduler or quota pressure.

1. Check that the cluster exposes the Metrics API.

   $ kubectl get apiservice v1beta1.metrics.k8s.io
   NAME                     SERVICE                      AVAILABLE   AGE
   v1beta1.metrics.k8s.io   kube-system/metrics-server   True        85s

   AVAILABLE should be True before kubectl top returns resource data. If the APIService is missing or False, install or repair Metrics Server first.
   Related: How to install Kubernetes Metrics Server

2. Check node-level resource usage.

   $ kubectl top node
   NAME            CPU(cores)   CPU(%)   MEMORY(bytes)   MEMORY(%)
   control-plane   147m         1%       700Mi           5%

   CPU(%) and MEMORY(%) show usage relative to node capacity as reported through the Metrics API.

3. Check Pod usage in the target namespace.

   $ kubectl top pod --namespace team-a
   NAME                   CPU(cores)   MEMORY(bytes)
   web-5bb7fdcc95-4z74t   0m           6Mi
   web-5bb7fdcc95-mk7wj   0m           6Mi

   Metrics can be unavailable for a few minutes after a Pod is created while the metrics pipeline catches up.

4. Split Pod usage by container.

   $ kubectl top pod --namespace team-a --containers
   POD                    NAME    CPU(cores)   MEMORY(bytes)
   web-5bb7fdcc95-4z74t   nginx   0m           6Mi
   web-5bb7fdcc95-mk7wj   nginx   0m           6Mi

   Use container output when a Pod has sidecars or several app containers and the Pod total does not show which container is consuming CPU or memory.

5. Sort cluster-wide Pod usage when the namespace is unknown.

   $ kubectl top pod --all-namespaces --sort-by=cpu
   NAMESPACE            NAME                                   CPU(cores)   MEMORY(bytes)
   kube-system          kube-apiserver-control-plane           32m          199Mi
   kube-system          etcd-control-plane                     16m          33Mi
   kube-system          kube-controller-manager-control-plane   12m          63Mi
   kube-system          kube-scheduler-control-plane           6m           24Mi
   kube-system          metrics-server-55bf4495db-nsbdb        4m           19Mi
   ##### snipped #####
   team-a               web-5bb7fdcc95-4z74t                   0m           6Mi
   team-a               web-5bb7fdcc95-mk7wj                   0m           6Mi

   Use --sort-by=memory when memory pressure is the issue.

6. Compare the selected workload with its declared requests and limits.

   $ kubectl describe deployment web --namespace team-a
   Name:                   web
   Namespace:              team-a
   Selector:               app=web
   Replicas:               2 desired | 2 updated | 2 total | 2 available | 0 unavailable
   ##### snipped #####
   Pod Template:
     Labels:  app=web
     Containers:
      nginx:
       Image:      nginx:1.27-alpine
       Limits:
         cpu:     250m
         memory:  128Mi
       Requests:
         cpu:         50m
         memory:      64Mi
   ##### snipped #####

   Requests show the scheduler reserve, while Limits show the runtime ceiling. Use live usage and declared resources together before changing workload sizing.
   Tool: Kubernetes Resource Requests Checker