Metrics Server — Lightweight Core Metrics for Kubernetes Autoscaling

Introduction

Metrics Server replaces the long-deprecated Heapster as the canonical implementation of the Kubernetes Resource Metrics API. It is intentionally small: it scrapes every kubelet''s Summary API every 15 seconds, keeps a short in-memory window, and serves CPU/memory numbers back to the Kubernetes API server. Anything that consumes these metrics — HPA, VPA, kubectl top, Lens, dashboards — sees them through the aggregation layer as if they were native API resources.

What Metrics Server Does

• Scrapes kubelet Summary API (/metrics/resource) on every node at a configurable interval.
• Aggregates CPU and memory usage per Pod, container, and Node in memory.
• Exposes the metrics.k8s.io API group through the Kubernetes aggregation layer.
• Provides the data source for HorizontalPodAutoscaler v1 and v2 (resource metrics).
• Powers kubectl top and UIs like Lens, Headlamp, and the dashboard.

Architecture Overview

The Metrics Server pod runs behind an APIService registration so requests for /apis/metrics.k8s.io/v1beta1/* are proxied to it through the aggregation layer. Internally it maintains a scrape loop hitting each node''s kubelet, decodes the returned Prometheus text, and stores the last two samples per object so it can compute rates. There is no persistent storage — restarting the pod resets the window. For large clusters you run multiple replicas; each instance scrapes all nodes independently, and the aggregation layer load-balances reads.

Self-Hosting & Configuration

• Install via the official components.yaml, the metrics-server Helm chart, or the addon that ships with most distros.
• In production, use signed kubelet certs and remove --kubelet-insecure-tls; set --kubelet-preferred-address-types=InternalIP,Hostname.
• Scale to 2 replicas with anti-affinity for HA; resources are modest (100m CPU, 200Mi RAM fits most clusters).
• Configure --metric-resolution=15s to match HPA''s default sync period; lower increases kubelet load.
• Monitor the metrics-server pod logs for scrape errors — missing metrics silently break HPA decisions.

Key Features

• Native Kubernetes API integration through the aggregation layer — no extra endpoints to manage.
• Works on every conformant Kubernetes distribution from v1.19 onward.
• Minimal resource footprint suitable for edge and single-node clusters.
• High-availability via leaderless replicas; no external state store.
• Secure TLS between metrics-server and kubelets, including bootstrap and client certs.

Comparison with Similar Tools

• kube-state-metrics — Exposes object state (Deployments desired vs ready), not resource usage; complementary.
• Prometheus + node_exporter — Full metrics stack with history; Metrics Server is the lightweight, in-cluster-only subset.
• cAdvisor — Per-node container stats; Metrics Server aggregates cAdvisor''s output via kubelet.
• Custom Metrics API (KEDA, Prometheus Adapter) — For custom/external metrics in HPA; Metrics Server covers only CPU/RAM.
• Datadog/New Relic agents — Full APM pipelines; too heavy if you only need HPA.

FAQ

Q: Why does kubectl top say "metrics not available yet"? A: Wait 60s after install for the first scrape window, and confirm the APIService is Available: True.

Q: Do I still need it if I run Prometheus? A: Usually yes — HPA v2 reads metrics.k8s.io by default. Prometheus Adapter can replace it but adds complexity.

Q: How much history does it keep? A: Just enough to compute the latest rate (typically 2 samples). For history, use a TSDB like Prometheus.

Q: Will it work on Fargate or serverless nodes? A: Only if the virtual kubelet exposes the Summary API. Most serverless Kubernetes offerings ship their own metrics integration.

Sources

• https://github.com/kubernetes-sigs/metrics-server
• https://kubernetes-sigs.github.io/metrics-server/