Topic

KEDA

2 posts about KEDA. Every summary links to the original.

Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.

Newest first

Posts

Red Hat
Comparison of Cluster Autoscaler and KEDA MachineSet Autoscaling on Red Hat OpenShift
This article compares two autoscaling approaches for Red Hat OpenShift compute infrastructure: the built-in Cluster Autoscaler and the KEDA-driven MachineSet Autoscaler. The key difference is the trigger mechanism: Cluster Autoscaler reacts to Pending pods, while KEDA scales based on external metrics like PromQL queries. KEDA triggers faster, scaling within about 15 minutes versus 24 minutes for Cluster Autoscaler, because it acts on metric thresholds before pods become unschedulable. Cluster Autoscaler offers built-in scale-down safety and zero configuration, while KEDA provides fine-grained, metric-driven control but requires the Custom Metrics Autoscaler operator. The choice depends on workload predictability, with Cluster Autoscaler suited for general-purpose workloads and KEDA for dedicated pools with predictable metric patterns. The two autoscalers cannot coexist on the same MachineSet, as they would fight over replica counts.

Red Hat
Red Hat OpenShift autoscaling using MachineSet autoscaler with KEDA
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.

The best engineering reads, once a week.

Topic

2 posts about KEDA. Every summary links to the original.

Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.

Newest first

Red Hat
Comparison of Cluster Autoscaler and KEDA MachineSet Autoscaling on Red Hat OpenShift
This article compares two autoscaling approaches for Red Hat OpenShift compute infrastructure: the built-in Cluster Autoscaler and the KEDA-driven MachineSet Autoscaler. The key difference is the trigger mechanism: Cluster Autoscaler reacts to Pending pods, while KEDA scales based on external metrics like PromQL queries. KEDA triggers faster, scaling within about 15 minutes versus 24 minutes for Cluster Autoscaler, because it acts on metric thresholds before pods become unschedulable. Cluster Autoscaler offers built-in scale-down safety and zero configuration, while KEDA provides fine-grained, metric-driven control but requires the Custom Metrics Autoscaler operator. The choice depends on workload predictability, with Cluster Autoscaler suited for general-purpose workloads and KEDA for dedicated pools with predictable metric patterns. The two autoscalers cannot coexist on the same MachineSet, as they would fight over replica counts.

Red Hat
Red Hat OpenShift autoscaling using MachineSet autoscaler with KEDA
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.

The best engineering reads, once a week.