Knative Eventing provides tools for routing events from event producers to sinks, enabling developers to use an event-driven architecture with their applications.
Knative Eventing resources are loosely coupled, and can be developed and deployed independently of each other. Any producer can generate events before there are active event consumers that are listening. Any event consumer can express interest in an event or class of events, before there are producers that are creating those events.
Knative Eventing uses standard HTTP POST requests to send and receive events between event producers and sinks. These events conform to the CloudEvents specifications, which enables creating, parsing, sending, and receiving events in any programming language.
Other services can be connected to the Knative Eventing system. These services can perform the following functions:
- Create new applications without modifying the event producer or event consumer.
- Select and target specific subsets of the events from their producers.
You can install Knative Eventing via the methods listed on the installation page.
Common use cases¶
Knative Eventing supports the following use cases:
Publish an event without creating a consumer. You can send events to a broker as an HTTP POST, and use binding to decouple the destination configuration from your application that produces events.
Consume an event without creating a publisher. You can use a trigger to consume events from a broker based on event attributes. The application receives events as an HTTP POST.
Multiple event producers and sinks can be used together to create more advanced Knative Eventing flows to solve complex use cases.
An event-driven architecture is based on the concept of decoupled relationships between event producers that create events, and event consumers, or sinks, that receive events. It builds on delivery over HTTP by providing configuration and management of pluggable event-routing components.
A sink or subscriber can also be configured to respond to HTTP requests by sending a response event. Examples of sinks in a Knative Eventing deployment include Knative Services, Channels and Brokers.
In a Knative Eventing deployment, event Sources are the primary event producers. Events are sent to a sink or subscriber.
Broker and Trigger¶
This delivers the following benefits:
- Consumers can register for specific types of events without needing to negotiate directly with event producers.
- Event routing can be optimized by the underlying platform using the specified filter conditions.
Channel and Subscription¶
This model is appropriate for event pipelines where events from one system need to be transformed and then routed to another process.
Knative Eventing defines an EventType object to make it easier for consumers to discover the types of events they can consume from Brokers.
The registry consists of a collection of event types. The event types stored in the registry contain (all) the required information for a consumer to create a Trigger without resorting to some other out-of-band mechanism.
To learn how to use the registry, see the Event Registry documentation.