Kubernetes Autoscaling Interaction

Kubernetes Autoscaling Interaction is the study of how the Horizontal Pod Autoscaler, Vertical Pod Autoscaler, and Cluster Autoscaler influence one another when deployed together on the same cluster, since each operates its own independent control loop yet all three ultimately compete for and shape the same underlying resource: available node capacity. Deploying them without understanding these interactions risks conflicting decisions, unexpected oscillation, or capacity shortfalls that no single autoscaler's configuration, viewed in isolation, would explain.

HPA and VPA on the Same Workload

The Feedback Loop Problem

When VPA manages a resource dimension (commonly CPU) that an HPA also uses as its utilization metric, VPA's resizing of a container's request directly changes the denominator of the HPA's utilization calculation — a VPA-driven increase in CPU request lowers the computed utilization percentage even with unchanged actual usage, which can suppress an HPA scale-up that would otherwise have occurred, or vice versa.

Recommended Separation of Concerns

The generally recommended pattern assigns each autoscaler a distinct resource dimension on the same workload — VPA managing memory while HPA scales replicas based on CPU utilization, for instance — avoiding direct interference between the two while still benefiting from both mechanisms.

# VPA scoped to memory only
resourcePolicy:
  containerPolicies:
  - containerName: app
    controlledResources: ["memory"]

# HPA scoped to CPU only
metrics:
- type: Resource
  resource:
    name: cpu
    target: { type: Utilization, averageUtilization: 70 }

Pod-Level Scaling Driving Cluster Autoscaler Activity

Replica and Resize Events Cascading to Node Demand

Both an HPA increasing replica count and a VPA increasing per-pod resource requests raise the aggregate resource demand across the cluster; if existing node capacity cannot absorb this increase, the resulting unschedulable pods trigger the Cluster Autoscaler's own independent scale-up flow, adding its own latency on top of whatever delay the pod-level autoscaler already introduced.

Compounding Latency Across Sequential Control Loops

Because the Cluster Autoscaler's scale-up flow only begins once pods are actually observed as unschedulable, a demand spike that requires both new replicas and new nodes experiences the full latency of both control loops in sequence — HPA reconciliation and pod scheduling delay, followed by node provisioning and bootstrap time — rather than either loop's delay alone.

Setting Compatible Bounds Across Mechanisms

Aligning HPA maxReplicas With Cluster Capacity

An HPA's maxReplicas set well beyond what the Cluster Autoscaler's node group maximums can accommodate produces pods that remain permanently unschedulable once the cluster reaches its own ceiling, silently capping effective scaling capacity at a lower value than the HPA configuration implies.

# HPA
maxReplicas: 100

# Cluster Autoscaler node group — must provide enough headroom for 100 replicas
cluster-autoscaler --nodes=5:30:general-purpose-pool

VPA maxAllowed Versus Node Instance Sizes

A VPA's maxAllowed value for a container should be sized with awareness of the largest available node instance type in the relevant node group, since a recommendation exceeding what any single node can accommodate produces a pod that can never be scheduled regardless of how much the Cluster Autoscaler tries to provision additional capacity.

Designing Coordinated Autoscaling Configurations

Testing Combined Behavior Under Load

Because the interaction between multiple autoscalers is difficult to reason about purely from individual configurations, load-testing a workload with all relevant autoscalers active simultaneously — rather than testing each in isolation — reveals emergent behavior (oscillation, cascading delay, capacity gaps) that isolated testing would miss.

Documenting the Intended Division of Responsibility

Recording explicitly which autoscaling mechanism is responsible for which resource dimension on a given workload — in code comments, runbooks, or manifest annotations — helps future operators understand the intended design rather than needing to reverse-engineer it from potentially conflicting configuration values discovered independently.

Monitoring the Combined System

Correlating Events Across All Three Mechanisms

Reviewing HPA scaling events, VPA recommendation and eviction events, and Cluster Autoscaler scale-up/scale-down events together, rather than any single mechanism's logs in isolation, is necessary to diagnose scaling behavior that spans multiple layers — a workload experiencing degraded performance during a demand spike may show an HPA scaling correctly but blocked by insufficient node capacity, which only becomes visible by examining the Cluster Autoscaler's own activity alongside the HPA's.