Brokers¶
Brokers are Kubernetes custom resources that define an event mesh for collecting a pool of events. Brokers provide a discoverable endpoint for event ingress, and use Triggers for event delivery. Event producers can send events to a broker by POSTing the event.
Event delivery¶
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.
A producer addresses the Broker rather than choosing each subscriber. A Trigger names that Broker, selects events by their CloudEvents attributes and extensions, and identifies a subscriber destination. This separates publishing from the subscription configuration. A Ready Broker or Trigger indicates that its configuration has reconciled; verifying a route also requires observing event receipt at the subscriber.
Filters select which events take a route; delivery settings govern what happens when delivery fails. Those are different concerns: changing retries will not make an event match a filter. The Trigger filtering reference states dialect support and matching behavior. The Event delivery reference states delivery fields and Broker/Channel support without assuming all implementations behave alike.
Advanced use cases¶
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.
Next steps¶
- Create a Broker.
- Route matching events to a subscriber and verify receipt.
- Configure and test retries and a dead-letter sink.
- Investigate events not reaching a subscriber or repeated delivery failures.
- Configure default Broker ConfigMap settings.