Kubernetes Autoscaling Reliability Basics

Kubernetes Autoscaling Reliability Basics is the intersection between autoscaling mechanisms and the reliability guarantees covered elsewhere in this knowledge area, addressing specifically how the Horizontal Pod Autoscaler's minimum replica floor, its stabilization window, the cluster autoscaler's respect for disruption budgets, and the Vertical Pod Autoscaler's restart behavior each interact with, and must be tuned consistently with, a workload's broader reliability posture.

minReplicas as the Reliability Floor

The Autoscaler Never Reduces Below This Value

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  minReplicas: 3
  maxReplicas: 10

Regardless of how low measured load drops, the Horizontal Pod Autoscaler never reduces replica count below minReplicas, meaning this value, not the autoscaler's dynamic behavior, is what actually determines the reliability floor discussed under replica reliability; minReplicas should be chosen using the same N+1 redundancy and disruption-budget-compatibility reasoning applied to any fixed replica count, not treated as a purely cost-driven minimum.

Stabilization Windows Against Flapping

Preventing Rapid Scale-Up/Scale-Down Oscillation

spec:
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
    scaleUp:
      stabilizationWindowSeconds: 0

Without a stabilization window, a metric hovering near its target threshold can cause the autoscaler to add and remove replicas repeatedly in quick succession, each removal potentially disrupting in-flight requests on the removed replica; a longer scaleDown stabilization window (commonly asymmetric, longer than scaleUp's) smooths out this oscillation by requiring load to remain reduced for a sustained period before capacity is actually removed.

Reaction Lag Against Sudden Load Spikes

The Gap Between Load Increase and New Capacity Ready

Horizontal scaling is not instantaneous: metric collection has its own delay, the scheduler must place new pods, and those pods must pass their readiness probes before contributing capacity, meaning a sudden, sharp traffic spike can exceed current capacity for a real, non-zero window before the autoscaler's response actually takes effect; workloads with highly spiky, unpredictable load patterns need either a larger standing buffer above typical load or a more aggressive scaleUp policy to shrink this exposure window.

spec:
  behavior:
    scaleUp:
      policies:
        - type: Percent
          value: 100
          periodSeconds: 15

An aggressive scaleUp policy, doubling capacity within a short period, reduces this exposure window at the cost of potentially over-provisioning briefly if the spike is short-lived, a deliberate trade-off in favor of availability over cost efficiency during genuine demand surges.

Cluster Autoscaler Respect for Disruption Budgets

Scale-Down Safety Checks

apiVersion: policy/v1
kind: PodDisruptionBudget
spec:
  minAvailable: 2

The cluster autoscaler, when consolidating underutilized nodes, evicts pods through the same eviction API that disruption budget basics describes, meaning it will not scale down a node whose pod eviction would violate an existing PodDisruptionBudget, correctly deferring node removal rather than compromising a workload's declared availability floor purely for cost optimization.

Vertical Pod Autoscaler Restart Risk

Resizing Requires Pod Replacement

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
spec:
  updatePolicy:
    updateMode: "Auto"

Unless a cluster supports in-place pod resource resizing, applying a VPA-recommended resource change requires evicting and recreating the affected pod, a disruptive action for that specific replica; updateMode: "Auto" accepts this disruption automatically according to its own internal eviction logic (which does respect disruption budgets), while "Initial" or "Off" modes apply recommendations only at pod creation or not at all, trading responsiveness to changing resource needs against avoiding unplanned restarts of already-running, healthy replicas.

Combining HPA and PDB Consistently

Avoiding a Contradictory Configuration

# HPA
minReplicas: 2
# PDB
minAvailable: 2

Setting a PodDisruptionBudget's minAvailable equal to an HPA's minReplicas leaves zero disruption tolerance whenever the autoscaler has scaled down to its floor, effectively blocking any voluntary eviction during low-load periods; these two values should be chosen together so the budget always leaves genuine headroom relative to whatever the autoscaler's current floor happens to be.

Relationship to Replica Reliability, Disruption Budget Basics, and the Reliability Model

Autoscaling reliability basics is the meeting point between the dynamic capacity management covered by autoscaling as its own discipline and the static reliability guarantees, replica floors, disruption budgets, covered elsewhere in this knowledge area: correctly configuring minReplicas, stabilization windows, and scale-up aggressiveness is what ensures a workload's autoscaling behavior actively supports, rather than silently undermines, the redundancy and controlled-disruption principles the broader reliability model establishes.