External Metrics Mechanisms

Welcome. This guide explains how Kubernetes external metrics work with the Horizontal Pod Autoscaler (HPA), why they matter, and how to put them into production. External metrics differ from native resource metrics (CPU/memory) and application-level custom metrics. They originate outside the cluster (or outside the pod resource model) and are made available to the HPA so scaling decisions can be based on external systems and services.

A slide titled "HPA External Metrics" showing an HPA box containing a "K8s External Metrics" block. An arrow points from the HPA box to a laptop icon labeled "External Metrics."

Why use external metrics?

Scale based on external systems such as cloud-managed queues, third-party APIs, or external load balancers.
Make proactive scaling decisions from signals that don’t exist inside pod metrics (for example, queue backlog or external request rate).
Integrate infrastructure- or business-level signals (billing events, backlog thresholds, SaaS metrics) into Kubernetes autoscaling.

Common examples:

A cloud-based message queue backlog drives additional consumers.
An external load balancer’s observed request rate determines replica count.

A presentation slide titled "HPA External Metrics" that says external metrics enable scaling based on external factors. It shows two examples: length of a message queue in a cloud service and rate of incoming requests from an external load balancer.

Architecture and data flow External metrics rely on a small set of components working together:

External metric source: the cloud provider, message queue, or third-party service exposing the metric.
Collection/monitoring system: gathers metrics from the external source (examples: Prometheus, cloud monitoring like Cloud Monitoring / CloudWatch).
Metrics adapter: translates collected metrics into the Kubernetes External Metrics API so the HPA can query them.
HPA: requests metrics via the Kubernetes API and uses the returned values to scale workloads.

Think: the monitoring system is the scout that fetches values, and the adapter is the translator exposing them to Kubernetes. Components summary

Component	Purpose	Example
External metric source	Origin of the metric (outside the cluster)	Cloud queue backlog, external LB request rate
Collector / monitoring	Pulls or receives external metrics	Prometheus, Cloud Monitoring / CloudWatch
Metrics adapter	Implements Kubernetes External Metrics API and bridges collector → K8s API	`prometheus-adapter`, cloud provider adapters
HPA	Queries the External Metrics API and makes scaling decisions	`HorizontalPodAutoscaler` (autoscaling/v2)

The default Kubernetes Metrics Server only serves resource metrics (CPU/memory) and does not expose external metrics. Deploy a metrics adapter that implements the External Metrics API (for example, the Prometheus Adapter or a cloud-specific adapter) to allow the HPA to consume external signals.

Important considerations

You need a reliable collector/monitoring layer that can fetch external values (via scraping, API polling, or event ingestion).
An in-cluster metrics adapter must be configured to expose metrics through the Kubernetes External Metrics API.
The adapter must support querying metrics by name and labels so the HPA can target the correct time series.
Validate auth, network connectivity, and metric naming between source → collector → adapter → HPA.

A presentation slide titled "HPA External Metrics – Considerations" showing three colored icons and labels: "Metrics server limitation", "Adapter configuration", and "Monitoring systems." The slide appears to outline key considerations for external metrics in horizontal pod autoscaling.

Practical configuration tips

Choose a monitoring backend that reliably collects your external signal (queue depth, request rate, third-party metric).
Select an adapter compatible with your metric store (for Prometheus, use the Prometheus Adapter; for cloud metrics, use the cloud provider’s adapter).
In the HPA spec, reference the external metric by name and supply label selectors if required to match the right series.
Test the full pipeline (external source → collector → adapter → Kubernetes API → HPA) and validate both metric accuracy and timeliness.

Example: HPA referencing an external metric (autoscaling/v2)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: example-external-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: External
      external:
        metric:
          name: queue_messages_ready
          selector:
            matchLabels:
              queue: orders
        target:
          type: Value
          value: "100"

Testing and observability checklist

Confirm the collector is scraping/pulling the external metric and exposing it in the monitoring backend.
Verify the adapter reports the metric through the Kubernetes External Metrics API:
- kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" (adapter dependent)
Check HPA events and status:
- kubectl describe hpa example-external-hpa
Monitor adapter and collector logs/alerts to detect failures or missing series.

If the adapter or collector is misconfigured or unavailable, the HPA will not receive external metrics and scaling may not occur. Continuously monitor adapter health and metric endpoints to avoid gaps in autoscaling.

Manual Scaling

Horizontal Pod Autoscaler (HPA)

Vertical Pod Autoscaler (VPA)

Cluster Proportional Autoscaler (CPA)

Kubernetes Event-Driven Autoscaling (KEDA)

Introduction

External Metrics Mechanisms

Watch Video

Practice Lab