Red Hat OpenShift autoscaling using MachineSet autoscaler with KEDA

Summary

The demonstration compares OpenShift MachineSet Autoscaler with KEDA against the previously used Cluster Autoscaler, using metrics to scale a MachineSet before pods remain pending. After installing Red Hat’s Custom Metrics Autoscaler operator (KEDA 2.19), granting permissions for MachineSet scaling and Thanos/Prometheus access, it creates a ScaledObject with a Prometheus trigger targeting demo-p4p95-worker-eastus3. Because a MachineSet has no pods, the HPA path cannot use metricType: Value, so AverageValue is paired with a PromQL query that multiplies CPU request utilization by the current node count. With nine one-CPU test pods, the MachineSet scaled from one to two to three nodes as the metric crossed 75%, and all pods reached Running; two additional Standard_D4s_v3 VMs were provisioned in zone 3.

Context

OpenShift compute infrastructure has multiple scaling options. This demonstration presents MachineSet Autoscaler with KEDA as a metrics-driven alternative to Cluster Autoscaler and uses the same eastus3 target and workload to enable direct comparison. It also addresses the limitation of scaling a non-pod target through the HPA external-metrics path.

Approach / What changed

Install the Custom Metrics Autoscaler operator, grant KEDA permission to update MachineSets and read Thanos/Prometheus, configure bearer-token authentication, and create a Prometheus-triggered ScaledObject for demo-p4p95-worker-eastus3. The PromQL query uses CPU requests and allocatable CPU, multiplies utilization by the current node count, and scales from one to three replicas with AverageValue. The MachineSet must not also have a MachineAutoscaler.

Takeaways

• KEDA uses metricType: AverageValue for the MachineSet because metricType: Value causes the HPA controller to fail when it cannot find ready pods for the target.
• The PromQL metric is CPU request utilization multiplied by the current node count, allowing ceil(metric / 75) to add one MachineSet replica as each set of nodes exceeds 75% utilization.
• The tested MachineSet scaled from 1 to 2 to 3 nodes, while nine one-CPU pods moved from pending to Running; two additional Standard_D4s_v3 VMs were provisioned in zone 3.

Related reading