What OpenShift’s Cluster Autoscaler needs before it can add a node

Red Hat has published a detailed Cluster Autoscaler walkthrough for OpenShift 4.20 on Microsoft Azure, and its most useful lesson is that installing a cluster-wide policy is only the beginning. The autoscaler needs an eligible MachineSet, realistic bounds and enough metadata to prove that a hypothetical new node can actually run the pending workload.

Two resources, two jobs

OpenShift exposes a cluster-scoped ClusterAutoscaler resource for global limits and a MachineAutoscaler resource for each MachineSet that may grow. Red Hat’s example stresses that the first resource cannot scale anything by itself: without a corresponding MachineAutoscaler, there is no node group with minimum and maximum replica bounds to expand.

The walkthrough also distinguishes raw capacity from allocatable capacity. Existing nodes are evaluated using status.allocatable, while an unprovisioned machine is represented by capacity annotations on its MachineSet. Platform teams therefore need to size global CPU, memory and node-count ceilings for both the current cluster and every machine that could be added.

Metadata can decide whether scale-up happens

Red Hat’s test confines nine one-CPU pods to an Azure availability zone and a tainted worker pool. To let the scheduler simulation recognize a suitable future node, the MachineSet carries annotations describing its CPU, memory, zone labels and taints.

That detail is operationally important. If the zone label is absent, the autoscaler cannot infer that a new machine would satisfy node affinity and can report that no expansion option exists. Taint metadata has the same role when workloads depend on a matching toleration. The simulated node must resemble the machine that the cloud provider will create.

In the worked example, six pods remain pending after three fit on the existing worker. The autoscaler raises the MachineSet from one to three replicas; two new Azure workers eventually join, allowing all nine pods to run.

A correct decision can still be too slow

The article separates autoscaler reaction time from infrastructure provisioning. In Red Hat’s test, each Azure worker took about seven minutes from the scale-up request to Ready state. Pending workloads wait through that interval even when the policy is functioning correctly.

For burst-sensitive services, the guide describes low-priority pause pods as one way to reserve warm capacity. Production pods preempt the placeholders, which then become pending and trigger replacement capacity. The tradeoff is higher baseline cost, more tuning and a cluster that intentionally keeps otherwise idle nodes online.

Red Hat also points to ProvisioningRequest and the emerging CapacityBuffer API as capacity-ahead-of-demand mechanisms. The former is developer preview in standalone OpenShift under DevPreviewNoUpgrade; availability of the latter depends on the OpenShift autoscaler build.

What platform teams should check

Before relying on Cluster Autoscaler, teams should verify that the Machine API is operational, every elastic MachineSet has explicit replica bounds, pods declare resource requests, cloud quotas cover the configured maximum and disruption budgets permit safe scale-down. They should also test the full path—from an unschedulable pod through machine provisioning—because scheduler logic and cloud boot latency are separate failure and delay domains.