One of the tenets of cloud computing is pay-as-you-go resource consumption. We can consume cloud services when needed, and only as much as needed. CA can inter‐ act with cloud providers where Kubernetes is running, and request additional nodes during peak times or shut down idle nodes during other times, reducing infrastruc‐ ture costs. While HPA and VPA perform Pod-level scaling and ensure service capacity elasticity within a cluster, CA provides node scalability to ensure cluster capacity elasticity. CA is a Kubernetes addon that has to be turned on and configured with a minimum and maximum number of nodes. It can function only when the Kubernetes cluster is running on a cloud-computing infrastructure where nodes can be provisioned and decommissioned on demand and that has support for Kubernetes CA, such as AWS, Microsoft Azure, or Google Compute Engine. All major cloud providers support Kubernetes CA. However, to make this happen, plugins have been written by cloud providers, leading to vendor locking and inconsis‐ tent CA support. Luckily there is the Cluster API Kubernetes project, which aims to provide APIs for cluster creation, configuration, and management. All major public and private cloud providers like AWS, Azure, GCE, vSphere, and OpenStack support this initiative. This also allows CA on on-premises Kubernetes installations. The heart of the Cluster API is a machine controller running in the background, for which sev‐ eral independent implementations like the Kubermatic machine-controller or the machine-api-operator by Open‐Shift already exist. It is worth keeping an eye on the Cluster API as it may become the backbone for any cluster autoscaling in the future. A CA performs primarily two operations: add new nodes to a cluster or remove nodes from a cluster. Let’s see how these actions are performed: If you have an application with a variable load (busy times during the day, week‐ end, or holiday season, and much less load during other times), you need varying capacity to meet these demands. You could buy fixed capacity from a cloud pro‐ vider to cover the peak times, but paying for it during less busy periods reduces the benefits of cloud computing. This is where CA becomes truly useful. When a Pod is scaled horizontally or vertically, either manually or through HPA or VPA, the replicas have to be assigned to nodes with enough capacity to satisfy the requested CPU and memory. If there is no node in the cluster with enough capacity to satisfy all of the Pod’s requirements, the Pod is marked as  unschedula‐ ble  and remains in the waiting state until such a node is found. CA monitors for Adding a new node (scale-up) Cluster API 214  |  Chapter 24: Elastic Scale