Broker and Trigger

Broker and Trigger are CRDs providing an event delivery mechanism that hides the details of event routing from the event producer and event consumer.

Broker

A Broker represents an ‘event mesh’. Events are sent to the Broker’s ingress and are then sent to any subscribers that are interested in that event. Once inside a Broker, all metadata other than the CloudEvent is stripped away (e.g. unless set as a CloudEvent attribute, there is no concept of how this event entered the Broker).

There can be different classes of Brokers providing different kinds of semantics around durability of events, performance, etc. The Broker that is part of the Knative Eventing repo is used for these examples, it uses Knative Channels for delivering events. You can read more details about MT Channel Based Broker. Simple example showing a Broker where the configuration is specified in a ConfigMap config-br-default-channel, which uses InMemoryChannel:

Example:

  1. apiVersion: eventing.knative.dev/v1beta1
  2. kind: Broker
  3. metadata:
  4.   name: default
  5. spec:
  6.   # Configuration specific to this broker.
  7.   config:
  8.     apiVersion: v1
  9.     kind: ConfigMap
  10.     name: config-br-default-channel
  11.     namespace: knative-eventing

More complex example, showing the same Broker as above but with failed events being delivered to Knative Service called dlq-service

  1. apiVersion: eventing.knative.dev/v1beta1
  2. kind: Broker
  3. metadata:
  4.   name: default
  5. spec:
  6.   # Configuration specific to this broker.
  7.   config:
  8.     apiVersion: v1
  9.     kind: ConfigMap
  10.     name: config-br-default-channel
  11.     namespace: knative-eventing
  12.   # Where to deliver Events that failed to be processed.
  13.   delivery:
  14.     deadLetterSink:
  15.       ref:
  16.         apiVersion: serving.knative.dev/v1
  17.         kind: Service
  18.         name: dlq-service

Trigger

A Trigger represents a desire to subscribe to events from a specific Broker.

Simple example which will receive all the events from the given (default) broker and deliver them to Knative Serving service my-service:

  1. apiVersion: eventing.knative.dev/v1beta1
  2. kind: Trigger
  3. metadata:
  4.   name: my-service-trigger
  5. spec:
  6.   broker: default
  7.   subscriber:
  8.     ref:
  9.       apiVersion: serving.knative.dev/v1
  10.       kind: Service
  11.       name: my-service

Trigger Filtering

Exact match filtering on any number of CloudEvents attributes as well as extensions are supported. If your filter sets multiple attributes, an event must have all of the attributes for the Trigger to filter it. Note that we only support exact matching on string values.

Example:

  1. apiVersion: eventing.knative.dev/v1beta1
  2. kind: Trigger
  3. metadata:
  4.   name: my-service-trigger
  5. spec:
  6.   broker: default
  7.   filter:
  8.     attributes:
  9.       type: dev.knative.foo.bar
  10.       myextension: my-extension-value
  11.   subscriber:
  12.     ref:
  13.       apiVersion: serving.knative.dev/v1
  14.       kind: Service
  15.       name: my-service

The example above filters events from the default Broker that are of type dev.knative.foo.bar AND have the extension myextension with the value my-extension-value.

Complete end-to-end example

Broker setup

We assume that you have installed a Broker in namespace default. If you haven’t done that yet, install it from here.

Subscriber

Create a function to receive events. This document uses a Knative Service, but it could be anything that is Callable.

  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4.   name: my-service
  5.   namespace: default
  6. spec:
  7.   template:
  8.     spec:
  9.       containers:
  10.       -  # This corresponds to
  11.          # https://github.com/knative/eventing-contrib/tree/master/cmd/event_display
  12.          image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:a214514d6ba674d7393ec8448dd272472b2956207acb3f83152d3071f0ab1911

Trigger

Create a Trigger that sends only events of a particular type to the subscriber created above (my-service). For this example, we use Ping Source, and it emits events types dev.knative.sources.ping.

  1. apiVersion: eventing.knative.dev/v1beta1
  2. kind: Trigger
  3. metadata:
  4.   name: my-service-trigger
  5.   namespace: default
  6. spec:
  7.   filter:
  8.     attributes:
  9.       type: dev.knative.sources.ping
  10.   subscriber:
  11.     ref:
  12.       apiVersion: serving.knative.dev/v1
  13.       kind: Service
  14.       name: my-service

Defaulting

The Webhook will default the spec.broker field to default, if left unspecified.

The Webhook will default the YAML above to:

  1. apiVersion: eventing.knative.dev/v1beta1
  2. kind: Trigger
  3. metadata:
  4.   name: my-service-trigger
  5.   namespace: default
  6. spec:
  7.   broker: default # Defaulted by the Webhook.
  8.   filter:
  9.     attributes:
  10.       type: dev.knative.sources.ping
  11.   subscriber:
  12.     ref:
  13.       apiVersion: serving.knative.dev/v1
  14.       kind: Service
  15.       name: my-service

You can make multiple Triggers on the same Broker corresponding to different types, sources (or any other CloudEvents attribute), and subscribers.

Emitting Events using Ping Source

Knative Eventing comes with a Ping Source which emits an event on a configured schedule. For this we’ll configure it to emit events once a minute, saying, yes, you guessed it Hello World!.

  1. apiVersion: sources.knative.dev/v1alpha2
  2. kind: PingSource
  3. metadata:
  4.   name: test-ping-source
  5. spec:
  6.   schedule: "*/1 * * * *"
  7.   jsonData: '{"message": "Hello world!"}'
  8.   sink:
  9.     ref:
  10.       # Deliver events to Broker.
  11.       apiVersion: eventing.knative.dev/v1alpha1
  12.       kind: Broker
  13.       name: default

Table of contents