Skip to main content
This lesson covers how to monitor a Kubernetes cluster: what to collect, how metrics flow through the system, and lightweight options for short-term metrics. What to monitor on Kubernetes
  • Node-level metrics: cluster size, node health, and performance (CPU, memory, network, disk).
  • Pod-level metrics: pod counts and per-pod resource usage (CPU, memory).
Collecting, storing, and analyzing metrics requires a solution that:
  • Scrapes metrics from nodes and pods,
  • Stores metrics (at least temporarily),
  • Provides querying/analytics for current and, optionally, historical data.
Kubernetes does not ship a full monitoring system by default. Common open-source and commercial options include:
  • Metrics Server (lightweight, short-term),
  • Prometheus (time-series database and query engine),
  • Elastic Stack, Datadog, Dynatrace (commercial/enterprise solutions).
A dark-themed infographic titled "Monitor" showing monitoring tools (Metrics Server, Prometheus, Elastic Stack, Datadog, Dynatrace). Below are three heatmap-style grids representing nodes/containers and metrics like CPU, memory, and disk.
Historic note: Heapster was previously used to collect cluster metrics but is now deprecated in favor of newer, more focused solutions.
A presentation slide titled "Heapster vs Metrics Server" showing two boxes: "Heapster" on the left (marked "Deprecated") and "Metrics Server" on the right. Each box includes a small icon (a monitor/cube for Heapster and stacked servers for Metrics Server).
Heapster is deprecated and should not be used for production monitoring. Replace Heapster-based tooling with Metrics Server for short-term metrics or Prometheus for full time-series monitoring and long-term storage.
What the Metrics Server provides
  • One Metrics Server per cluster is typical.
  • It scrapes metrics from all kubelets, aggregates them in memory, and serves current cluster metrics.
  • It does not persist time-series data to disk, so it cannot provide historical metrics.
Use Metrics Server for lightweight, near-real-time metrics (e.g., kubectl top, Horizontal Pod Autoscaler). For historical storage, advanced queries, and alerting, use a Prometheus-based stack or a commercial monitoring service.
How metrics are produced and collected
  • kubelet: runs on every node, manages pods, and exposes node/pod metrics.
  • cAdvisor: built into kubelet; collects per-container resource usage (CPU, memory, filesystem, network).
  • Metrics Server: scrapes the kubelet endpoints across the cluster to gather and aggregate metrics.
Component summary Deploying Metrics Server
  • Minikube:
  • Other clusters (apply official components):
This creates the Metrics Server deployment, service, and RBAC roles required for scraping kubelets and serving aggregated metrics. After deploying, allow a short period for metric collection before querying. Viewing metrics with kubectl
  • Node metrics:
  • Pod metrics:
Example outputs:
Practice exercise
  • Deploy Metrics Server in a test cluster (Minikube or a cloud cluster).
  • Create a few pods with varying resource limits/requests.
  • Use kubectl top node and kubectl top pod to observe live resource usage.
  • If you need historical metrics, set up Prometheus (and optionally a remote storage backend) and compare stored time-series vs Metrics Server live view.
Links and references Practice viewing performance metrics on your Kubernetes cluster to reinforce these concepts.

Watch Video

Practice Lab