Viewing Resource Metrics: Monitoring CPU and Memory in Kubernetes

Previously in this course, we learned about monitoring cluster events to track the "what" and "when" of system changes. In this lesson, we add the "how much" by introducing resource Metrics. Without these, you’re flying blind when your applications start hitting performance bottlenecks.

The Need for Cluster Metrics

Kubernetes does not collect performance data by default. While the API server tracks the state of your objects, it doesn't natively record how much CPU or RAM your containers are consuming over time. To get this data, we need the Metrics Server.

The Metrics Server is a scalable, efficient source of cluster resource data. It collects metrics from the kubelet on every node and exposes them through the Kubernetes API using the Metrics API. Once installed, these metrics become available to the kubectl top command, which acts similarly to the standard Linux top utility you might use in real-time monitoring.

Installing the Metrics Server

Most managed Kubernetes environments (like EKS, GKE, or AKS) have the Metrics Server installed by default. If you are running a local cluster like minikube or kind, you may need to enable it manually.

For minikube, run:

Bash
minikube addons enable metrics-server

If you are on a bare-metal or custom cluster, you install it by applying the official components YAML:

Bash
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Note: After applying the manifest, wait about 30-60 seconds for the Metrics Server pods to start up and begin scraping data from the nodes.

Using kubectl top

Once installed, the top command provides a snapshot of current resource usage. It is your primary tool for identifying which Pods or nodes are consuming the most hardware resources.

Checking Node Metrics

To see how much of your total cluster capacity is being used:

Bash
kubectl top nodes

This shows the CPU and memory utilization for each node in your cluster. If a node is near 100% usage, the Kubelet may begin evicting Pods to protect the system.

Checking Pod Metrics

To see the usage of individual Pods:

Bash
kubectl top pods

If you want to see metrics for a specific namespace, add the -n flag:

Bash
kubectl top pods -n my-app-namespace

Identifying Resource-Heavy Containers

A common production scenario involves identifying why a specific service is lagging. If a Pod shows high CPU usage in kubectl top pods, you can inspect its containers to see if one specific sidecar or main application process is the culprit:

Bash
kubectl top pods <pod-name> --containers

This output is invaluable when you suspect a "noisy neighbor" or a memory leak. By comparing the output here against the resource requests and limits you've defined, you can determine if your application needs more headroom or if it's simply experiencing a spike in traffic.

Hands-on Exercise

1. Verify Installation: Run kubectl top nodes. If you see an error saying "Metrics API not available," ensure the Metrics Server pod is running in the kube-system namespace.
2. Deploy Load: Deploy a simple container, such as an Nginx server, to your cluster.
3. Monitor: Run kubectl top pods and observe the memory usage.
4. Stress Test (Optional): If you are comfortable, use a tool like stress-ng inside your container to artificially spike CPU usage and watch the values in kubectl top update.

Common Pitfalls

• Metrics Not Ready: If you run kubectl top immediately after installation, you will likely see an error. The Metrics Server needs time to scrape data from the Kubelets. Wait a minute and try again.
• Missing RBAC Permissions: If your cluster is highly restricted, the Metrics Server might not have the correct permissions to read from the Kubelet. Ensure the ClusterRole and ClusterRoleBinding are correctly applied.
• Inaccurate Snapshots: kubectl top provides a point-in-time snapshot. It is not for historical trend analysis. For long-term tracking, you would eventually look toward tools like Prometheus and Grafana.

FAQ

Q: Can I use kubectl top for historical trends? A: No. kubectl top only shows the current usage. For historical data, you need a metrics pipeline that stores data over time.

Q: Why does my Pod show 0 CPU usage? A: If a container is idle, it may consume near-zero CPU. Additionally, if the Metrics Server hasn't successfully scraped that specific pod yet, it may return empty values.

Q: Does installing the Metrics Server slow down my cluster? A: Generally, no. It is designed to be lightweight, but it does consume a small, predictable amount of CPU and memory on your nodes to perform the scraping.

Recap

We've successfully moved from observing cluster events to monitoring actual resource consumption. By installing the Metrics Server and mastering kubectl top, you now have the visibility required to diagnose performance issues. You can identify which containers are over-consuming resources, allowing you to tune your resource limits and ensure your cluster remains stable under load.

Up next: Security Contexts — learning how to harden your containers by running them as non-root users.