Red Hat OpenShift autoscaling with Cluster Autoscaler

Summary

Red Hat OpenShift supports compute scaling using Cluster Autoscaler integrated with the OpenShift machine API. The mechanism relies on paired ClusterAutoscaler and MachineAutoscaler custom resources to manage cluster-wide limits and per-MachineSet replica boundaries. Scaling decisions evaluate pending pods against node allocatable capacity and hypothetical node capacity annotations while respecting expander strategies like Random, LeastWaste, or Priority. Cluster Autoscaler checks for unnecessary nodes every 10 seconds, scaling down when utilization falls below configured thresholds and workloads can safely migrate. To mitigate provisioning delays, clusters can adopt overprovisioning via low-priority pause containers or use APIs like ProvisioningRequest and CapacityBuffer for predictive scaling.

Context

Workload demands on Red Hat OpenShift require dynamic infrastructure adjustments, but the built-in Cluster Autoscaler operates solely on scheduling constraints rather than external or queue-based metrics.

Approach / What changed

Deploying paired ClusterAutoscaler and MachineAutoscaler custom resources configures cluster-wide constraints and per-MachineSet bounds, while overprovisioning with pause pods or APIs like ProvisioningRequest proactively reserves capacity.

Takeaways

• Cluster Autoscaler requires both ClusterAutoscaler and MachineAutoscaler custom resources; deploying the former alone will not scale the cluster.
• Scale-down checks run every 10 seconds and target nodes with utilization below the threshold, excluding nodes hosting local storage, non-controller pods, or restrictive PodDisruptionBudgets.
• Overprovisioning reduces pending pod delays by deploying low-priority pause containers (value -10) that production workloads displace via PriorityClass preemption.

Related reading

• Grab · Oct 13, 2020

  Optimally Scaling Kafka Consumer Applications

  Grab's Coban platform runs Golang-based stream processing pipelines on Kubernetes, servicing roughly 400 billion events weekly from Kafka. The initial Horizontal Pod Autoscaler setup caused resource waste and uneven load distribution across Kafka partitions during scale-in and scale-out events. To resolve this, Grab moved to a fixed pod count matching the topic's partition count and adopted Vertical Pod Autoscaling, reducing resource usage versus requests by approximately 45%. The team also introduced Kubernetes priority classes to segment latency-sensitive workloads onto On-Demand nodes and non-critical jobs onto Spot instances. Additionally, overprovisioning via low-priority placeholder pods managed by Cluster Proportional Autoscaler enabled rapid pod rescheduling and reduced deployment delays.

  Shubham Badkur

• Red Hat · Aug 24, 2026

  Run LoRA fine-tuning on Red Hat OpenShift AI with Ray