Knative Eventing

Knative Eventing is a system that is designed to address a common need for cloud
native development and provides composable primitives to enable late-binding
event sources and event consumers.

Design overview

Knative Eventing is designed around the following goals:

Knative Eventing services are loosely coupled. These services can be
developed and deployed independently on, and across a variety of platforms
(for example Kubernetes, VMs, SaaS or FaaS).

Event producers and event consumers are independent. Any producer (or
source), 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.

Other services can be connected to the 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.

Ensure cross-service interoperability. Knative Eventing is consistent with
the
CloudEvents
specification that is developed by the
CNCF Serverless WG.

Event consumers

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

Addressable objects are able to receive and acknowledge an event
delivered over HTTP to an address defined in their status.address.hostname
field. As a special case, the core
Kubernetes Service object
also fulfils the Addressable interface.

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

Event brokers and triggers

As of v0.5, Knative Eventing defines Broker and Trigger objects to make it
easier to filter events.

A Broker provides a bucket of events which can be selected by attribute. It
receives events and forwards them to subscribers defined by one or more matching
Triggers.

A Trigger describes a filter on event attributes which should be delivered to an
Addressable. You can create as many Triggers as necessary.

Event registry

As of v0.6, Knative Eventing defines an EventType object to make it easier for
consumers to discover the types of events they can consume from the different
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.

Event channels and subscriptions

Knative Eventing also defines an event forwarding and persistence layer, called
a
Channel.
Messaging implementations may provide implementations of Channels via the
ClusterChannelProvisioner
object. Events are delivered to Services or forwarded to other channels
(possibly of a different type) using
Subscriptions.
This allows message delivery in a cluster to vary based on requirements, so that
some events might be handled by an in-memory implementation while others would
be persisted using Apache Kafka or NATS Streaming.

Future design goals

The focus for the next Eventing release will be to enable easy implementation of
event sources. Sources manage registration and delivery of events from external
systems using Kubernetes
Custom Resources.
Learn more about Eventing development in the
Eventing work group.

Architecture

The eventing infrastructure supports two forms of event delivery at the moment:

Direct delivery from a source to a single Service (an Addressable endpoint,
including a Knative Service or a core Kubernetes Service). In this case, the
Source is responsible for retrying or queueing events if the destination
Service is not available.

Fan-out delivery from a source or Service response to multiple endpoints
using
Channels
and
Subscriptions.
In this case, the Channel implementation ensures that messages are delivered
to the requested destinations and should buffer the events if the destination
Service is unavailable.

The actual message forwarding is implemented by multiple data plane components
which provide observability, persistence, and translation between different
messaging protocols.

Sources

Each source is a separate Kubernetes custom resource. This allows each type of
Source to define the arguments and parameters needed to instantiate a source.
Knative Eventing defines the following Sources in the
sources.eventing.knative.dev API group. Types below are declared in golang
format, but may be expressed as simple lists, etc in YAML. All Sources should be
part of the sources category, so you can list all existing Sources with
kubectl get sources. The currently-implemented Sources are described below.

In addition to the core sources (explained below), there are
other sources that you can install.

accessToken.secretKeyRef:
SecretKeySelector
containing a GitHub access token for configuring a GitHub webhook. One of this
or secretToken must be set.

secretToken.secretKeyRef:
SecretKeySelector
containing a GitHub secret token for configuring a GitHub webhook. One of this
or accessToken must be set.

serviceAccountName: string The name of the ServiceAccount to run the
container as.

sink:
ObjectReference
A reference to the object that should receive events.

githubAPIURL: string Optional field to specify the base URL for API
requests. Defaults to the public GitHub API if not specified, but can be set
to a domain endpoint to use with GitHub Enterprise, for example,
https://github.mycompany.com/api/v3/. This base URL should always be
specified with a trailing slash.

AwsSqsSource

The AwsSqsSource fires a new event each time an event is published on an
AWS SQS topic.

Spec fields:

queueURL: URL of the SQS queue to pull events from.

awsCredsSecret: credential to use to poll the AWS SQS queue.

sink:
ObjectReference
A reference to the object that should receive events.

serviceAccountName: string The name of the ServiceAccount used to access
the awsCredsSecret.

ContainerSource

The ContainerSource will instantiate a container image which can generate events
until the ContainerSource is deleted. This may be used (for example) to poll an
FTP server for new files or generate events at a set time interval.

Spec fields:

image (required): string A docker image of the container to be run.

args: []string Command-line arguments. If no --sink flag is provided,
one will be added and filled in with the DNS address of the sink object.

env: map[string]string Environment variables to be set in the container.

serviceAccountName: string The name of the ServiceAccount to run the
container as.

sink:
ObjectReference
A reference to the object that should receive events.

CamelSource

A CamelSource is an event source that can represent any existing
Apache Camel component
that provides a consumer side, and enables publishing events to an addressable
endpoint. Each Camel endpoint has the form of a URI where the scheme is the ID
of the component to use.

CamelSource requires Camel-K
to be installed into the current namespace.

Spec fields:

source: information on the kind of Camel source that should be created.

component: the default kind of source, enables creating an EventSource by
configuring a single Camel component.

uri: string contains the Camel URI that should be used to push events
into the target sink.

properties: key/value map contains Camel global options or component
specific configuration. Options are available in the documentation of each
existing Apache Camel component.

serviceAccountName: string an optional service account that can be used to
run the source pod.

image: string an optional base image to use for the source pod, mainly for
development purposes.