Skip to content

4.8. HPA (Horizontal Pod Autoscaler)

Overview

The HPA (Horizontal Pod Autoscaler) page manages every HPA held on the MCM control plane in one place. An HPA is the Kubernetes resource that adjusts the number of pod replicas automatically on a metric such as CPU utilisation or memory usage.

What it is for:

  • Managing multi-cluster HPAs together
  • Configuring and monitoring autoscaling
  • Scaling dynamically on resource usage
  • Distributing HPAs through a PropagationPolicy

Where HPAs are used:

  • Scaling out automatically when traffic grows
  • Optimising capacity against resource utilisation
  • Cost-efficient resource management
  • Keeping an application available
  • Automating the response to peak times

How the Screen Is Laid Out

The HPA page shows the HPA list as a table.

The HPA main screen

The Elements at the Top of the Page

ElementDescription
Namespace filterShows only the HPAs of a particular namespace
Refresh buttonRefreshes the HPA list
Create buttonOpens the dialog for creating a new HPA
Search boxSearches by HPA name

Table Columns

ColumnDescriptionSortable
NameThe HPA name
NamespaceThe namespace the HPA belongs to
Scale TargetThe resource being scaled (Deployment/my-deployment, for example)
Min ReplicasThe minimum pod count to keep
Max ReplicasThe maximum pod count to grow to
ReplicasCurrent replicas / desired replicas
AgeThe time since the HPA was created
ActionsThe edit and delete buttons-

How the Replicas Are Shown

The Replicas column shows the HPA's current scaling state:

  • Format: current replicas/desired replicas
  • For example 2/0 -- 2 pods now, 0 desired (waiting to scale down)
  • For example 3/5 -- 3 pods now, scaling up to 5

HPA Detail

Clicking an HPA row opens the detail panel.

HPA detail

The Detail Panel Header

ElementDescription
HPA nameThe name of the chosen HPA
NamespaceThe namespace the HPA belongs to
Replica stateCurrent replicas / desired replicas (2/0, for example)

The Action Buttons

ButtonWhat it does
RefreshRefreshes the HPA information
EditOpens the YAML edit mode
DeleteDeletes the HPA

The Tabs

The Overview Tab

Shows the HPA's basic information, scale configuration, and metrics.

Basic information:

ItemDescription
NameThe HPA name
NamespaceThe namespace the HPA belongs to
StatusThe replica state (2/0 ready, for example)
AgeThe time since creation
CreatedWhen the HPA was created

Scale Configuration:

ItemDescription
Scale TargetThe resource being scaled (Deployment/my-deployment, for example)
Min ReplicasThe minimum pod count to keep
Max ReplicasThe maximum pod count to grow to
Current ReplicasThe number of pods running now
Desired ReplicasThe pod count the HPA wants

Metrics:

Shows the metrics the HPA watches:

ItemDescription
Target CPUThe target CPU utilisation (75%, for example)
Target memoryThe target memory utilisation (where it is set)
Custom metricsCustom metrics (where they are set)

The Multi-Cluster Policies Tab

Shows the multi-cluster policies that apply to the HPA.

The multi-cluster policies tab

PropagationPolicy:

ColumnDescription
NameThe PropagationPolicy name
NamespaceThe namespace the policy belongs to
ScopeNamespace-scoped policies / cluster-scoped policies
Target ClustersThe list of target clusters

OverridePolicy:

Shown where there are per-cluster custom settings.

The Labels Tab

Shows the list of Kubernetes labels applied to the HPA.

The Annotations Tab

Shows the list of annotations applied to the HPA.

The Events Tab

Shows the Kubernetes events related to the HPA.

Creating an HPA

Creates a new HPA on the MCM control plane.

Fields

FieldRequiredDescription
NameThe HPA name
NamespaceThe namespace to deploy into
Scale TargetThe resource to scale
Min ReplicasThe minimum pod count (default: 1)
Max ReplicasThe maximum pod count
Target CPU utilisation-The target CPU utilisation (%)
Target memory utilisation-The target memory utilisation (%)

Editing the YAML

The "Edit YAML" tab lets you write the HPA definition directly.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: my-hpa
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-deployment
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 75

HPA Operations

Editing an HPA

  1. Choose the HPA
  2. Press the "Edit" button in the detail panel
  3. Change the HPA definition in the YAML editor
  4. Press the "Save" button

Note: changing an HPA affects its scaling behaviour at once. Change it carefully in a production environment.

Deleting an HPA

⚠️ Caution: deleting an HPA stops the automatic scaling. After that the replica count has to be managed by hand.

  1. Choose the HPA to delete
  2. Press the "Delete" button in the detail panel
  3. Type the HPA name in the confirmation dialog
  4. Press the "Delete" button

Worked Examples

Scenario 1: Creating a CPU-Based HPA

  1. Press the "Create" button
  2. Enter the HPA details:
    • Name: web-hpa
    • Namespace: production
    • Scale Target: Deployment/web-app
    • Min Replicas: 2
    • Max Replicas: 10
    • Target CPU utilisation: 70%
  3. Press the "Create" button
  4. Name the target clusters with a PropagationPolicy
  5. Monitor how the HPA scales

Scenario 2: Checking an HPA's Scaling State

  1. Click the HPA you want to check in the list
  2. Check the Scale Configuration on the Overview tab:
    • The current replica count
    • The desired replica count
    • The min and max replica settings
  3. Check the target utilisation in the Metrics section
  4. Check the scaling events on the Events tab

Scenario 3: Creating a Memory-Based HPA

  1. Press the "Create" button and choose the Edit YAML tab
  2. Write this YAML:
    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
    name: memory-hpa
    namespace: production
    spec:
    scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: memory-app
    minReplicas: 2
    maxReplicas: 8
    metrics:
    - type: Resource
    resource:
    name: memory
    target:
    type: Utilization
    averageUtilization: 80
  3. Press the "Create" button

Scenario 4: Creating an HPA on Several Metrics

  1. Press the "Create" button and choose the Edit YAML tab
  2. Set both CPU and memory:
    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
    name: multi-metric-hpa
    namespace: production
    spec:
    scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
    minReplicas: 3
    maxReplicas: 15
    metrics:
    - type: Resource
    resource:
    name: cpu
    target:
    type: Utilization
    averageUtilization: 70
    - type: Resource
    resource:
    name: memory
    target:
    type: Utilization
    averageUtilization: 80
  3. Press the "Create" button

Scenario 5: Deploying an HPA Across Clusters

  1. Create the HPA
  2. Create a PropagationPolicy:
    • Resource selector: name the HPA
    • Target clusters: choose the clusters to deploy to
  3. Check the "Multi-Cluster Policies" tab in the detail panel
  4. Confirm the HPA is working on each cluster

How an HPA Works

An HPA runs on this cycle:

  1. Collect the metric: gathers the named metric (CPU, memory and so on) periodically
  2. Work out the utilisation: compares the current utilisation against the target
  3. Work out the replicas: computes the desired replica count
  4. Scale: adjusts the replica count where needed

The formula:

desired replicas = ceil(current replicas * (current metric value / target metric value))

HPA against VPA

TraitHPAVPA
Direction of scalingHorizontal (more pods)Vertical (more resources)
What it adjustsThe replica countThe CPU and memory requests
Where it is usedResponding to a rise in trafficOptimising resources
DowntimeNoneThe pod has to restart

Scaling Policies

Scaling up:

  • Scales up when the metric passes the target
  • Scales up quickly by default
  • The speed can be controlled with the scaleUp policy

Scaling down:

  • Scales down when the metric falls below the target
  • Scales down after a stabilisation window (5 minutes) by default
  • The speed can be controlled with the scaleDown policy

Configuring the Scaling Behaviour

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: advanced-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app
minReplicas: 2
maxReplicas: 10
behavior:
scaleUp:
stabilizationWindowSeconds: 0
policies:
- type: Percent
value: 100
periodSeconds: 15
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 50
periodSeconds: 60
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70

Metric Types

TypeDescriptionExample
ResourceA resource metric such as CPU or memoryCPU utilisation 70%
PodsA pod metric (custom)Requests per second
ObjectA Kubernetes object metricThe Ingress request count
ExternalAn external metricThe queue length

Points to Watch with Multi-Cluster HPAs

When deploying an HPA to several clusters through MCM:

PropagationPolicy:

  • Copies the HPA to several clusters
  • Each cluster scales independently
  • Each cluster scales itself on its local metrics

OverridePolicy:

  • Applies different scaling settings per cluster
  • For example, a different maximum replica count per cluster
  • For example, a different target utilisation per cluster

Points to watch:

  • The HPA works independently on each cluster
  • Global scaling at the level of all clusters needs a separate arrangement
  • Traffic distribution between clusters is managed at the Ingress or Service level

Good Practice for HPAs

  1. Set a sensible target utilisation: 50 to 80% is generally recommended
  2. Set the minimum replicas: 2 or more is recommended for high availability
  3. Cap the maximum replicas: set an upper bound with resource cost in mind
  4. Set resource requests: an HPA needs pod resource requests to work correctly
  5. Scale gradually: set policies to prevent abrupt scaling
  6. Monitor: keep watching the HPA events and metrics

Next Steps