We use analytics and cookies to understand site traffic. Information about your use of our site is shared with Google for that purpose. Learn more.
MT Channel Based Broker
NOTE: This doc assume the shared Knative Eventing components are installed in the
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
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
ConfigMaps to describe how the Channels of each type are created:
# Define how InMemoryChannels are created apiVersion: v1 kind: ConfigMap metadata: namespace: knative-eventing name: imc-channel data: channelTemplateSpec: | apiVersion: messaging.knative.dev/v1beta1 kind: InMemoryChannel
# Define how Kafka channels are created. Note we specify # extra parameters that are particular to Kakfa Channels, namely # numPartitions as well as replicationFactor. apiVersion: v1 kind: ConfigMap metadata: name: kafka-channel namespace: knative-eventing data: channelTemplateSpec: | apiVersion: messaging.knative.dev/v1alpha1 kind: KafkaChannel spec: numPartitions: 3 replicationFactor: 1
kind: ConfigMap apiVersion: v1 metadata: name: config-br-defaults namespace: knative-eventing data: default-br-config: | clusterDefault: brokerClass: MTChannelBasedBroker apiVersion: v1 kind: ConfigMap name: imc-channel namespace: knative-eventing namespaceDefaults: brokerClass: MTChannelBasedBroker test-broker-6: apiVersion: v1 kind: ConfigMap name: kafka-channel namespace: knative-eventing
Creating Broker using defaults
To create the Broker assuming above mentioned default configuration.
kubectl apply -f - <<EOF apiVersion: eventing.knative.dev/v1beta1 kind: Broker metadata: name: mybroker EOF
This creates a
mybroker in the
namespace. As per above configuration, it would be configured to use
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:
kubectl apply -f - <<EOF # Define how Kafka channels are created. Note we specify # extra parameters that are particular to Kakfa Channels, namely # numPartitions as well as replicationFactor. apiVersion: v1 kind: ConfigMap metadata: name: my-kafka-channel namespace: my-namespace data: channelTemplateSpec: | apiVersion: messaging.knative.dev/v1alpha1 kind: KafkaChannel spec: numPartitions: 10 replicationFactor: 1 EOF
kubectl apply -f - <<EOF apiVersion: eventing.knative.dev/v1beta1 kind: Broker metadata: name: my-other-broker namespace: my-namespace annotations: eventing.knative.dev/broker.class: MTChannelBasedBroker spec: config: apiVersion: v1 kind: ConfigMap name: my-kafka-channel namespace: my-namespace EOF
Creating Broker by Annotation
The easiest way to get Broker installed, is to annotate your namespace
default with the desired namespace):
kubectl label namespace default knative-eventing-injection=enabled
This will automatically create a
default in the
namespace. As per above configuration, it would be configured to use Kafka
kubectl -n default get broker default
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
Broker as described above. If you now remove the annotation, the
will not be removed, you have to manually delete it.
For example, to delete the injected Broker from the foo namespace:
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
apiVersion: eventing.knative.dev/v1beta1 kind: Trigger metadata: annotations: knative-eventing-injection: enabled name: testevents-trigger0 namespace: default spec: broker: default filter: attributes: type: dev.knative.sources.ping subscriber: ref: apiVersion: serving.knative.dev/v1 kind: Service 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.
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.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.