Knative: Operator’s Handbook

CloudEvents

Knative Eventing uses CloudEvents as its eventing format. CloudEvents defines a small set of common metadata attributes that most eventing systems already use and tries to standardize on them without actually trying to enforce them.

For example, let’s imagine you want to send this message to Broker:

$ curl -v "http://default-broker.default.svc.cluster.local" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"msg":"Hello Knative!"}'

It’s not going to work because the Broker expects a CloudEvent with certain required headers. Here’s the same event with the required CloudEvents headers:

$ curl -v "http://default-broker.default.svc.cluster.local" \
  -X POST \
  -H "Ce-Specversion: 1.0" \
  -H "Ce-Type: dev.knative.samples.helloworld" \
  -H "Ce-Source: dev.knative.samples/helloworldsource" \
  -H "Ce-Id: 536808d3-88be-4077-9d7a-a3f162705f79" \
  -H "Content-Type: application/json" \
  -d '{"msg":"Hello Knative!"}'

Now, the event can be processed by the Broker. The required attributes are:

Binary vs Structured

The above example uses a Binary format for a CloudEvent where attributes are HTTP headers. There is also a Structured format where attributes are part of the JSON in the HTTP body. The same event can be sent in Structured format as follows:

$ curl -v "http://default-broker.default.svc.cluster.local" \
  -X POST \
  -H "Content-Type: application/cloudevents+json" \
  -d '{"specversion":"1.0","type":"dev.knative.samples.helloworld","source":"dev.knative.samples/helloworldsource","id":"536808d3-88be-4077-9d7a-a3f162705f79","data":{"msg":"Hello Knative2!"}}'