Implement duck-typing for ScaledObject

[jeffhollan]

There is a pattern to have CRDs utilize "duck-typing" so that they can flexibly support other types that it may not even know about. I'm not an expert on this :) - but I believe this could help make our ScaledObject a bit nicer between the 3 kinds: Scale Deployment, Scale Jobs, Scale StatefulSet.

We could implement this pattern for a future release

[jeffhollan]

@zroubalik not sure if this is something you were interested to lead out?

[zroubalik]

@jeffhollan yes, happy to do so :) assigning to myself

[tomkerkhove]

Can we add a link to the concept for the folks who are not aware?

Might help understands what's coming!

[zroubalik]

@tomkerkhove absolutely, I will add some details to the description later on

[anirudhgarg]

Here is a KubeCon talk I found about this: https://www.youtube.com/watch?reload=9&v=kldVg63Utuw

[n3wscott]

You can ask me questions if you have them.

[mattmoor]

Me too 🍿

[zroubalik]

@mattmoor @n3wscott thanks, definitely will do that 😄

[zroubalik]

If we want to add a KEDA duck type, in particular it will mean, that we define a shape of a on object (the properties needed by KEDA, basically these ones which are currently in ScaledObject). Users can then incorporate these properties (and a label) into their CustomResource (which is completely unknown to KEDA) and KEDA controller can scale this CR based on a specification in this object and won't need ScaledObject. The CR and the properites need to conform the duck type shape of course.

For example we have a CustomResource named MyCustomResource and we would like to scale it by KEDA. We will need to:

1. add fields into the Status needed by the KEDA to conform the KEDA duck type
2. add some label, so KEDA could discover this object and scale it, eg. duck.keda.sh/scalable=true

the CR extended by properties needed for KEDA could look like this:
(please note that this is just an example to describe the idea, the specific duck-type and it's properties could be different)

apiVersion: foo.bar/v1alpha1
kind: MyCustomResource
metadata:
  name: ResourceScaledByKeda
  labels:
    myLabel: value                  # labels specified on the CR
    ...
    duck.keda.sh/scalable: true     # KEDA could discover CRs by a label
spec:
  specField1: value1  # spec field that is originally specified by this particular CR
  specField2: value2  # spec field that is originally specified by this particular CR
  ...
status:
  myCustomResourceStatusField1: value   #  status field that is originally specified by this particular CR
  myCustomResourceStatusField2: value   #  status field that is originally specified by this particular CR
  ...
  kedaSpec:              # values needed by KEDA, originally in scaledObject.spec
    pollingInterval: 30  
    cooldownPeriod:  300 
    minReplicaCount: 0   
    maxReplicaCount: 10
    triggers:
       ...  # triggers section
  kedaStatus:             # values needed by KEDA, originally in scaledObject.status
    lastActiveTime: value
    externalMetricNames: values
  ...

Concerns

1. Currently KEDA controller is updating status on the ScaledObject to store values needed for scaling (see the kedaStatus section above). If we use ducktype defined above, it will result in collisions between KEDA controller and the Controller which handles the original CustomResource as both will update the same resource. We will need to find another way how to store these values.
2. There is a lot of properties needed by KEDA. Currently they are stored in a ScaledObject, if we include triggers section it could be ~15-20 lines, see example on this page in the bottom. It could be hard to maintain such a huge yaml file within one CR, a separate ScaledObject is better for most usecases from my POV.
3. It would be non-trivial to reimplement KEDA core to support this feature.

Proposal
To support scaling other types of worlkoads, it shouldn't be neccessary to create a special KEDA duck type, we could use approach proposed in #703 and add support of some duck type later if there are requests from the community.

@n3wscott @mattmoor please correct me, if I am wrong in my assumptions

@tomkerkhove @jeffhollan @ahmelsayed @anirudhgarg PTAL

[mattmoor]

You don't want to stuff things into another resource's schema. You can define a KEDA CRD with the spec/status you want and associate it (OwnerRefs) with that resource.

In this world, the original resource acts as the source-of-truth for the original partial schema to seed KEDA's state, and this is projected into a new concrete child resource that codifies KEDA's state.

I believe (@n3wscott correct me) this is somewhat similar to how Knative Channels work. There is both a concrete Channel and domain-specific variants KafkaChannel.

[zroubalik]

We have decided to go with the direction on generic scaling based on /scale subresource. We are using some duck types internally.

Closing this for now. We can reopen if there's a demand in the future.