Skip to content

Interface to easily install and manage external scalers #5117

Open
@zroubalik

Description

@zroubalik

Proposal

When users want to use external scalers in KEDA, they usually need to provide connection information in the trigger metadata:

- type: external
  metadata:
    scalerAddress: external-scaler-service:8080
    caCert : /path/to/tls/ca.pem
    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549
    tlsClientCert: /path/to/tls/cert.pem
    tlsClientKey: /path/to/tls/key.pem
    unsafeSsl: false
    // ACTUAL TRIGGER CONFIG STARTS HERE
    activationThreshold: 10
    threshold: 20
    fooConfig: true
    barConfig: false
    ...

Let's provide an interface (CRD?), where administrators can install external scalers to KEDA on a cluster level including authenticationRef. This external scalers will define a name (that is unique and don't collide with built-in scalers).
Users can then just easily reference this external scaler as a built in one and provide only needed config (and don't need to specify external scaler connection settings).

Example

For example, let's see an example of external trigger my-awesome-scaler:

  1. Let's define this CRD once (created in keda namespace)
apiVersion: scalers.keda.sh/v1alpha1
kind: ExternalScalerRegistration
metadata:
  name: my-awesome-scaler
spec:
 metadata:
    scalerAddress: external-scaler-service:8080
    caCert: /path/to/tls/ca.pem
    tlsCertFile: /path/to/tls/cert.pem  # Note: This field is deprecated. 
    tlsClientCert: /path/to/tls/cert.pem
    tlsClientKey: /path/to/tls/key.pem
    unsafeSsl: false
  authenticationRef:
    my-ta
  1. users then can reference this trigger like this in their SO/SJ:
- type: my-awesome-scaler
  metadata:
    activationThreshold: 10
    threshold: 20
    fooConfig: true
    barConfig: false
    ...

Things to consider

  • Should we allow arbitrary names for scalers (but check that they don't collide with built-in)? - it would be nice to not pust any restrictions. But what would happen if a user creates and registers external scaler foo in KEDA v 2.X but KEDA v 2.X+1 introduces a new built in scaler called foo?
  • AuthenticationRef should be included in the scaler registration

Use-Case

Simplified management of external scalers

Is this a feature you are interested in implementing yourself?

Maybe

Metadata

Metadata

Assignees

Labels

featureAll issues for new features that have been committed toneeds-discussion

Type

No type

Projects

  • Status

    To Do

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions