Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wbaldowski-atos opened this issue Nov 8, 2024 · 3 comments
Open

Comments

@wbaldowski-atos
Copy link

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
Copy link
Member

pierDipi commented Nov 8, 2024

Hi @wbaldowski-atos, I work on Knative Eventing and CloudEvents, 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.

@wbaldowski-atos
Copy link
Author

Thank you a lot for answer. Will study provided materials and will go back with more details when ready to continue.

@duglin
Copy link
Collaborator

duglin commented Nov 11, 2024

@wbaldowski-atos does this issue need to remain open? It feels like more a Knative issue than a CE one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants