Repository navigation
KPA cannot scale gang workloads to zero #16684
Description
/area autoscale
/kind bug
What version of Knative?
v1.23.0
Expected Behavior
KPA should support gang workloads whose valid replica states are:
replicas == 0, or replicas >= minCount
Actual Behavior
KPA gradually scales 2 -> 1 -> 0. With the default
MaxScaleDownRate=2:
Ready=2, metricDesired=0
desired=floor(2/2)=1
A gang workload with minCount=2 cannot realize one replica, so it remains at
two. KPA continues observing two Ready Pods and repeatedly requests one,
preventing scale-to-zero:
KPA requests 1 -> target remains at 2 -> repeat
Pods remain stable, but KPA desired remains 1, actual remains 2, and a
persistent write loop occurs. A control allowing one replica successfully
converges through 2 -> 1 -> 0.
Related behavior is discussed in #14017 and #15154.
KEDA avoids this using separate idle and active floors:
idleReplicaCount: 0
minReplicaCount: 2https://keda.sh/docs/2.20/reference/scaledobject-spec/#idlereplicacount
This matters for gang-aware workload controllers, for example
ai-dynamo/grove#686, and Kubernetes Workload/PodGroup APIs in KEP-4671:
ai-dynamo/grove#686
https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/4671-gang-scheduling
Could KPA support a similar separation between idle and active floors?
Activity
webdevsamran commentedon Sep 6, 2026
Hi team, I would like to work on this issue.
When KPA calculates desired scale-down for gang-scheduled workloads where valid replica states are
0or>= minCount, gradual step-down (e.g. 2 -> 1 with default MaxScaleDownRate) creates a deadlock where 1 replica cannot be realized, preventing scale-to-zero. I can look into KPA's scaling calculation inpkg/autoscaler/scalingto properly account forminCountboundaries during scale-down decisions so gang workloads can cleanly scale to zero, and add test cases.Could you please assign this to me? Thanks!