KEDA scales any CustomResource that implements Scale subresource

[zroubalik]

KEDA could scale Deploment, StatefulSet (as requested in #497) or any CustomResource that implemtents /scale subresource (eg. Argo Rollout as requested in #595). This functionality should work out of the box for users, ie. they won't have to perform any changes on their workloads.

To enable this a few changes would be needed:

• modify the RBAC to allow operator to access scale subresource
• implement polymorphic scale client to access scale subresource on any CR
• make the scale logic more general and not bound strictly to Deployment
• change the spec of ScaledObject and create a special CR for Job as it is suggested in Introduce ScaledJob & ScaledObject #653
  Proposed change:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: {scaled-object-name}
spec:
  scaleTargetRef:
    apiVersion:  {apiVersion-of-object-to-scale}   # Optional. Default: apps/v1
    kind:        {kind-of-object-to-scale}.        # Optional. Default: Deployment
    name:        {name-of-object-to-scale}
  pollingInterval: 30  # Optional. Default: 30 seconds
  cooldownPeriod:  300 # Optional. Default: 300 seconds
  minReplicaCount: 0   # Optional. Default: 0
  maxReplicaCount: 100 # Optional. Default: 100
  triggers:
  # {list of triggers to activate the deployment}

There is a change in scaleTargetRef section, if user specifies only name, KEDA would assume that the target is Deployment, if user wants to target any other workload, fields apiVersion and kind need to be specified appropriately.

I am working on POC to check if it is possible to achieve this. There shouldn't be any major changes in the scalers.

Open questions

1. Do we want this functionality?
2. How to handle Secrets or Authentication in general?
   • We could drop support of Secret linked in containers in favor of TriggerAuthentication
   • We could keep support of Secret linked in containers only for Deployment and StatefulSet, it will be needed to specify the containerName property somewhere in the spec. Where? Authentication support for CustomResources would be possible only through TriggerAuthentication as it is hard to detect the correct container in the CR.

@jeffhollan @tomkerkhove @ahmelsayed @anirudhgarg ^

[tomkerkhove]

I think this makes sense but what we should keep in mind is the how things should scale as mentioned in #653 where a Job spins up an instance per message, while deployment/statefulset/deamon adds based on message count; there is no 1-to-1 link.

How would KEDA know the difference for that then exactly?

Or would that be a distinction on this then?

For deployments, deamons, et al

apiVersion: keda.sh/v1alpha1
kind: ScaledWorker # As per OAM's workload types https://github.com/oam-dev/spec/blob/master/schema/component.schema.json#L54

And for jobs/"serverless"

apiVersion: keda.sh/v1alpha1
kind: ScaledTask # As per OAM's workload types https://github.com/oam-dev/spec/blob/master/schema/component.schema.json#L54

Can we incorporate that?

As per secrets, I'm more than happy to drop what we have today and enforce TriggerAuthentication as I think that makes more sense; but it requires you to deploy two things (but don't think that's an issue)

[zroubalik]

@tomkerkhove thanks for the input. My intention is to create a separate resource for Job if we agree on this. As we can handle each type of resource a different way and specify different properties on each resource.

[aslom]

I think it would be amazing functionality in KEDA and very useful for Knative Eventing. Especially as more event sources need scaling made easy to implement.

[zroubalik]

merged into v2 branch