In Knative the Broker
API is a custom Kubernetes API defining an event mesh for CloudEvents.
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.
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.
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.
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!
yes, that is right. Might write differently - but will keep the yaml, since that displays the components better, IMO