The Deployments chapter showed us how to scale the number of Pod replicas manually. However, manually scaling a set of Pods does not scale (excuse the pun). As an example, if demand on your application spikes at 4:20 a.m., it’s far from ideal if you need to page an operator who will then log on to the cluster and manually increase the number of replicas. The same applies if you need to scale the number of nodes to your cluster.

With these challenges in mind, Kubernetes offers several auto-scaling technologies.

The Horizontal Pod Autoscaler (HPA) dynamically increases and decreases the number of Pods in a Deployment based on demand.

The Cluster Autoscaler (CA) dynamically increases and decreases the number of nodes in your cluster based on demand.

The Vertical Pod Autoscaler (VPA) attempts to right-size your Pods, but it’s currently an alpha product.

Horizontal Pod Autoscaler (HPA)

HPA’s are stable resources in the autoscaling/v1 API group, and their job is to scale the number of replicas in a Deployment based on observed CPU metrics. At the time of writing, the autoscaling/v2 API is being worked on and will allow scaling based on more than just CPU.

It works like this: you define a Deployment that makes use of Pod resource requests – where each container in the Pod requests an amount of CPU. You deploy this to the cluster. You also create an HPA object that targets that Deployment and has a rule that says something like: if any Pod in this Deployment uses more than 60% of its requested CPU, spin up an additional Pod.

Once the Deployment and HPA are deployed to the cluster, scaling operations become automatic.

One thing worth noting is that HPAs update the .spec.replicas field of the targeted Deployment. While this update is recorded against the Deployment object in the cluster store, it can lead to situations where the copy of the Deployment YAML file in your external version control system gets out of sync with what is currently observed on the cluster.