kubectl topShow CPU and memory use of nodes and pods
kubectl top shows current CPU and memory usage for nodes or pods, from metrics-server. Use it to find the pod eating memory before an OOM kill, compare usage with requests and limits, or see which node is running hot.
kubectl top (node | pod) [NAME | -l SELECTOR] [-n NS | -A] [--containers] [--sort-by=cpu|memory]Latency rose on some requests. Check whether any node is close to its CPU or memory limits.
kubectlThe Kubernetes CLI.
kubectl top does not measure anything itself. It calls the aggregated API /apis/metrics.k8s.io/v1beta1/namespaces/prod/pods, which the API server forwards to metrics-server (an add-on; on EKS install it as a community add-on or Helm chart). metrics-server scrapes every kubelet's /metrics/resource endpoint about every 15 seconds; the kubelet gets the numbers from cgroups via cAdvisor or the runtime. CPU is a rate over the last window, in millicores (1000m = one vCPU). Memory is the container's working set: memory in use minus easily reclaimable page cache, the same figure the kubelet uses for eviction and close to what the OOM killer sees. Node CPU(%) and MEMORY(%) are relative to allocatable, not total capacity. It's a short-term snapshot only; for history use Prometheus or CloudWatch Container Insights.
node / podWhat to report on-n NS / -ANamespace, or all namespaces--containersPer-container rows for pods--sort-by=cpu|memorySort descending by that resource-l SELECTOROnly pods/nodes with matching labels--no-headersOmit the header row (for scripts)--sumPrint a total row under the pods--show-swapAdd swap usage columns where swap is enabledComparing kubectl top memory with free or ps RSS inside the containertop reports the cgroup working set (includes active page cache, excludes inactive), so numbers differ.
Compare top with the container's memory limit; for detail read /sys/fs/cgroup/memory.stat in the containerSetting requests from one kubectl top glanceIt's a 15-second snapshot; peaks, daily cycles and startup spikes are invisible.
Use Prometheus or Container Insights percentiles over days (or the VPA's recommendations)Reading node CPU(%) 73% as 'the node can take 27% more work'Scheduling uses requests, not usage; the node may already be fully requested.
kubectl describe node NODE | grep -A8 'Allocated resources'Try these on a Linux machine of your own. Each task has a hint and a solution.
Write the command to list the 5 pods using the most CPU in the whole cluster.
Read this and decide whether the node can schedule a pod requesting 1 CPU: 'kubectl top node' shows 30% CPU, but describe node shows 'cpu 1900m (98%)' under Allocated resources.
Show the 5 pods using the most memory across the whole cluster, then the per-container numbers for the biggest one.
kubectl topShow CPU and memory use of nodes and pods
kubectl top shows current CPU and memory usage for nodes or pods, from metrics-server. Use it to find the pod eating memory before an OOM kill, compare usage with requests and limits, or see which node is running hot.
kubectl top (node | pod) [NAME | -l SELECTOR] [-n NS | -A] [--containers] [--sort-by=cpu|memory]Latency rose on some requests. Check whether any node is close to its CPU or memory limits.
kubectlThe Kubernetes CLI.
kubectl top does not measure anything itself. It calls the aggregated API /apis/metrics.k8s.io/v1beta1/namespaces/prod/pods, which the API server forwards to metrics-server (an add-on; on EKS install it as a community add-on or Helm chart). metrics-server scrapes every kubelet's /metrics/resource endpoint about every 15 seconds; the kubelet gets the numbers from cgroups via cAdvisor or the runtime. CPU is a rate over the last window, in millicores (1000m = one vCPU). Memory is the container's working set: memory in use minus easily reclaimable page cache, the same figure the kubelet uses for eviction and close to what the OOM killer sees. Node CPU(%) and MEMORY(%) are relative to allocatable, not total capacity. It's a short-term snapshot only; for history use Prometheus or CloudWatch Container Insights.
node / podWhat to report on-n NS / -ANamespace, or all namespaces--containersPer-container rows for pods--sort-by=cpu|memorySort descending by that resource-l SELECTOROnly pods/nodes with matching labels--no-headersOmit the header row (for scripts)--sumPrint a total row under the pods--show-swapAdd swap usage columns where swap is enabledComparing kubectl top memory with free or ps RSS inside the containertop reports the cgroup working set (includes active page cache, excludes inactive), so numbers differ.
Compare top with the container's memory limit; for detail read /sys/fs/cgroup/memory.stat in the containerSetting requests from one kubectl top glanceIt's a 15-second snapshot; peaks, daily cycles and startup spikes are invisible.
Use Prometheus or Container Insights percentiles over days (or the VPA's recommendations)Reading node CPU(%) 73% as 'the node can take 27% more work'Scheduling uses requests, not usage; the node may already be fully requested.
kubectl describe node NODE | grep -A8 'Allocated resources'Try these on a Linux machine of your own. Each task has a hint and a solution.
Write the command to list the 5 pods using the most CPU in the whole cluster.
Read this and decide whether the node can schedule a pod requesting 1 CPU: 'kubectl top node' shows 30% CPU, but describe node shows 'cpu 1900m (98%)' under Allocated resources.
Show the 5 pods using the most memory across the whole cluster, then the per-container numbers for the biggest one.