Skip to content

For the complete documentation index and AI-optimized content, see /llms.txt. All pages support markdown format via .md extension or Accept: text/markdown header.

Scaling Groups

For the complete documentation index and AI-optimized content, see /llms.txt. All pages support markdown format via .md extension or Accept: text/markdown header.

A ScalingGroup is a CRD in Kedify KEDA allowing to set shared max capacity for multiple ScaledObjects belonging to a logical group. Group membership is defined dynamically by a label selector.

This feature must be enabled in the KEDA operator by setting env variable:

KEDIFY_SCALINGGROUPS_ENABLED=true

Any already existing or new ScaledObjects can be added to a ScalingGroup by ensuring matching labels to the group’s selector. The group’s capacity is shared among all members, each ScaledObject is guaranteed to have their minReplicaCount and can scale up to maxReplicaCount unless the group capacity would be exceeded.

Scaling Groups

Only triggers with metrics from external.metrics.k8s.io are supported for ScalingGroups which means cpu and memory scalers are excluded from this functionality.

ScalingGroup members use Kubernetes HPA in the initial Kedify Pod Autoscaler preview. When an existing ScaledObject explicitly selects KPA and begins matching a group selector, the ScalingGroup controller atomically changes autoscaling.kedify.io/class to hpa while assigning membership and emits an AutoscalingClassFallback Warning event. KEDA then replaces the generated KPA with HPA.

Removing the matching label or group does not automatically restore an explicit KPA selection. The ScaledObject remains explicitly configured for HPA so leaving the shared-capacity policy cannot silently change its autoscaling controller. After membership has been removed, select autoscaling.kedify.io/class: kpa again if the workload should return to KPA. A ScaledObject that used KPA only through the installation default is not rewritten; it uses HPA while it is a member and follows the installation default again after it leaves.

Below is a simple ScalingGroup restricting the total capacity to 15 replicas. The group consists of three ScaledObjects with the label scaling-group: pear-db. Status of the group shows members and their scaling status.

apiVersion: keda.kedify.io/v1alpha1
kind: ScalingGroup
metadata:
name: pear-db
spec:
capacity: 15 # max capacity for the whole group
selector: # label selector to match ScaledObjects
matchLabels:
scaling-group: pear-db
status:
memberCount: 3 # how many ScaledObjects belong to the group
residualCapacity: 0 # capacity available to allocate for scale-out
scaledObjects: # scaling status for individual members
pear-store:
hpaDesiredReplicaCount: 7 # how many replicas KEDA allows HPA to scale to
cappedStatus:
replicaCountBasedOnMetrics: 14 # what would be the replica count purely based on the metric
replicaCountCapped: 7 # capped replica count
pear-tunes:
hpaDesiredReplicaCount: 3
cappedStatus:
replicaCountBasedOnMetrics: 9
replicaCountCapped: 3
pear-cloud:
hpaDesiredReplicaCount: 5
cappedStatus:
replicaCountBasedOnMetrics: 6
replicaCountCapped: 5