Autoscaling is a chain of control loops

Workload scaling changes desired replicas. Scheduling decides placement. Node autoscaling reacts to unschedulable Pods and asks a provider for capacity. Bootstrap, readiness and downstream limits add delay. A desired replica count is therefore not the same as ready capacity.

HPA math

The base equation is:

desired = ceil(currentReplicas * currentMetric / desiredMetric)

For 6 replicas at average 140 with a target of 70, the base result is 12, not an unanchored percentage guess. Kubernetes then applies readiness and missing- metric handling, tolerance, min/max bounds, scaling policies and stabilization.

Capacity math

required_vCPU = replicas * request_vCPU

Ten Pods requesting 4 vCPU require 40 vCPU. If a node has 8 allocatable vCPU, CPU alone requires at least ceil(40 / 8) = 5 nodes. Three nodes provide only 24 vCPU and cannot satisfy the request. Memory, DaemonSet overhead, per-Pod shape, affinity, zones and volumes can require more.

Use queue backlog and oldest age for asynchronous work, not CPU alone. Bound worker concurrency by the queue and downstream services. For scale-down, drain requests, finish or release leases, stabilize recommendations, and verify Pod disruption and rescheduling before consolidating Nodes.

Scenarios

Sources

• Horizontal Pod Autoscaling
• Node autoscaling
• Container resource requests
• KEDA scaling deployments