OpenShift Auto Scaling with Horizontal Pod Autoscaler (HPA)

Learn how Horizontal Pod Autoscaler (HPA) automatically scales Spring Boot applications on OpenShift using CPU, memory, and custom metrics. Understand HPA architecture, metrics pipeline, scaling policies, and enterprise best practices.

Introduction

Enterprise applications experience different traffic patterns throughout the day.

Examples:

Banking applications during salary credit days
E-commerce websites during Black Friday sales
Insurance portals during policy renewal periods
Payment platforms during holiday shopping
Airline booking systems during festivals

Keeping a fixed number of Pods is inefficient.

Too few Pods cause:

High response times
Request failures
CPU exhaustion

Too many Pods result in:

Increased infrastructure costs
Underutilized resources

OpenShift solves this using the Horizontal Pod Autoscaler (HPA), which automatically increases or decreases the number of Pods based on application demand.

Learning Objectives

By the end of this article, you will understand:

What is Horizontal Pod Autoscaler?
HPA Architecture
CPU-based Scaling
Memory-based Scaling
Custom Metrics
Spring Boot Integration
Metrics Server
Scaling Policies
Enterprise Best Practices

What is HPA?

Horizontal Pod Autoscaler automatically changes the number of application Pods based on resource utilization or custom metrics.

Typical scaling metrics include:

CPU Usage
Memory Usage
Request Rate
Queue Length
Kafka Consumer Lag
Custom Business Metrics

Why Auto Scaling?

Without HPA:

flowchart LR
    A[1000 Users]
    B[2 Pods]

    A --> B

Problems:

CPU reaches 100%
Slow API responses
Request timeouts

With HPA

flowchart LR
    A[1000 Users]
    B[OpenShift Service]

    C[Pod 1]
    D[Pod 2]
    E[Pod 3]
    F[Pod 4]
    G[Pod 5]

    A --> B
    B --> C
    B --> D
    B --> E
    B --> F
    B --> G

OpenShift automatically creates additional Pods.

HPA Architecture

flowchart LR
    A[Spring Boot Pods]
    B[Metrics Server]
    C[Horizontal Pod Autoscaler]
    D[Deployment]

    A --> B
    B --> C
    C --> D

Scaling Workflow

sequenceDiagram
    participant User
    participant SpringBoot
    participant MetricsServer
    participant HPA

    User->>SpringBoot: Heavy Traffic

    SpringBoot->>MetricsServer: CPU Metrics

    MetricsServer->>HPA: CPU > Target

    HPA->>SpringBoot: Increase Replicas

CPU-Based Scaling

Example:

Current Pods = 2
CPU Usage = 90%
Target CPU = 70%

Result:

Pods increase

2

↓

4

Memory-Based Scaling

Applications with high memory usage can scale automatically.

Example:

Memory

85%

↓

New Pods Created

HPA Resource Flow

flowchart LR
    A[CPU]
    B[Memory]
    C[Metrics Server]
    D[HPA]

    A --> C
    B --> C
    C --> D

Spring Boot Metrics

Spring Boot exposes metrics using:

Spring Boot Actuator
Micrometer
Prometheus

Example dependency:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Enable Metrics

management.endpoints.web.exposure.include=health,prometheus

management.metrics.export.prometheus.enabled=true

HPA Configuration

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:
  name: payment-service

spec:

  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payment-service

  minReplicas: 2

  maxReplicas: 10

  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Scaling Process

flowchart LR
    A[Traffic Increases]
    B[CPU > 70%]
    C[HPA]
    D[Increase Replicas]

    A --> B
    B --> C
    C --> D

Scale Down

When traffic decreases:

flowchart LR
    A[Traffic Drops]
    B[CPU < Target]
    C[HPA]
    D[Remove Extra Pods]

    A --> B
    B --> C
    C --> D

Enterprise Banking Example

During salary day:

flowchart TD
    A[Internet Users]
    B[OpenShift Route]
    C[Payment Service]

    D[Pod 1]
    E[Pod 2]
    F[Pod 3]
    G[Pod 4]
    H[Pod 5]

    A --> B
    B --> C

    C --> D
    C --> E
    C --> F
    C --> G
    C --> H

The payment service automatically scales to handle increased traffic.

Custom Metrics

HPA can also scale based on business metrics.

Examples:

Orders Per Minute
Kafka Consumer Lag
Queue Size
Active Sessions
Payments Per Second

Custom Metrics Architecture

flowchart LR
    A[Spring Boot]
    B[Micrometer]
    C[Prometheus]
    D[Prometheus Adapter]
    E[HPA]

    A --> B
    B --> C
    C --> D
    D --> E

Enterprise Auto Scaling

flowchart TD
    A[Users]

    B[OpenShift Router]

    C[Service]

    D[Horizontal Pod Autoscaler]

    E[Pod 1]
    F[Pod 2]
    G[Pod 3]
    H[Pod 4]

    A --> B
    B --> C
    C --> D

    D --> E
    D --> F
    D --> G
    D --> H

View HPA

oc get hpa

Example Output

NAME              CPU   MIN   MAX   REPLICAS

payment-service   55%    2    10        3

Useful Commands

Create HPA

oc apply -f hpa.yaml

Describe HPA

oc describe hpa payment-service

View Pods

oc get pods

View Deployment

oc get deployment

Common Problems

HPA Not Scaling

Verify:

Metrics Server is running
CPU requests are configured
Metrics are available

CPU Always Zero

Check Deployment resources:

resources:

  requests:

    cpu: "500m"

Without resource requests, HPA cannot calculate utilization correctly.

Pods Scale Frequently

Possible causes:

Target CPU too low
Sudden traffic spikes
Short stabilization window

Tune HPA behavior to avoid oscillation.

Production Best Practices

Configure CPU and memory requests.
Set realistic minimum replicas.
Define an appropriate maximum replica count.
Monitor scaling events.
Combine HPA with Cluster Autoscaler.
Use custom metrics for business workloads.
Avoid aggressive scaling policies.
Test under production-like load.
Monitor application latency in addition to CPU.
Use readiness probes with HPA.

Common Mistakes

❌ No CPU requests configured.

❌ Maximum replicas set too low.

❌ Scaling based only on CPU for every workload.

❌ Ignoring memory-intensive applications.

❌ No load testing before production.

❌ Very small minimum replica count for critical services.

Advantages

Automatic scaling
Better resource utilization
Reduced infrastructure costs
Improved application performance
Faster response to traffic spikes
Cloud-native elasticity
High availability
Enterprise-ready scaling

Summary

Horizontal Pod Autoscaler enables Spring Boot applications on OpenShift to automatically scale according to application demand.

Key takeaways:

HPA monitors CPU, memory, or custom metrics.
It increases or decreases Pod replicas automatically.
Spring Boot integrates with HPA through Actuator, Micrometer, and Prometheus.
Custom metrics enable business-driven scaling strategies.
Combining HPA with health probes and Cluster Autoscaler creates a resilient, cost-effective, and highly available platform.

Interview Questions

What is Horizontal Pod Autoscaler (HPA)?
How does HPA determine when to scale?
Why are CPU requests required for HPA?
What is the difference between HPA and Cluster Autoscaler?
Can HPA scale based on custom metrics?
How does Prometheus integrate with HPA?
What are common scaling metrics?
Why should HPA be combined with readiness probes?
How do you prevent frequent scaling oscillations?
What are the production best practices for HPA?