Support KEDA as scaling solution

[xogoodnow]

Hi,
For scaling, it would be very useful if the operator would create a KEDA ScaleObject per versioned replicaSet.
When an old version is draining -> operator can simply disable the respective ScaleObject (unlike HPA it can scale to 0).

IMHO these are the top benefits:

1. This would solve the migration issue when switching to Knative.
2. Very flexible for scaling signals kafka lag, invocation latency (any metric really)
3. No need to have the Knative networking constraints (port naming, activator and ...)

[joebowbeer]

Will KEDA support be useful by itself?

Knative's revision based traffic routing is leveraged by RestateOperator in several ways.

For example, when you tag a revision, Knative generates a separate, unique URL derived from the tag. The endpoint follows the standard format: https://<tag>-<service-name>.<namespace>.<domain>

https://knative.dev/docs/serving/revisions/

Also, isn't KEDA extended by adding support to it?

For example, KEDA has a scaler for Temporal

https://keda.sh/docs/2.19/scalers/

What does RestateOperator need to provide in order for KEDA to support it?

[xogoodnow]

IMHO it could be useful if the operator would:

1. for each versioned RS, the operator creates a ScaledObject.
2. when a version enters draining, set minReplicaCount: 0 (or autoscaling.keda.sh/paused: "true") so the RS drops to 0 as soon as in flight invocations finish.
3. delete the ScaledObject with the RS.

[lukebond]

just wanted to acknowledge the issue but say that i haven't got around to being able to focus on it yet. thanks for raising it!