CPU use alone may not describe when an application needs more replicas; a queue length or request metric may be more useful. Prometheus Adapter translates selected measurements already stored in Prometheus into Kubernetes metrics APIs that an autoscaler can read. It connects the monitoring data to the scaling decision rather than collecting the application measurements itself. The mapping must identify the right workload and value, and delayed or missing samples need predictable behavior before the metric controls production capacity.
Current guidance
Prometheus Adapter serves Kubernetes custom, resource and external metrics APIs using data from Prometheus. The Horizontal Pod Autoscaler consumes these APIs; the adapter does not collect application metrics itself.
Use the prometheus-community/prometheus-adapter chart and upstream configuration documentation. Check how discovery rules select series, associate their labels with Kubernetes resources and turn Prometheus queries into the metric names and values requested by the autoscaler.
Verify the source series in Prometheus, then query the relevant Kubernetes metrics API and inspect the HPA’s reported metrics and conditions. Test missing and delayed data as well as a normal scaling case. Set metrics-max-age at least as long as the Prometheus scrape interval, and account for upstream reporting delays, or metrics can disappear from discovery. No release-specific installation or autoscaling result is claimed here.
Historical upstream link check · 2026-10-09
The recorded upstream address redirects to https://github.com/kubernetes-sigs/prometheus-adapter and returned HTTP 200 on 2026-10-09. GitHub does not mark kubernetes-sigs/prometheus-adapter archived or disabled; this does not establish active maintenance, support or compatibility. GitHub resolves the old repository identity to kubernetes-sigs/prometheus-adapter. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
Installs the Prometheus Adapter for the Custom Metrics API. Custom metrics are used in Kubernetes by Horizontal Pod Autoscale to scale workloads based upon your own metric pulled from an external metrics provider like Prometheus. This chart complements the metrics-server chart that provides resource only metrics.
This repository contains an implementation of the Kubernetes custom metrics API (custom.metrics.k8s.io/v1beta1), suitable for use with the auto scaling/v2 Horizontal Pod Autoscaler in Kubernetes 1.6+.
Prerequisites
- Kubernetes 1.9+
Using the Chart
To use the chart, ensure the Prometheus.url and prometheus.port are configured with the correct Prometheus service endpoint. Additionally, the chart comes with a set of default rules out of the box but they may pull in too many metrics or not map them correctly for your needs. Therefore, it is recommended to populate rules.custom with a list of rules (see the config document for the proper format). Finally, to configure your Horizontal Pod Autoscaler to use the custom metric, see the custom metrics section of the HPA walkthrough.
Configuration
The adapter takes the standard Kubernetes generic API server arguments (including those for authentication and authorization). By default, it will attempt to using Kubernetes in-cluster config to connect to the cluster.
It takes the following additional arguments specific to configuring how the adapter talks to Prometheus and the main Kubernetes cluster:
- –lister-kubeconfig=<path-to-kubeconfig>: This configures how the adapter talks to a Kubernetes API server in order to list objects when operating with label selectors. By default, it will use in-cluster config.
- –metrics-relist-interval=<duration>: This is the interval at which to update the cache of available metrics from Prometheus. Since the adapter only lists metrics during discovery that exists between the current time and the last discovery query, your relist interval should be equal to or larger than your Prometheus scrape interval, otherwise your metrics will occasionally disappear from the adapter.
- –prometheus-url=<url>: This is the URL used to connect to Prometheus. It will eventually contain query parameters to configure the connection.
- –config=<yaml-file> (-c): This configures how the adapter discovers available Prometheus metrics and the associated Kubernetes resources, and how it presents those metrics in the custom metrics API. More information about this file can be found in docs/config.md.
Launching Prometheus and the Adapter
In order to expose metrics beyond CPU and memory to Kubernetes for autoscaling, you’ll need an “adapter” that serves the custom metrics API. Since you’ve got Prometheus metrics, it makes sense to use the Prometheus adapter to serve metrics out of Prometheus.
Launching Prometheus
First, you’ll need to deploy the Prometheus Operator. Check out the getting started guide for the Operator to deploy a copy of Prometheus.
This walkthrough assumes that Prometheus is deployed in the prom namespace. Most of the sample commands and files are namespace-agnostic, but there are a few commands or pieces of configuration that rely on namespace. If you’re using a different namespace, simply substitute that in for prom when it appears.
Launching the Adapter
Now that you’ve got a running copy of Prometheus that’s monitoring your application, you’ll need to deploy the adapter, which knows how to communicate with both Kubernetes and Prometheus, acting as a translator between the two.
The deploy/manifests directory contains the appropriate files for creating the Kubernetes objects to deploy the adapter.
See the deployment README for more information about the steps to deploy the adapter. Note that if you’re deploying on a non-x86_64 (amd64) platform, you’ll need to change the image field in the Deployment to be the appropriate image for your platform.
The default adapter configuration should work for this walkthrough and a standard Prometheus Operator configuration, but if you’ve got custom relabelling rules, or your labels above weren’t exactly namespace and pod, you may need to edit the configuration in the ConfigMap. The configuration walkthrough provides an overview of how configuration works.
Sources & further reading
Spotted something that needs another look?
Help improve this page →