Kubernetes Autoscaling Definition

Kubernetes Autoscaling Definition is the precise characterization of autoscaling as an independent, closed-loop control process that formally observes a defined metric, compares it against a defined target, and adjusts a defined scaling dimension, replica count, per-container resource allocation, or node count, accordingly, without requiring any single, unified autoscaling object; the three formally recognized autoscaling controllers, the Horizontal Pod Autoscaler, the Vertical Pod Autoscaler, and the Cluster Autoscaler, each apply this same control-loop pattern to a distinct, non-overlapping scaling dimension.

The Formal Control-Loop Pattern

Shared Structure

Every Kubernetes autoscaler formally conforms to the same abstract loop: observe a current metric value, compute a target value or desired state from that metric, compare the two, and issue an adjustment action if they diverge beyond a defined tolerance, repeated on a periodic evaluation interval.

Distinguishing Scaling Dimension

What formally differentiates the three autoscalers is exclusively the dimension each one adjusts; none of them share an adjustment target, and none formally supersedes or subsumes another's function.

Horizontal Pod Autoscaler

Formal Target

The Horizontal Pod Autoscaler (HPA) formally adjusts the replicas field of a scalable workload, a Deployment, ReplicaSet, or StatefulSet, computing a desired replica count from one or more observed metrics relative to a per-replica target value.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: codartium-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: codartium-api
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Vertical Pod Autoscaler

Formal Target

The Vertical Pod Autoscaler (VPA) formally adjusts a workload's container-level resources.requests and resources.limits, computed from historical observed usage rather than the current instantaneous metric value that drives the HPA, targeting correct per-replica sizing rather than replica count.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: codartium-worker-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: codartium-worker
  updatePolicy:
    updateMode: "Auto"

Formal Incompatibility with HPA on the Same Metric

Because the VPA's adjustment to a container's requests formally alters the denominator the HPA uses when computing utilization for that same metric, configuring both to act on the same resource dimension of the same workload produces formally unstable, mutually interfering behavior, and is therefore disallowed in practice.

Cluster Autoscaler

Formal Target

The Cluster Autoscaler formally adjusts the number of nodes in the cluster, adding nodes when Pods remain unschedulable due to insufficient aggregate capacity, and removing nodes whose utilization falls persistently below a configured threshold and whose workloads can be safely relocated.

Formal Constraints on Scale-Down

Node removal is formally gated by defined safety constraints, including active PodDisruptionBudgets, non-evictable local storage, and Pods explicitly marked as non-evictable, meaning a persistently underutilized node is not necessarily removable if doing so would violate one of these constraints.

kubectl get hpa
kubectl get vpa
kubectl -n kube-system get deployment cluster-autoscaler

Formal Composition of the Three Layers

No Shared Control Object

Because each autoscaler formally targets a distinct dimension, all three can operate simultaneously and independently within the same cluster without a formal conflict, provided the VPA and HPA are not configured against the same resource metric of the same workload, since only that specific combination formally produces interference.

Why Autoscaling Is Formally Split This Way

Defining autoscaling as three independently scoped control loops, rather than a single mechanism adjusting multiple dimensions at once, is what formally allows each to be reasoned about, configured, and enabled or disabled in isolation, reflecting that replica count, per-replica sizing, and node capacity are, in general, orthogonal concerns requiring independently tunable feedback loops.