Knative: Operator’s Handbook

Broker and Trigger Delivery

Complex Delivery with reply method works but it's hard to maintain multiple Channels and Subscriptions. It also does not have the concept for filtering, so Services have to filter all messages themselves.

The preferred model to work with is Broker and Trigger. Broker combines Channel, reply, and filter functionality into a single resource. Trigger provides declarative filtering of all events.

In the Broker and Trigger model, the Complex Delivery with reply method turns into this:

Broker and Trigger Deliverydiagram

Once the Broker is injected in the namespace, a Source simply points to the Broker:

apiVersion: sources.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
  name: source
spec:
  schedule: "* * * * *"
  data: '{"message": "Hello world from cron!"}'
  sink:
    apiVersion: eventing.knative.dev/v1alpha1
    kind: Broker
    name: default

A Service registers interest to events from the Broker by creating a Trigger.

In this example, only Service2 sends a reply but any Service can reply back. Replies are sent back into the Broker and filtered again in Triggers. Therefore, it's important to set a filter for each Trigger to make sure Services do not receive unintended messages.

In this example, Trigger for Service1 and Service2 should filter for CronJobSource events:

apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
  name: trigger1
spec:
  filter:
    attributes:
      type: dev.knative.cronjob.event
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: service1

Trigger for Service3 should filter for the the type emitted by Service2, in this case dev.knative.samples.hifromknative:

apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
  name: trigger3
spec:
  filter:
    attributes:
      type: dev.knative.samples.hifromknative
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: service3