Use-Case

From the design proposal:

Goal

Allow end-users to subscribe to events emitted by KEDA allowing them to gain insights into what is going on and how their applications are being scaled.

These should serve several purposes such as:

• Allow for autoscaling awareness (scaling)
• Allow for automated notifications for incidents (errors, misconfiguration)
• Allow for extensibility to enable end-users and our community to build on top of KEDA

Events that are being emitted must be CloudEvent-compliant and support pushing to destination endpoints inside/outside of the cluster.

With this proposal, our intention is to extend the event capabilities of KEDA with CloudEvents.

From a high-level perspective, KEDA will be doing three things in this area:

1. Scale workloads across one or more namespaces
2. Provide Kubernetes events inside the cluster that can be used through typical tooling (CLI, UIs, …)
3. Emit events to endpoints inside/outside the cluster that are CloudEvents-compliant

What are we doing

With the introduction of CloudEvents, we are targeting two audiences:

• Cluster operators who are interested to subscribe to events across all namespaces to have a holistic overview of everything going on in the cluster
• App developers who want to subscribe to events of their own application by using. This allows them to reduce the noise of other teams and save compute for filtering them out

With the introduction of EventSource & ClusterEventSource CRD, we cover both scenarios and give end-users the controls that they need. The goal is that they can define an endpoint, authentication, and optional filter to which KEDA will emit its events.

Similar to TriggerAuthentication & ClusterTriggerAuthentication CRDs, the idea is that EventSource is scoped to a single namespace while ClusterEventSource is cluster-wide.

End-users can optionally define event types they want to exclude so that the destination will never receive them.

While the event subscription configuration opens up a lot of opportunities, we should strive to keep the control as minimal as possible so that we don’t implement our own eventing engine.

End-users who need more robust filtering capabilities have to use another tool that is a better fit in this scenario.

Do we need a new CRD?

In order to build a scalable way of emitting events, across various teams and parties it is not an option to configure an endpoint directly on our KEDA control plane, but rather rely on a new CRD.

Otherwise, it would quickly become a bottleneck for end-users that have numerous namespaces and want to have more control over who is allowed to receive what events:

• Cluster admins/operators will want to have events for scaling in all namespaces
• App devs/operators will only be interested in the events for their applications

While every team could do the filtering on their own, this is a waste of compute.

Requirements

Introduce a new (Cluster)EventSource CRD that allows people to subscribe for CloudEvents:

apiVersion: events.keda.sh/v1alpha1
kind: EventSource # Or ClusterEventSource
metadata:
  name: operations-cross-cluster-events
spec:
  destination:
    # Support regular webhook endpoints over HTTP(S)
    http:
      uri: http://foo.bar
      authentication:
        apiKey:
          headerName: x-api-key
          valueFrom:
            secretKeyRef:
            name: secrets-operations-events
            key: webhook-api-key
  eventSubscription:
    includedEventTypes:
      - keda.example.Event
    excludedEventTypes:
      - keda.example.Event

Once these are created by end-users; KEDA will automatically push the events to the configured sink(s).

Issues for events are created separately.

Anything else?

Relates to #479