Red Hat uses KEDA to scale OpenShift MachineSets before pods pile up

Red Hat has documented a metrics-driven alternative to the OpenShift Cluster Autoscaler: use the Custom Metrics Autoscaler Operator, Red Hat’s supported KEDA distribution, to scale an individual MachineSet from a Prometheus query.

The engineering walkthrough is aimed at infrastructure teams that want capacity to follow a custom signal before unschedulable pods become the trigger. It includes the operator subscription, RBAC, Prometheus authentication, a KEDA ScaledObject and a tested one-to-three-node scale-up.

How the pattern works

The target is an OpenShift MachineSet, not a pod-owning workload. KEDA queries the in-cluster Thanos endpoint for CPU requests and allocatable CPU on nodes belonging to that MachineSet. The demonstration multiplies utilization percentage by the current node count, then lets the HPA path calculate desired replicas with ceil(metric / threshold).

That workaround matters because metricType: Value expects the scale target to resolve ready pods. A MachineSet has no pods of its own, so the article reports that path failing with “no pods returned by selector.” The example instead uses AverageValue and embeds the replica factor in PromQL.

The required permissions are broader than a normal application autoscaler. The KEDA operator receives permission to read and patch machinesets and machinesets/scale. A separate service account receives monitoring-view access and a bearer token for the Thanos querier.

The operational boundary

Red Hat is explicit about the conflict condition: a MachineAutoscaler must not manage the same MachineSet. Cluster Autoscaler and KEDA should not compete for that target. That makes this a choice of control loop per MachineSet, not an extra autoscaler to layer on without coordination.

The test configures a minimum of one and maximum of three workers, with a 75% threshold and a 30-second polling interval. Nine one-CPU pods fill the nodes in stages. In the observed run, the metric caused the MachineSet to move from one to two replicas, then two to three; all nine pods eventually reached Running across the three workers.

When the approach fits

The pattern is useful when a platform team has an external or custom metric that represents future scheduling pressure better than pending pods do. It also exposes the costs clearly: operators must own the PromQL formula, grant cluster-level scaling access and verify that no other controller owns the same MachineSet.

Red Hat plans a follow-up comparison with the built-in Cluster Autoscaler. Until then, this walkthrough is best read as a reproducible alternative for selected MachineSets, not a blanket replacement for cluster-wide autoscaling.