Knative Eventing

    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.

    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.

    You can use a trigger to consume events from a broker based on event attributes. The application receives events as an HTTP POST.

    Tip

    Multiple event producers and sinks can be used together to create more advanced to solve complex use cases.

    Eventing components

    An event-driven architecture is based on the concept of decoupled relationships between event producers that create events, and event consumers, or , 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.

    This delivers the following benefits:

    • Event routing can be optimized by the underlying platform using the specified filter conditions.

    and Subscriptions provide a “event pipe” model which transforms and routes events between Channels using Subscriptions.

    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 .