MT Channel Based Broker

NOTE: This doc assume the shared Knative Eventing components are installed in the knative-eventing namespace. If you installed the shared Knative Eventing components in a different namespace, replace knative-eventing with the name of that namespace. Furthermore, you have to install the Multi Tenant Channel Based Broker.

Knative provides a Multi Tenant Broker implementation that uses Channels for event routing. You will need to have a Channel provider installed, for example InMemoryChannel (for development purposes), Kafka, Nats, etc. You can choose from list of available channels

Once you have decided which Channel(s) you want to use and have installed them, you can configure the Broker by controlling which Channel(s) are used. You can choose this as a cluster level default, by namespace or by a specific Broker. These are configured by a config-br-defaults ConfigMap in knative-eventing namespace.

Here’s an example of a configuration that uses Kafka channel for all the Brokers except namespace test-broker-6 which uses InMemoryChannels. First define the ConfigMaps to describe how the Channels of each type are created:

  1. # Define how InMemoryChannels are created
  2. apiVersion: v1
  3. kind: ConfigMap
  4. metadata:
  5.   namespace: knative-eventing
  6.   name: imc-channel
  7. data:
  8.   channelTemplateSpec: |
  9.     apiVersion: messaging.knative.dev/v1beta1
  10.     kind: InMemoryChannel
  1. # Define how Kafka channels are created. Note we specify
  2. # extra parameters that are particular to Kakfa Channels, namely
  3. # numPartitions as well as replicationFactor.
  4. apiVersion: v1
  5. kind: ConfigMap
  6. metadata:
  7.   name: kafka-channel
  8.   namespace: knative-eventing
  9. data:
  10.   channelTemplateSpec: |
  11.     apiVersion: messaging.knative.dev/v1alpha1
  12.     kind: KafkaChannel
  13.     spec:
  14.       numPartitions: 3
  15.       replicationFactor: 1
  1. kind: ConfigMap
  2. apiVersion: v1
  3. metadata:
  4.   name: config-br-defaults
  5.   namespace: knative-eventing
  6. data:
  7.   default-br-config: |
  8.     clusterDefault:
  9.       brokerClass: MTChannelBasedBroker
  10.       apiVersion: v1
  11.       kind: ConfigMap
  12.       name: imc-channel
  13.       namespace: knative-eventing
  14.     namespaceDefaults:
  15.       brokerClass: MTChannelBasedBroker
  16.       test-broker-6:
  17.         apiVersion: v1
  18.         kind: ConfigMap
  19.         name: kafka-channel
  20.         namespace: knative-eventing

Creating Broker using defaults

To create the Broker assuming above mentioned default configuration.

  1. kubectl apply -f - <<EOF
  2. apiVersion: eventing.knative.dev/v1beta1
  3. kind: Broker
  4. metadata:
  5.   name: mybroker
  6. EOF

This creates a Broker named mybroker in the default namespace. As per above configuration, it would be configured to use InMemoryChannel.

  1. kubectl -n default get broker mybroker

Creating Broker without defaults

You can also configure all aspects of your Broker by not relying on default behaviours, and just construct the entire object. For example, say you wanted to create a Broker that has a different Kafka configuration. You would first create the configuration you’d like to use, for example let’s increase the number of partitions to 10:

  1. kubectl apply -f - <<EOF
  2. # Define how Kafka channels are created. Note we specify
  3. # extra parameters that are particular to Kakfa Channels, namely
  4. # numPartitions as well as replicationFactor.
  5. apiVersion: v1
  6. kind: ConfigMap
  7. metadata:
  8.   name: my-kafka-channel
  9.   namespace: my-namespace
  10. data:
  11.   channelTemplateSpec: |
  12.     apiVersion: messaging.knative.dev/v1alpha1
  13.     kind: KafkaChannel
  14.     spec:
  15.       numPartitions: 10
  16.       replicationFactor: 1
  17. EOF
  1. kubectl apply -f - <<EOF
  2. apiVersion: eventing.knative.dev/v1beta1
  3. kind: Broker
  4. metadata:
  5.   name: my-other-broker
  6.   namespace: my-namespace
  7.   annotations:
  8.     eventing.knative.dev/broker.class: MTChannelBasedBroker
  9. spec:
  10.   config:
  11.     apiVersion: v1
  12.     kind: ConfigMap
  13.     name: my-kafka-channel
  14.     namespace: my-namespace
  15. EOF

Creating Broker by Annotation

The easiest way to get Broker installed, is to annotate your namespace (replace default with the desired namespace):

  1. kubectl label namespace default knative-eventing-injection=enabled

This will automatically create a Broker named default in the default namespace. As per above configuration, it would be configured to use Kafka channels.

  1. kubectl -n default get broker default

NOTE Brokers created due to annotation will not be removed if you remove the annotation. For example, if you annotate the namespace, which will then create the Broker as described above. If you now remove the annotation, the Broker will not be removed, you have to manually delete it.

For example, to delete the injected Broker from the foo namespace:

  1. kubectl -n foo delete broker default

Creating Broker by Trigger Annotation

Besides the annotation of the namespace, there is an alternative approach to annotate one of the Triggers, with knative-eventing-injection: enabled:

  1. apiVersion: eventing.knative.dev/v1beta1
  2. kind: Trigger
  3. metadata:
  4.   annotations:
  5.     knative-eventing-injection: enabled
  6.   name: testevents-trigger0
  7.   namespace: default
  8. spec:
  9.   broker: default
  10.   filter:
  11.     attributes:
  12.       type: dev.knative.sources.ping
  13.   subscriber:
  14.     ref:
  15.       apiVersion: serving.knative.dev/v1
  16.       kind: Service
  17.       name: broker-display

However, this approach only works if the Trigger is coupled to the default Broker, and takes only effect when there is no default Broker already present.

Deleting the Trigger does not delete the Broker. With this approach the same rules from the namespace annotation apply here.

You can find out more about delivery spec details here.