Broker

    Before you can use the Knative Channel-based Broker, you must install a channel provider, such as InMemoryChannel, Kafka or Nats.

    NOTE: InMemoryChannel channels are for development use only and must not be used in a production deployment.

    For more information on which channels are available and how to install them, see the list of available channels.

    When an Event is sent to the Broker, all request metadata other than the CloudEvent data and context attributes is stripped away. Unless the information existed as a attribute, no information is retained about how this Event entered the Broker.

    Triggers register a subscriber’s interest in a particular class of events, so that the subscriber’s event sink will receive events that match the Trigger’s filter.

    Knative Eventing provides a config-br-defaults ConfigMap, which lives in the knative-eventing namespace, and provides default configuration settings to enable the creation of Brokers and Channels by using defaults. For more information, see the ConfigMap documentation.

    Create a Broker using the default settings:

    You can configure Knative Eventing so that when you create a broker, it uses a different type of broker than the default Knative channel-based broker. To configure a different broker type, or class, you must modify the eventing.knative.dev/broker.class annotation and spec.config for the Broker object. MTChannelBasedBroker is the broker class default.

    1. Modify the eventing.knative.dev/broker.class annotation. Replace MTChannelBasedBroker with the class type you want to use:
    1. kind: Broker
    2. metadata:
    3.   annotations:
    4.     eventing.knative.dev/broker.class: MTChannelBasedBroker
    1. Configure the spec.config with the details of the ConfigMap that defines the backing channel for the broker class:
    1. apiVersion: eventing.knative.dev/v1
    2. kind: Broker
    3. metadata:
    4.   annotations:
    5.     eventing.knative.dev/broker.class: MTChannelBasedBroker
    6.   name: default
    7. spec:
    8.   config:
    10.     kind: ConfigMap
    11.     name: config-br-default-channel
    12.     namespace: knative-eventing

    After you have created a Broker, you can complete the following tasks to finish setting up event delivery.

    Create a function to receive events. This document uses a Knative Service, but it could be anything that is Callable.

    Create a Trigger that sends only events of a particular type to the subscriber created above (my-service). For this example, we use Ping Source, and it emits events types dev.knative.sources.ping.

    1. kubectl create -f - <<EOF
    2. apiVersion: eventing.knative.dev/v1
    3. kind: Trigger
    4. metadata:
    5.   name: my-service-trigger
    6.   namespace: default
    7. spec:
    8.   broker: default
    9.   filter:
    10.     attributes:
    11.       type: dev.knative.sources.ping
    12.   subscriber:
    13.     ref:
    14.       apiVersion: serving.knative.dev/v1
    15.       name: my-service

    Knative Eventing comes with a which emits an event on a configured schedule. For this we’ll configure it to emit events once a minute, saying, yes, you guessed it Hello World!.

    1. apiVersion: eventing.knative.dev/v1
    2. kind: Broker
    3. metadata:
    4.   annotations:
    5.     eventing.knative.dev/broker.class: MTChannelBasedBroker
    6.   name: default
    7. spec:
    8.   # Configuration specific to this broker.
    9.   config:
    10.     apiVersion: v1
    11.     kind: ConfigMap
    12.     name: config-br-default-channel
    13.     namespace: knative-eventing
    14.   # Where to deliver Events that failed to be processed.
    15.   delivery:
    16.     deadLetterSink:
    17.       ref:
    18.         apiVersion: serving.knative.dev/v1

    See also: Delivery Parameters