Brokers

    Event delivery mechanics are an implementation detail that depend on the configured broker class. Using brokers and triggers abstracts the details of event routing from the event producer and event consumer.

    After an event has entered a broker, it can be forwarded to subscribers by using triggers. Triggers allow events to be filtered by attributes, so that events with particular attributes can be sent to subscribers that have registered interest in events with those attributes.

    For most use cases, a single broker per namespace is sufficient, but there are several use cases where multiple brokers can simplify architecture. For example, separate brokers for events containing Personally Identifiable Information (PII) and non-PII events can simplify audit and access control rules.

    The following broker types are available for use with Knative Eventing.

    Knative Eventing provides a multi-tenant (MT) channel-based broker implementation that uses channels for event routing.

    Alternative broker implementations

    In the Knative Eventing ecosystem, alternative broker implementations are welcome as long as they respect the broker specifications.

    The following is a list of brokers provided by the community or vendors:

    GCP broker

    The GCP broker is optimized for running in GCP. For more details, refer to the documentation.

    Apache Kafka broker

    RabbitMQ broker

    The RabbitMQ Broker uses for its underlying implementation. For more information, see the RabbitMQ broker in GitHub.

    Next steps