Sources, Brokers, Triggers, Sinks, oh my!

    Let’s take a look at how these components interact:

    A note on Sources and Sinks

    A Knative Service can act as both a Source and a Sink for events, and for good reason. You may want to consume events from the Broker and send modified events back to the Broker, as you would in any pipeline use-case.

    What are CloudEvents?

    For our purposes, the only thing you need to know about CloudEvents are:

    1. CloudEvents can carry some attributes (like id, Source, type, etc) as well as data payloads (JSON, plaintext, reference to data that lives elsewhere, etc).
    2. CloudEvents follow the CloudEvents 1.0 Specification, with required and optional attributes.

    To find out more about CloudEvents, check out the !

    Examining the Broker

    As part of the install, an In-Memory Broker should already be installed in your Cluster. Check to see that it is installed by running the command:

    Warning

    In-Memory Brokers are for development use only and must not be used in a production deployment.

    Are there any other components of Knative Eventing?

    Though it is out of scope for this tutorial, Knative Eventing has many components which can be used in many ways to suit your needs.

    Next, you’ll take a look at a simple implementation of Sources, Brokers, Triggers and Sinks using an app called the CloudEvents Player.