Skip to content

Instantly share code, notes, and snippets.

What would you like to do?

Event Mesh based on Knative Eventing

In Knative the Broker API is a custom Kubernetes API defining an event mesh for CloudEvents.

Creating a Knative Broker

The Broker APIs can be used as a declarative way to create broker objects, like:

kind: Broker
  namespace: my-namespace
  name: my-broker

Creating the above broker object results in an endpoint (http://broker-ingress.knative-eventing.svc.cluster.local/my-namespace/my-broker in this case), which can be used for 3rd party event producers to deliver CloudEvents to it.

NOTE: There is different Broker implementations available, like the Knative Kafka Broker.

Event Routing based on metadata

The Knative Trigger API allows developers to route (or filter) events by standardized CloudEvent metadata, so that matching events get delivered to specified subscriber applications, such as:

kind: Trigger
  name: my-trigger
  broker: my-broker
      type: my.demo.event
      kind: Service
      name: broker-display

The my-trigger is registered on the my-broker broker object and sends all CloudEvents with the matching type attribute (my.demo.event) to the referenced subscriber.

An event enters a Broker. The Broker uses Triggers to forward the event to the appropriate Subscriber.

If the referenced application sends back a HTTP response with a CloudEvent, the returned event is also feed back into the broker for further event processing.

NOTE: There is work in place to also support the CNCF Subscription API for advanced filtering, as discussed here.

Custom Code for Event Processing

The broker-display, referenced above, is some custom code that can be used for different types of Event Processing. Below is a very simple application that just prints the received event to the server log:

kind: Service
  name: broker-display
      - image:

NOTE: For more advanced user-cases it is recommended using the functions API from Knative itself, which is discussed here.

Sending an Event

Any existing application can be integrated with the above URL for the Event Mesh for delivering their own CloudEvents to Knative Eventing. For demo reasons the most minimal integration for a 3rd party event-producer is a curl container, that sends a simple CloudEvent like:

kubectl -n my-namespace run curl \
    --image=curlimages/curl --rm=true --restart=Never -ti -- \
    -X POST -v \
    -H "content-type: application/json"  \
    -H "ce-specversion: 1.0"  \
    -H "ce-source: my/curl/command"  \
    -H "ce-type: my.demo.event"  \
    -H "ce-id: 0815"  \
    -d '{"name":"Matthias"}' \

The output will be received by the broker-display application, and is printed to the console in our case, like:

☁️  cloudevents.Event
Validation: valid
Context Attributes,
  specversion: 1.0
  type: my.demo.event
  source: my/curl/command
  id: 0815
  datacontenttype: application/json
  knativearrivaltime: 2021-10-05T12:40:28.411841462Z
    "name": "Matthias"

Have fun!

Copy link

rhuss commented Oct 11, 2021

Sounds good, but shouldn't you create the service first before connecting with a trigger to the broker ?

FWIW, the following sequence of kn commands is equivalent to the demo above:

# Create broker
kn broker create my-broker

# Creaet a KService for displaying events.
kn service create broker-display --image

# Create trigger to connect broker with service
kn trigger create my-trigger --broker my-broker --sink broker-display

# Use `kn-plugin-event` for sending events, syntax is a bit in flux. Can also send from within the cluster like
# In you example
kn event send --type my.demo.event --field name=Matthias --to

Copy link

matzew commented Oct 11, 2021

Sounds good, but shouldn't you create the service first before connecting with a trigger to the broker ?

yes, that is right. Might write differently - but will keep the yaml, since that displays the components better, IMO

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment