Provide support for multiple triggers

[tomkerkhove]

Provide support for multiple triggers that act as an AND.

Use-Case

Queue processing that persists orders in the database.

As of today, we can autoscale based on message count but if our DB DTU is at 99% capacity we'll only make it worse.

Specification

apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
  name: {scaled-object-name}
  labels:
    deploymentName: my-queue-worker
spec:
  scaleTargetRef:
    deploymentName: my-queue-worker
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: functions-sbqueue
      queueLength: "5" # Optional. Subscription length target for HPA. Default: 5 messages
  - type: azure-monitor # Requested here: https://github.com/kedacore/keda/issues/155
    metadata:
      resourceUri: <uri>

Kudos to @jornbeyers for idea

[tomkerkhove]

Thoughts @jeffhollan?

[zroubalik]

Interesting. How would this exactly calculate the final replicas count? Sum across all triggers? Or what is the idea on the scaling logic here?

[tomkerkhove]

I would say that we just scale out if both criteria has met.

As far as I know we just add one instance every time based on the metric but you're more thinking in terms of the HPA underneath it or?

[zroubalik]

Yeah, but it is interesting scenario for sure. We should look into this.

[fktkrt]

Interesting. How would this exactly calculate the final replicas count? Sum across all triggers? Or what is the idea on the scaling logic here?

The HorizontalPodAutoscaler calculates a value for each metric, then chooses the highest replica count. Should that be modified?

[alegmal]

Hi, is there any update on where this feature stands?
Our use case is a service that consumes multiple queues

[marchmallow]

We have a similar use case as we watch multiple Redis lists from same deployment.. it would be nice if I could also specify a single trigger with a regex on the queue name, and get the scaler to watch all matching queues then allow also scale on total sum of elements across all queues.

@inuyasha82 FYI

[inuyasha82]

I think the change is not hard to implement, i have an idea even where to put it, i can probably work on it in the next weeks.

[tomkerkhove]

This will be finalized with #733, right @zroubalik ?

[zroubalik]

@tomkerkhove yes!

[zroubalik]

Solved in #966

[tomkerkhove]

Just verifying - This is only for ScaledObject I presume?

[zroubalik]

I think it should work for ScaledJob as well.

@TsuyoshiUshio could you please confirm?

[alegmal]

Hi,

Could you please provide an example for multiple triggers for rabbitmq?

I have deleted KEDA 1.5 and deployed KEDA 2.0.0-rc2 in our dev cluster.

If I create following yaml (single trigger), everything works:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: <deployment-name>
  namespace: default
spec:
  scaleTargetRef:
    name: <deployment-name>
  pollingInterval: 2
  cooldownPeriod: 60
  minReplicaCount: 1
  maxReplicaCount: 100
  triggers:
  - type: rabbitmq
    metadata:
      hostFromEnv: MQ_INFO
      protocol: amqp
      queueLength: '30'
      queueName: <queue name>

If I add triggers it breaks (I need 5 but even 2 breaks it):

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: <deployment-name>
  namespace: default
spec:
  scaleTargetRef:
    name: <deployment-name>
  pollingInterval: 2
  cooldownPeriod: 60
  minReplicaCount: 1
  maxReplicaCount: 100
  triggers:
  - type: rabbitmq
    metadata:
      hostFromEnv: MQ_INFO
      protocol: amqp
      queueLength: '30'
      queueName: <queue # 1>
  - type: rabbitmq
    metadata:
      hostFromEnv: MQ_INFO
      protocol: amqp
      queueLength: '30'
      queueName:  <queue # 2>

Also, in the documentation:
https://keda.sh/docs/2.0/scalers/rabbitmq-queue/

It shows apiVersion: keda.k8s.io/v1alpha1 but I believe its a mistake so I used keda.sh/v1alpha1

[zroubalik]

@alegmal and what problem are you exactly facing?

[alegmal]

Figured it out.

Apparently scaledobjects.keda.k8s.io was not really deleted and it did not let me delete it.
Workaround that worked was:
kubectl patch crd/scaledobjects.keda.k8s.io -p '{"metadata":{"finalizers":[]}}' --type=merge

After running that command it instantly deleted crd/scaledobjects.keda.k8s.io and now everything seems to work!

[zroubalik]

@alegmal glad to hear that :) Yeah it is important to delete the old CRDs first (https://keda.sh/docs/2.0/migration/#migrating-from-keda-v1-to-v2)