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.
Broker configuration example
The following is a full example of a multi-tenant (MT) channel-based Broker object which shows the possible configuration options that you can modify:
apiVersion: eventing.knative.dev/v1 kind: Broker metadata: name: default namespace: default annotations: eventing.knative.dev/broker.class: MTChannelBasedBroker spec: config: apiVersion: v1 kind: ConfigMap name: config-br-default-channel namespace: knative-eventing delivery: deadLetterSink: ref: kind: Service namespace: example-namespace name: example-service apiVersion: v1 uri: example-uri retry: 5 backoffPolicy: exponential backoffDelay: "2007-03-01T13:00:00Z/P1Y2M10DT2H30M"
- You can specify any valid
namefor your broker. Using
defaultwill create a broker named
namespacemust be an existing namespace in your cluster. Using
defaultwill create the broker in the current namespace.
- You can set the
eventing.knative.dev/broker.classannotation to change the class of the broker. The default broker class is
MTChannelBasedBroker, but Knative also supports use of the
KafkaBrokerclass. For more information about Kafka brokers, see the Apache Kafka Broker documentation.
spec.configis used to specify the default backing channel configuration for MT channel-based broker implementations. For more information on configuring the default channel type, see the documentation on ConfigMaps.
spec.deliveryis used to configure event delivery options. Event delivery options specify what happens to an event that fails to be delivered to an event sink. For more information, see the documentation on broker event delivery.
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.