search

cloudevents / spec

CloudEvents Specification
https://cloudevents.io
Apache License 2.0
5.07k stars 583 forks source link

Knative broker as integration layer (event mesh) for CloudEvents #1316

Open wbaldowski-atos opened 4 hours ago

wbaldowski-atos commented 4 hours ago

Dear CloudEvents Community.

Many CNCF and CloudEvents papers mention the use of Knative as an agnostic platform, built according to the Event Mesh concept, which provides an abstraction for the message broker used by CloudEvents. Then it is possible to use and integrate various solutions such as Kafka or MQTT in the background.

In one of my projects I tried to use Knative in combination with the TriggerMesh tool, but I had to abandon this concept, because we use Kong as an ingress controller for Kubernetes, which does not support Knative.

My questions are as follows:

  1. Are you aware of the limitations of Knative, e.g. in the context of supported ingress controllers for Kubernetes?

  2. What is the practical level of use of Knative in production systems, as an abstraction and integration layer for the event broker for CloudEvents?

  3. Is there another similar solution that you can recommend that supports Kong?

Thanks in advance for your answers and any suggestions. Regards.

pierDipi commented 3 hours ago

Hi @wbaldowski-atos, I work on Knative Eventing, one initial note, Knative Eventing is independent from Knative Serving, you can use one without the other, but they work well together.

Are you aware of the limitations of Knative, e.g. in the context of supported ingress controllers for Kubernetes?

With the initial note in mind, Knative Eventing supports HTTP(S) as runtime protocol, in particular, HTTP binding for Cloudevents.

In brief, to send an event to a Knative Broker, you simply POST over HTTP(S) a cloudevent (using binary or structured mode).

To use Eventing in combination with Kong ingress (or any other ingress controller / class), you would simply

  1. Create a Knative Broker (this one will have a URL in the object status, status.address.url)
  2. Create a Kubernetes Ingress referencing a Broker service ( this depends on which Broker implementation you're using, however the URL found at the previous point will reveal what that is, here you can find an example with Knative Broker for Apache Kafka https://stackoverflow.com/questions/67800887/can-knatives-kafka-broker-be-fed-with-events-from-outside-its-cluster/67804273#67804273)
  3. Create triggers and event consumer applications (event consumer can be Knative Services or a regular HTTP Service + Deployment)

What is the practical level of use of Knative in production systems, as an abstraction and integration layer for the event broker for CloudEvents?

You can find some recent case studies here on how some organizations are using it: https://www.cncf.io/case-studies/ibmwatsonxassistant/ and https://www.cncf.io/case-studies/system-vertrieb-alexander-gmbh/

As well as some of the talks we've given:

Is there another similar solution that you can recommend that supports Kong?

In theory, as written above, Kong is usable with Knative Eventing (and not with Knative Serving), however, Eventing can be used without Serving and I would be happy to take a look at any issues you'd encounter when using Eventing with Kong ingress. In this case, I would suggest opening an issue here https://github.com/knative/eventing.