View on GitHub


Scalable and efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines.

Kubernetes Metrics Server

Metrics Server is a scalable, efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines.

Metrics Server collects resource metrics from Kubelets and exposes them in Kubernetes apiserver through Metrics API for use by Horizontal Pod Autoscaler and Vertical Pod Autoscaler. Metrics API can also be accessed by kubectl top, making it easier to debug autoscaling pipelines.

Metrics Server is not meant for non-autoscaling purposes. For example, don’t use it to forward metrics to monitoring solutions, or as a source of monitoring solution metrics. In such cases please collect metrics from Kubelet /metrics/resource endpoint directly.

Metrics Server offers:

Use cases

You can use Metrics Server for:

Don’t use Metrics Server when you need:

For unsupported use cases, check out full monitoring solutions like Prometheus.


Metrics Server has specific requirements for cluster and network configuration. These requirements aren’t the default for all cluster distributions. Please ensure that your cluster distribution supports these requirements before using Metrics Server:


Latest Metrics Server release can be installed by running:

kubectl apply -f

Installation instructions for previous releases can be found in Metrics Server releases.

Compatibility matrix:

Metrics Server Metrics API group/version Supported Kubernetes version
0.6.x *1.19+
0.5.x *1.8+
0.4.x *1.8+
0.3.x 1.8-1.21

*For <1.16 requires passing --authorization-always-allow-paths=/livez,/readyz command line flag

High Availability

Latest Metrics Server release can be installed in high availability mode by running:

kubectl apply -f

Note that this configuration requires having a cluster with at least 2 nodes on which Metrics Server can be scheduled.

Also, to maximize the efficiency of this highly available configuration, it is recommended to add the --enable-aggregator-routing=true CLI flag to the kube-apiserver so that requests sent to Metrics Server are load balanced between the 2 instances.

Security context

Metrics Server requires the CAP_NET_BIND_SERVICE capability in order to bind to a privileged ports as non-root. If you are running Metrics Server in an environment that uses PSPs or other mechanisms to restrict pod capabilities, ensure that Metrics Server is allowed to use this capability. This applies even if you use the --secure-port flag to change the port that Metrics Server binds to to a non-privileged port.


Starting from v0.5.0 Metrics Server comes with default resource requests that should guarantee good performance for most cluster configurations up to 100 nodes:

Metrics Server resource usage depends on multiple independent dimensions, creating a Scalability Envelope. Default Metrics Server configuration should work in clusters that don’t exceed any of the thresholds listed below:

Quantity Namespace threshold Cluster threshold
#Nodes n/a 100
#Pods per node 70 70
#Deployments with HPAs 100 100

Resources can be adjusted proportionally based on number of nodes in the cluster. For clusters of more than 100 nodes, allocate additionally:

You can use the same approach to lower resource requests, but there is a boundary where this may impact other scalability dimensions like maximum number of pods per node.


Depending on your cluster setup, you may also need to change flags passed to the Metrics Server container. Most useful flags:

You can get a full list of Metrics Server configuration flags by running:

docker run --rm --help

Helm Chart

This Helm chart can deploy the metric-server service in your cluster.


Metrics Server is a component in the core metrics pipeline described in Kubernetes monitoring architecture.

For more information, see:

Have a question?

Before posting an issue, first checkout Frequently Asked Questions and Known Issues.

Community, discussion, contribution, and support

Learn how to engage with the Kubernetes community on the community page.

You can reach the maintainers of this project at:

This project is maintained by SIG Instrumentation

Code of conduct

Participation in the Kubernetes community is governed by the Kubernetes Code of Conduct.