Knative_Event_Mesh.md

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:

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  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:

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: my-trigger
spec:
  broker: my-broker
  filter:
    attributes:
      type: my.demo.event
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      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.

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:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: broker-display
spec:
  template:
    spec:
      containers:
      - image: quay.io/openshift-knative/knative-eventing-sources-event-display

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"}' \
    http://broker-ingress.knative-eventing.svc.cluster.local/default/my-broker

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
Extensions,
  knativearrivaltime: 2021-10-05T12:40:28.411841462Z
Data,
  {
    "name": "Matthias"
  }

Have fun!

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