Support adding HPA Standard Metrics to Scaled Object Spec

[patnaikshekhar]

Allow a user to add standard metrics to the scaled object spec so that the HPA created by KEDA contains those metrics

Use-Case

We need to be able to scale our pods based on queue depth as well as memory metrics. If we use KEDA only to scale based on queue depth and create another HPA to scale the deployment based on standard metrics (memory util) there is a conflict and the system reaches a unstable state.

Specification

• Allow additional metrics to be specified in the Scaled Object spec. Example

apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
  name: azure-servicebus-queue-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    deploymentName: azure-servicebus-queue-function
  triggers:
  - type: azure-servicebus
    metadata:
      # Required: queueName OR topicName and subscriptionName
      queueName: functions-sbqueue
      # or
      topicName: functions-sbtopic
      subscriptionName: sbtopic-sub1
      # Required: connection OR authenticationRef that defines connection
      connection: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # reference to a connection string in deployment
      # or authenticationRef as defined below
      #
      # Optional
      queueLength: "5" # default 5
 additionalMetrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50
    - type: Pods
      pods:
        metric:
          name: packets-per-second
        target:
          type: AverageValue
          averageValue: 1k
    - type: Object
      object:
        metric:
          name: requests-per-second
        describedObject:
          apiVersion: networking.k8s.io/v1beta1
          kind: Ingress
          name: main-route
        target:
          type: Value
          value: 10k
    authenticationRef:
        name: azure-servicebus-auth 

[zroubalik]

Thats' a great idea. We could introduce it in upcoming v2.

My only concern is the proposed specification. I am not sure if the triggers section is the right place for this fields.

[patnaikshekhar]

Thats' a great idea. We could introduce it in upcoming v2.

My only concern is the proposed specification. I am not sure if the triggers section is the right place for this fields.

That is a typo I wanted to say that it should be at the same level as triggers.

[zroubalik]

@patnaikshekhar why did you close this issue?

[patnaikshekhar]

I have no idea how that happened!

[jeffhollan]

Chatted about this in standup. @ckuduvalli mentioned that also a scenario he is interested in. This potentially could be combined with the requirement for #802 but makes sense

[zroubalik]

Fixed by #874