What is Kubernetes autoscaling?
Kubernetes autoscaling is the set of controllers that resize a cluster’s workloads and infrastructure as demand changes. Horizontal autoscaling changes the number of pod replicas, vertical autoscaling changes the CPU and memory each pod requests, and node autoscaling adds or removes worker nodes. Each one works on a different layer.
Think of a supermarket at rush hour. Opening more tills is horizontal scaling, giving one cashier a faster scanner is vertical scaling, and building a bigger shop is adding nodes. You can open tills in minutes, but only as many as the shop has room for.
What are the three kinds of autoscaling?
Horizontal Pod Autoscaler
The Horizontal Pod Autoscaler (HPA) is built into Kubernetes. Every 15 seconds by default, it compares a metric with your target and computes desired replicas as current replicas times current value divided by target value, rounded up. It works on anything with a scale subresource, such as a Deployment or StatefulSet, but not a DaemonSet.
CPU and memory metrics come from the metrics.k8s.io API, which the Metrics Server add-on usually provides. Custom and external metrics, such as queue length or requests per second, need their own metrics adapter.
Vertical Pod Autoscaler
The Vertical Pod Autoscaler (VPA) is an add-on, not part of a default cluster, and it needs the Metrics Server. It watches real usage and adjusts the requests of each pod. Depending on the update mode, it either recreates pods with new requests or resizes running pods in place, falling back to recreation when that fails.
Node autoscaling
Node autoscalers such as Cluster Autoscaler and Karpenter add nodes when pods cannot be scheduled on the existing ones. They remove nodes that are underused once their pods fit elsewhere. Cluster Autoscaler, for example, treats a node as a removal candidate when its pods request less than half its capacity for 10 minutes.
Why do resource requests matter?
Every autoscaler reads resource requests, not just live usage. The HPA computes CPU utilization as a share of each container’s request. If a container has no request, the HPA takes no action on that metric.
Node autoscalers also plan capacity from requests. A pod that requests 2 CPUs but uses 0.2 still blocks 2 CPUs on its node. Requests that are too high waste nodes, and requests that are too low pack pods so tightly that they slow each other down.
What goes wrong in practice?
- Scaling down too fast. The HPA waits 300 seconds by default before scaling down, so short dips do not remove pods you need a minute later.
- A fixed replica count in the manifest. If spec.replicas stays in your Deployment, each apply resets the count the HPA chose.
- No headroom for new pods. The HPA can add replicas only while nodes have free capacity, or while a node autoscaler can add more.
- Disruption during scale-down. Removing a node evicts its pods, so set a PodDisruptionBudget for anything that must keep a minimum number of replicas running.
How enum handles Kubernetes autoscaling
On enum Kubernetes Engine, workloads scale horizontally with demand, and you size node pools for your peak. There is no cluster or node autoscaling today, so plan node capacity for your largest expected load. Ask us about the metrics your autoscalers should use, or about planning capacity ahead of a known launch.
FAQ
Can the Horizontal Pod Autoscaler scale to zero? Only on recent Kubernetes versions, and only for object and external metrics, not for CPU or memory. For idle workloads that should wake on events, use an event-driven autoscaler such as KEDA.
Should I use HPA and VPA on the same workload? Not on the same metric. If both react to CPU, the VPA changes requests while the HPA scales on utilization of those requests, and they fight. Use the VPA for recommendations, or scale the HPA on a custom metric.
Do I need node autoscaling if my pods autoscale? Not always. The HPA only needs free capacity on existing nodes. Without node autoscaling, you size node pools for your peak and accept some idle capacity outside busy hours in exchange for predictable cost.