Channel based Broker

The Channel based Broker (MTChannelBasedBroker) uses Channels for event routing. It is shipped by default with Knative Eventing. Users should prefer native Broker implementations (like Knative Broker for Apache Kafka or RabbitMQ Broker) over the MTChannelBasedBroker and Channel combination because it is usually more efficient as they reduce network hops for example.

Prerequisites

  • You have Knative Eventing installed.
  • You have a Channel implementation installed.

As the MTChannelBasedBroker is based on Channels, you need to install a Channel implementation. Check out the available Channels for a (non-exhaustive) list of the available Channels for Knative Eventing.

You can install for example the InMemory Channel by running the following command:

  1. kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.16.0/in-memory-channel.yaml

Create a MTChannelBasedBroker

You can create a MTChannelBasedBroker by using the kn CLI or by applying YAML files using kubectl.

knkubectl

You can create a MTChannelBasedBroker by entering the following command:

  1. kn broker create <broker-name> --class MTChannelBasedBroker

Where <broker-name> is the name of your Broker.

The YAML in the following example creates a Broker.

  1. Create a MTChannelBasedBroker by creating a YAML file using the following template:

    1. apiVersion: eventing.knative.dev/v1
    2. kind: Broker
    3. metadata:
    4. annotations:
    5. eventing.knative.dev/broker.class: MTChannelBasedBroker
    6. name: <broker-name>

    Where <broker-name> is the name of your Broker.

    Note

    Note, that the Broker class is specified via the eventing.knative.dev/broker.class annotation.

  2. Apply the YAML file:

    1. kubectl apply -f <filename>.yaml

    Where <filename> is the name of the file you created in the previous step.

Configuration

You configure the Broker object itself, or you can define cluster or namespace default values.

Broker specific configuration

It is possible to configure each Broker individually by referencing a ConfigMap in the spec.config:

  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: my-broker-specific-configuration
  13. namespace: default

The referenced ConfigMap must contain a channel-template-spec that defines the underlining Channel implementation for this Broker, as well as some Channel specific configurations. For example:

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: my-broker-specific-configuration
  5. namespace: default
  6. data:
  7. channel-template-spec: |
  8. apiVersion: messaging.knative.dev/v1
  9. kind: InMemoryChannel

Kafka Channel configuration example:

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: kafka-channel
  5. namespace: knative-eventing
  6. data:
  7. channel-template-spec: |
  8. apiVersion: messaging.knative.dev/v1beta1
  9. kind: KafkaChannel
  10. spec:
  11. numPartitions: 3
  12. replicationFactor: 1

Broker default configuration

The config-br-defaults ConfigMap defines default values for any Broker that does not specify a spec.config or a Broker class. It is possible to define these defaults cluser wide or on a per namespace basis. Check the Administrator configuration options on how to set Broker defaults cluster wide or on a namespace basis.

Developer documentation

For more information about MTChannelBasedBroker, see the MTChannelBasedBroker developer documentation.