KPA cannot scale gang workloads to zero

[yankay]

/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: 2

https://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?

[webdevsamran]

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 0 or >= 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 in pkg/autoscaler/scaling to properly account for minCount boundaries during scale-down decisions so gang workloads can cleanly scale to zero, and add test cases.

Could you please assign this to me? Thanks!