HPA Multiple Metrics

Welcome. In this lesson we’ll cover how to use multiple metrics with the Horizontal Pod Autoscaler (HPA) to build more accurate, reliable autoscaling policies. Why this matters: a complex microservices application (for example, an e‑commerce platform) can show different load characteristics across services. Scaling only by CPU or memory may not reflect actual application load — you may need to combine resource metrics (CPU) with application-level metrics (request rate, active HTTP requests, queue length) to scale the right component at the right time.

A presentation slide titled "When Do We Need Multiple Metrics?" showing an "E‑Commerce Application" icon and three colored circles representing stages: Browsing products, Adding to cart, and Processing transactions. The slide includes simple line icons for each stage and a small © Copyright KodeKloud note.

Consider an e‑commerce stack split into microservices: product-catalog, cart service, and transaction processor. Each service may require different scaling signals—product-catalog might need CPU plus incoming request rate, while transaction processing may need concurrency or queue length. Multiple metrics let HPA satisfy the strictest requirement across the configured metrics.

A slide titled "When Do We Need Multiple Metrics?" showing a laptop with a rising chart and the caption "To efficiently scale the application during peak traffic." To the right is an icon of a person linked to multiple documents with the caption "Scaling requires considering multiple metrics at once."

Architecture and required components

Cluster resource metrics: Ensure a working cluster metrics pipeline (metrics-server) to provide resource metrics like CPU and memory.
Application instrumentation: Expose custom application metrics (e.g., active HTTP requests, requests per second, queue length) via Prometheus or another collector.
Metrics adapter: Deploy an adapter (for example, Prometheus Adapter) to make custom metrics available through the Kubernetes metrics API so HPA can consume them.

How HPA evaluates multiple metrics

HPA reads all configured metrics (resource and external/custom).
For each metric, HPA computes the desired replica count required to meet that metric’s target.
The HPA then scales to the highest of those desired replica counts so that all targets are satisfied.

Example: scale a Deployment named backend-service by CPU utilization and a custom per-pod metric active_http_requests:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: backend-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: backend-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: active_http_requests
      target:
        type: AverageValue
        averageValue: "100"

Notes about the configuration:

averageUtilization: 70 targets ~70% CPU utilization across the pods.
The Pods metric type with AverageValue targets an average of 100 active_http_requests per pod. The adapter must expose active_http_requests as a pods-scoped metric.
HPA evaluates both metrics and scales to the highest computed replica count.

Metric types at a glance

Metric Type	Scope	Best for	Example
Resource	Pod/Container	CPU & memory-driven scaling	`cpu` utilization
Pods	Per-pod custom	Metrics that are naturally measured per pod (concurrency, active requests)	`active_http_requests`
External	Cluster/external service	Metrics external to pods (queue length in external system, cloud metrics)	`sqs_queue_length`

When NOT to use multiple metrics

Metrics are not correlated to actual service load (e.g., CPU stuck at high value with no request changes).
The metrics adapter or metric source is unreliable or hard to maintain.
Metrics have incompatible sampling intervals or units (one metric sampled every second vs another every 10 minutes).
The added complexity of reconciling multiple metrics outweighs autoscaling benefits.

A presentation slide titled "Using Multiple Metrics for Scaling – When to Avoid" showing three colored columns—Non-Correlated Metrics, Complex Adapters Metrics, and Different Sampling Rates—with icons and bullet points describing when not to use multiple metrics. The slide also includes a small © Copyright KodeKloud notice.

Ensure your cluster has a working metrics pipeline (metrics-server) and a compatible adapter (for example, the Prometheus Adapter) before relying on custom metrics for HPA. Verify sampling intervals, metric names, and scope (pods vs. external) to avoid surprising behavior.

Best practices

Start simple: use a single well-understood metric and validate behavior.
Use per-pod metrics when the metric is tightly coupled to workload per replica (like concurrent requests).
Ensure consistent scraping intervals and retention in your monitoring system.
Test scaling behavior under realistic load patterns and validate that the highest computed replica count is the correct safe option.

Summary Multiple metrics let you express richer autoscaling policies (e.g., combine CPU and request rate) and help you scale the right microservice at the right time. However, they require reliable instrumentation, a functioning metrics adapter, and careful attention to metric correlation and sampling. Balance complexity against the value added and choose metrics that best reflect real workload characteristics. Links and references

Kubernetes Autoscaling (HPA): https://learn.kodekloud.com/user/courses/kubernetes-autoscaling
metrics-server: https://github.com/kubernetes-sigs/metrics-server
Prometheus Adapter: https://github.com/prometheus-community/prometheus-adapter
Prometheus monitoring course: https://learn.kodekloud.com/user/courses/youtube-labs-monitoring-kubernetes-with-prometheus

We will get hands-on with this setup so you can see it in action.

Manual Scaling

Horizontal Pod Autoscaler (HPA)

Vertical Pod Autoscaler (VPA)

Cluster Proportional Autoscaler (CPA)

Kubernetes Event-Driven Autoscaling (KEDA)

Introduction

HPA Multiple Metrics

Watch Video

Practice Lab