metrics-server and live usage
metrics-server runs in every Syself Autopilot cluster and gives you live CPU and memory usage. It polls each kubelet, keeps the most recent sample, and serves it through the metrics.k8s.io API. Two things read that API, and nothing about it is history.
What reads it#
kubectl top.kubectl top nodesandkubectl top podsshow current usage by reading metrics-server.$ kubectl top nodes NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% worker-1 210m 5% 1420Mi 18%The HorizontalPodAutoscaler. An HPA that scales on CPU or memory reads the same API to decide when to add or remove replicas.
Without it, the HPA sits idle#
metrics-server is what makes a resource-based HPA work. If it is not running or not healthy, an HPA targeting CPU or memory cannot read usage and does nothing, logging unable to fetch metrics from resource metrics api. If an HPA never scales, check that metrics-server is up before you touch the HPA itself.
Latest sample only, not a time series#
metrics-server keeps one sample per pod and node and overwrites it. It answers "how much is this pod using right now", never "how much was it using an hour ago". There is no query language, no retention, and no history. That is by design: it is a lightweight feed for kubectl top and the autoscaler, not a database.
When you outgrow it#
The moment you need any of these, you need Prometheus, not metrics-server:
- usage over time, or a graph of the last day,
- alerts on a trend rather than a single reading,
- metrics from anything other than CPU and memory.
metrics-server keeps doing its job (kubectl top and the HPA) alongside Prometheus, so you add to it rather than replace it. Start with Set up Prometheus .
Troubleshoot the collectors
The failure modes worth knowing by name, from a target that is down and a series scraped twice to out-of-order samples and a cardinality spike.
Set up Prometheus
Install the Prometheus Operator and one Prometheus that only receives, because the Alloy collectors do all the scraping.