Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
    2. history
×

Knative Eventing architecture

Knative Eventing on OpenShift Container Platform enables developers to use an event-driven architecture with serverless applications. An event-driven architecture is based on the concept of decoupled relationships between event producers that create events, and event sinks, or consumers, that receive them.

Knative Eventing uses standard HTTP POST requests to send and receive events between event producers and consumers. These events conform to the CloudEvents specifications, which enables creating, parsing, sending, and receiving events in any programming language.

You can propagate an event from an event source to multiple event sinks by using:

The channel and broker implementations manage delivery of events to event sinks, by using subscriptions and triggers. Events are buffered if the destination sink is unavailable.

Knative Eventing supports the following scenarios:

Publish an event without creating a consumer

You can send events to a Broker as an HTTP POST, and use a sink binding to decouple the destination configuration from your application that is producing events.

Consume an event without creating a publisher

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

Event sinks

To enable delivery to multiple types of sinks, Knative Eventing defines the following generic interfaces that can be implemented by multiple Kubernetes resources:

Addressable objects

Able to receive and acknowledge an event delivered over HTTP to an address defined in the event status.address.url field. The Kubernetes Service object also satisfies the addressable interface.

Callable objects

Able to receive an event delivered over HTTP and transform it, returning 0 or 1 new events in the HTTP response payload. These returned events can be further processed in the same way that events from an external event source are processed.