Sources, Brokers, Triggers, Sinks

Sources, Brokers, Triggers, Sinks, oh my!

For the purposes of this tutorial, let's keep it simple. You will focus on three powerful Eventing components: Source, Trigger and Broker. We'll then bring this all together by using a Knative Service as a Sink for our CloudEvents.

Let's take a look at how these components interact:

Source 1 and Source 2 are transmitting some data (1's and 2's) to the Broker, which then gets filtered by Triggers to the desired Sink.

Component	Basic Definition
Source	A Kubernetes Custom Resource which emits events to the Broker.
Broker	A "hub" for events in your infrastructure; a central location to send events for delivery.
Trigger	Acts as a filter for events entering the broker, can be configured with desired event attributes.
Sink	A destination for events.

A note on Sources and Sinks

A Knative Service can act as both a Source and a Sink for events, and for good reason. You may want to consume events from the Broker and send modified events back to the Broker, as you would in any pipeline use-case.

Examining the Broker

As part of the KonK install, you should have an in-memory Broker already installed.

kn broker list

Expected Output

NAME             URL                                                                          AGE   CONDITIONS   READY   REASON
example-broker   http://broker-ingress.knative-eventing.svc.cluster.local/default/default     5m    5 OK / 5     True    

Warning

In-Memory Brokers are for development use only and must not be used in a production deployment.

What other components exist in Knative Eventing?

If you want to find out more about the different components of Knative Eventing, like Channels, Sequences, Parallels, etc. check out "Eventing Components."