Visit Website →
← Back to blog

Metrics Server vs Prometheus: What Each Does in Kubernetes

November 5, 2026
Metrics Server vs Prometheus: What Each Does in Kubernetes

Metrics Server and Prometheus are not rivals. Metrics Server gives your cluster a short-lived, current view of CPU and memory so that kubectl top and autoscalers work. Prometheus scrapes many endpoints, stores the samples as time series, and lets you query history and alert on it. Most production clusters end up with both, plus kube-state-metrics for object state. This guide explains what each one collects, where each stops, and how to see live metrics when you don't want to build a full stack first.

Kubezilla Desktop
kubezilladesktop.com
See Live Metrics Across Your Clusters
Kubezilla Desktop brings live metrics monitoring and cluster management into one native app, without requiring a full monitoring stack.
Explore Kubezilla Desktop

TL;DR

  • Metrics Server serves current CPU and memory for nodes and Pods through the Metrics API. It feeds kubectl top, the Horizontal Pod Autoscaler (HPA) and the Vertical Pod Autoscaler (VPA). It keeps no history.
  • Prometheus is a monitoring and alerting toolkit. It pulls metrics over HTTP, stores them with timestamps and labels, and answers questions with PromQL.
  • kube-state-metrics is a third piece. It reports the state of Kubernetes objects (replica counts, Pod phase, restarts), not resource usage.
  • Running Metrics Server for autoscaling and Prometheus for history is the common pattern. Neither replaces the other.
  • If you only need live numbers while operating clusters, a desktop client can show them without standing up a monitoring stack.

Table of Contents

The short answer: different layers, different jobs

The Kubernetes documentation treats these as separate layers of the observability stack. The Kubernetes observability page describes the Metrics API as intentionally limited to the resource metrics needed for autoscaling and basic inspection. It places Prometheus in a typical metrics pipeline, one that scrapes component endpoints and stores samples in a time series database.

In practice:

Question you are askingTool that answers it
How much CPU and memory is this Pod using right now?Metrics Server
Should the HPA add replicas?Metrics Server (for CPU and memory based scaling)
What was memory usage last Tuesday at 3 a.m.?Prometheus
Alert me when error rates climb for ten minutesPrometheus (with its alertmanager)
How many Pods in this Deployment are not ready?kube-state-metrics, usually scraped by Prometheus
Is this container restarting repeatedly?kube-state-metrics, or Pod status in your client

What Metrics Server actually does

Metrics Server is a single, lightweight deployment. According to the official Metrics Server documentation, it is a scalable, efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines. It collects resource metrics from the kubelets and exposes them through the Kubernetes API server as the Metrics API. The HPA and VPA consume that API, and so does kubectl top.

The same documentation lists its footprint: 1 milli core of CPU and 2 MB of memory per node, a collection interval of 15 seconds, and support for clusters of up to 5,000 nodes. That is why it is installed in almost every cluster.

Two properties matter when you compare it with Prometheus:

  1. It holds only the latest values. A Kubernetes-focused write-up describes it as a short-term, in-memory store that does not keep historical data. If you want a graph of the last week, Metrics Server cannot provide it.
  2. It is scoped to autoscaling. The Metrics Server documentation says it is not meant for non-autoscaling purposes, such as forwarding metrics to monitoring solutions. For those cases it points you to the kubelet /metrics/resource endpoint and to full monitoring solutions like Prometheus.

It also doesn't cover every scaling signal. The same documentation notes that it does not support horizontal autoscaling based on other resources, and names full monitoring solutions as the option there.

What Prometheus does

The Prometheus overview describes it as an open-source systems monitoring and alerting toolkit, originally built at SoundCloud. It collects and stores metrics as time series, meaning each value carries a timestamp and optional key-value labels. The ecosystem includes the main server, client libraries, a push gateway, exporters and an alertmanager.

The features that matter to a cluster operator:

  • A multi-dimensional data model, so you can slice a metric by namespace, Pod, container or any label you attach.
  • PromQL, a query language built for this data.
  • A pull model over HTTP, with targets found through service discovery or static configuration.
  • No reliance on distributed storage, so a single server is self-contained.
  • Several modes of graphing and dashboarding support.

In Kubernetes, Prometheus periodically scrapes the metrics endpoints of cluster components and stores the samples. That is a very different job from Metrics Server, which answers one narrow question through the API aggregation layer.

How the two collect data differently

A frequent point of confusion: can Prometheus scrape Metrics Server? The answer from a maintainer discussion in the Metrics Server repository is no, not in the way people hope. Metrics Server does not expose the underlying metrics for scraping. Metrics pipelines like Prometheus should read directly from the nodes' /metrics/cadvisor endpoint. Controllers and kubectl top read from /apis/metrics.k8s.io through Metrics Server.

So the two sit side by side and both draw from the kubelet. They do not feed each other.

Separate Metrics Server and Prometheus collection paths

# Served by Metrics Server through the API aggregation layer
kubectl top nodes
kubectl top pods -n production

# Confirm the Metrics API is registered
kubectl get apiservices | grep metrics

If kubectl top returns an error, the usual first check is whether the Metrics Server deployment is running and its APIService reports as available. Prometheus has no part in that path.

Where kube-state-metrics fits

Searchers often type "metrics server vs kube state metrics", and the confusion is understandable because the names are close. They answer different questions.

According to a maintainer thread comparing the two projects, Metrics Server exposes CPU and memory usage for nodes and Pods through the Metrics API. kube-state-metrics exposes Prometheus-formatted metrics about the state of Kubernetes objects, including Deployments, Jobs and Pods.

The Kubernetes documentation on object-state metrics says kube-state-metrics connects to the API server and exposes an HTTP endpoint with metrics generated from individual objects. These include labels, annotations, start and termination times, and status or phase. An external component such as Prometheus can scrape that endpoint, which enables queries such as the number of Pods that are not ready.

A useful way to remember it:

  • Metrics Server: how much is being used?
  • kube-state-metrics: what state are the objects in?
  • Prometheus: collect, store and query both over time.

If a Deployment has three desired replicas and one is crash-looping, kube-state-metrics is the source that reports the mismatch and the restart count. Metrics Server only tells you what the running Pods consume.

Prometheus and Grafana are not the same thing

People also ask whether Prometheus is the same as Grafana. They are separate projects. Prometheus collects, stores and queries metrics, and it does include some graphing support, as the overview above notes. Dashboards are a separate layer many teams put on top of a time series store. Treat the dashboard as the viewing layer and Prometheus as the data layer when you plan a setup.

Do you need both?

The honest answer depends on what you need to do.

You need Metrics Server if you use HPA or VPA on CPU or memory, or you want kubectl top to work. It is small and purpose built.

You need Prometheus if you want history, alert rules, capacity trends, or metrics from your applications and exporters, not only from the kubelet. One platform-engineering write-up describes the common pattern: teams run Metrics Server for current autoscaling needs and Prometheus for history, and neither replaces the other. A vendor guide on Kubernetes metrics frames it the same way: Metrics Server is the fast path for autoscaling, while Prometheus stores history for long-term observability.

You need kube-state-metrics if you want alerts or dashboards about object state, such as unavailable replicas, Pods stuck pending, or Job failures. It is typically deployed so that Prometheus can scrape it.

A note on installing both

Teams often ask what happens when a Prometheus stack and Metrics Server land in the same cluster. They cover different APIs, so they generally coexist. The thing to watch is the Metrics API registration: only one provider can own v1beta1.metrics.k8s.io. If you install an adapter that serves the same API, decide which component is the owner before you apply manifests, and check kubectl get apiservices afterward.

Kubernetes metrics without Prometheus

Can you watch resource usage without Prometheus? For live operational work, yes. Metrics Server alone gives you current CPU and memory per node and Pod. That covers the daily questions: which Pod is hot, which node is running out of memory, did the scale-up take effect.

The limits are the ones above. There is no history, no alerting, and nothing about application-level metrics. Within those limits, a lot of day-to-day cluster operation needs only current numbers, plus logs and Pod status.

There are three ways to read live resource metrics without building a monitoring stack:

  1. kubectl top for a quick terminal check. Our guide on viewing pod metrics with kubectl top and beyond walks through the flags and the situations where the command runs out of road.
  2. The kubelet resource endpoint, which the Metrics Server documentation names as the direct source when you need to collect metrics yourself.
  3. A desktop client that shows live metrics next to logs, YAML and Pod terminals, so you aren't stitching together terminal tabs.

Live metrics for the person operating the cluster

The "best Kubernetes metrics dashboard" depends on who is looking. A time series dashboard answers "what happened over the last month?" An operator in the middle of a rollout asks something else: is this Pod healthy now, what do its logs say, and does it need more replicas?

That is the workflow we built Kubezilla Desktop around. Metrics sit in the same window as live log streaming, pod terminals, YAML editing and workload scaling. If you are chasing a latency spike, you can check usage, tail the logs and scale the workload without switching tools. Our related guides cover viewing Kubernetes logs live and scaling a Deployment from the command line.

Perspective

Most teams treat "metrics" as one problem, then buy or build one big answer to it. We see two problems. One is long-term observability: history, alert rules, capacity planning. That is what a time series system is for. The other is the operator's live view: what is this cluster doing right now, and what can I change about it?

The second problem gets less attention, and it is where engineers lose time. Every extra CLI, browser tab and port-forward is friction. When you manage several clusters, some behind SSH tunnels or bastion hosts, that friction multiplies. We built Kubezilla Desktop as a native app in Rust, so it starts fast and stays light on RAM. It keeps kubeconfigs stored locally, with no cloud sync and no telemetry, because the tool that touches your clusters should not send data anywhere.

Our view: keep Metrics Server for autoscaling, add a monitoring system when you need history and alerts, and give the people on call a fast, secure, unified place to look and act. Those layers work together.

Margus

Choosing a setup by team size and need

A few common situations and the combination that fits each:

  • A small team running a handful of services. Metrics Server for kubectl top and HPA, and a desktop client for live inspection. Add history later when an incident shows you wish you had it.
  • A platform team supporting many product teams. Metrics Server in every cluster, Prometheus with kube-state-metrics for history and alerts, and a client for operators who jump between clusters. Our guide on managing multiple Kubernetes clusters covers that side.
  • Autoscaling on custom or external signals. The Metrics Server documentation notes that other resources need a fuller monitoring solution. Plan for Prometheus, plus whatever component exposes those metrics to the autoscaler.
  • Resource governance. Usage data informs how you set requests, limits and namespace budgets. See our guide to Kubernetes resource quotas for that step.

Try live metrics in Kubezilla Desktop

Kubezilla Desktop is a native app for Linux, macOS and Windows. It connects to multiple clusters, supports SSH tunneling and direct remote cluster management, and puts metrics monitoring, live logs, pod terminals, YAML editing, workload scaling, Helm and ArgoCD operations in one interface. It costs €5 per month.

Kubezilla Desktop

If you want a single place to see what your clusters are doing without juggling CLIs and tabs, get Kubezilla Desktop.

FAQ

Can Metrics Server replace Prometheus?

No. Metrics Server holds only the most recent CPU and memory values for autoscaling and kubectl top, and its own documentation points to full monitoring solutions like Prometheus for other uses. Prometheus stores time series and supports queries and alerting. Many teams run both.

Can Prometheus scrape Metrics Server?

Not for resource metrics. A maintainer explanation in the Metrics Server repository says it does not expose the underlying metrics for scraping. Prometheus should read the kubelet's /metrics/cadvisor endpoint directly, while kubectl top and the autoscalers read the Metrics API.

What is the difference between Metrics Server and kube-state-metrics?

Metrics Server reports CPU and memory usage for nodes and Pods through the Metrics API. kube-state-metrics reports the state of Kubernetes objects, such as Deployments, Jobs and Pods, in a format Prometheus can scrape. One tells you consumption, the other tells you status.

Do I need Prometheus for HPA?

Not for CPU and memory based autoscaling. Metrics Server provides those metrics to the HPA. For scaling on other signals, the Metrics Server documentation names full monitoring solutions like Prometheus as the option.

Sources