Kubernetes Workload Scaling Control

Kubernetes Workload Scaling Control is the set of mechanisms through which the number of Pod replicas a workload controller maintains is changed, spanning manual adjustment, the scale subresource that unifies scaling across different controller kinds, and the automated scaling controllers that adjust replica counts based on observed metrics rather than a fixed, manually set number.

The scale Subresource

A Uniform Interface Across Controller Types

Deployments, ReplicaSets, and StatefulSets each expose a scale subresource, a minimal, standardized representation containing just spec.replicas and status.replicas, distinct from the resource's own full spec and status. This subresource is what allows generic tooling, kubectl scale, the HorizontalPodAutoscaler, to scale any of these controller types through one consistent interface without needing type-specific logic.

kubectl scale deployment scaling-control-example --replicas=5

apiVersion: autoscaling/v1
kind: Scale
metadata:
  name: scaling-control-example
spec:
  replicas: 5
status:
  replicas: 3
  selector: app=web

Manual Scaling

Direct replicas Edits

The simplest form of scaling control is a direct edit to spec.replicas, either through kubectl scale, kubectl edit, or applying an updated manifest. This does not trigger a rollout in the Deployment sense, since no template hash changes; it only adjusts the target count the controller's reconciliation loop works toward.

spec:
  replicas: 8

HorizontalPodAutoscaler

Metric-Driven Automatic Adjustment

A HorizontalPodAutoscaler targets a scalable controller through the scale subresource and periodically adjusts spec.replicas based on observed metrics, most commonly average CPU or memory utilization across the controlled Pods, compared against a configured target.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: scaling-control-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: scaling-control-example
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Custom and External Metrics

Beyond built-in resource metrics, the HorizontalPodAutoscaler can scale based on custom metrics exposed through the metrics API, such as request queue depth or requests per second, letting scaling decisions reflect application-specific load signals rather than only CPU or memory pressure.

Stabilization and Scaling Behavior

Avoiding Flapping

spec.behavior on a HorizontalPodAutoscaler configures stabilization windows and rate limits separately for scale-up and scale-down events, preventing rapid oscillation in replica count when a metric hovers near its target threshold.

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

Interaction With Rolling Updates

Scaling During a Rollout

Manual or automated scaling that occurs while a Deployment rollout is in progress is respected by the rollout logic, the total desired replica count target simply changes mid-flight, and the controller continues distributing Pods between old and new ReplicaSets according to maxSurge and maxUnavailable against the new total.

Scaling Control Diagram

Because both manual and automated scaling ultimately converge on the same spec.replicas field through the shared scale subresource, a controller's reconciliation loop treats every source of a replica count change identically, regardless of whether a human or the HorizontalPodAutoscaler initiated it.