-
Notifications
You must be signed in to change notification settings - Fork 584
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
Comments
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.
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
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:
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. |
Thank you a lot for answer. Will study provided materials and will go back with more details when ready to continue. |
@wbaldowski-atos does this issue need to remain open? It feels like more a Knative issue than a CE one. |
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:
Are you aware of the limitations of Knative, e.g. in the context of supported ingress controllers for Kubernetes?
What is the practical level of use of Knative in production systems, as an abstraction and integration layer for the event broker for CloudEvents?
Is there another similar solution that you can recommend that supports Kong?
Thanks in advance for your answers and any suggestions.
Regards.
The text was updated successfully, but these errors were encountered: