Keda: Provide CPU/Memory scaler

[tomkerkhove]

Provide CPU/Memory scaler which acts as an abstraction on top of HPA functionality.

Today, you can already scale on CPU/Memory (docs) through horizontalPodAutoscalerConfig.resourceMetrics but it requires you to at least have one trigger defined.

This is not ideal given KEDA users should be able to fully rely on KEDA for autoscaling, and not have the need to add HPAs as well. If we have dedicated scalers for these (who don't go through metrics server) they have a consistent experience without knowing the Kubernetes internals and only use ScaledObjects.

Do you need this as well? Don't hesitate to give a :+1:

💡 We know this is perfectly possible today, but we want to give a streamlined experience for those who are not a Kubernetes (expert)

[silenceper]

Does this mean that metrics servier is no longer needed?

[tomkerkhove]

Yes, it's jsut an abstraction on top of the HPA; but as a user I don't have to care about that as KEDA handles that for me.

[silenceper]

I am interested in completing this feature.

I think there are two ways to achieve this:

1. Set the triggers field as an optional field, and use the settings in horizontalPodAutoscalerConfig to generate hpa objects.
2. Add a new scaler, which means cpu/memory built-in resources. Thus replacing horizontalPodAutoscalerConfig.resourceMetrics(abandon this field)

@tomconte @zroubalik Which way is more appropriate?

I tend to use the second method, to provide a new scaler for cpu/memory to instead of horizontalPodAutoscalerConfig.resourceMetrics field

[tomkerkhove]

Our idea is to use a scaler definition which defines the CPU/Memory needs and just use that for horizontalPodAutoscalerConfig.

Reasoning for that is:

1. We shouldn't reinvent the wheel and just use HPA
2. Provide a trigger for user experience
3. We enforce at least one trigger (which makes sense)

But I can see the confusion if the setting is still there. However, if we remove it then we should have it for 2.0. Thoughts @zroubalik ?

[silenceper]

My idea is to add the following configuration, using resourceMetrics as a new trigger：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    name: my-deployment
  advanced:                                          # Optional. Section to specify advanced options
    restoreToOriginalReplicaCount: true/false        # Optional. Default: false
    horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options
      behavior:                                      # Optional. Use to modify HPA's scaling behavior
        scaleDown:
          stabilizationWindowSeconds: 300
          policies:
          - type: Percent
            value: 100
            periodSeconds: 15
  triggers:
  - type: resource                           # provider cpu/memory scaler
    metadata:
      name: cpu/memory
      type: value/ utilization/ averagevalue
      value: 60                                  # Optional
      averageValue: 40                           # Optional
      averageUtilization: 50                     # Optional

Of course, the wheel will not be repeated. The resource scaler is only responsible for generating an hpa resource object (in implementation, this scaler may need to be specially processed, instead of generating a type:External hpa object like other scalers)

[tomkerkhove]

I personnaly would intro cpu & memory instead of resource which is less user friendly

[silenceper]

like this :

...
  triggers:
  - type: cpu/memory                          # provider cpu/memory scaler
    metadata:
      type: value/ utilization/ averagevalue
      value: 60                                  # Optional
      averageValue: 40                           # Optional
      averageUtilization: 50                     # Optional

if this design is ok, I plan to implement it.

PTAL @tomconte @zroubalik

[tomkerkhove]

What if it's just this:

  triggers:
  - type: cpu/memory                          # provider cpu/memory scaler
    metadata:
      type: value/utilization/averagevalue # or 'aggregation'
      value: 60

[silenceper]

yes, this will be more user-friendly.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    name: my-deployment
  advanced:                                          # Optional. Section to specify advanced options
    restoreToOriginalReplicaCount: true/false        # Optional. Default: false
    horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options
      behavior:                                      # Optional. Use to modify HPA's scaling behavior
        scaleDown:
          stabilizationWindowSeconds: 300
          policies:
          - type: Percent
            value: 100
            periodSeconds: 15
  triggers:
  - type: cpu/memory                           # provider cpu/memory scaler
    metadata:
      type: value/ utilization/ averagevalue
      value: 60                                  

Any other suggestions?

[tomkerkhove]

LGTM, thanks!

[silenceper]

@tomkerkhove

In addition, this scaler is not applicable to ScaledJob.

If you want to support it, it will be more complicated, and the logic will be repeated with the hpa part, resulting in duplicate wheels.

[silenceper]

/assign me