Chapter 4. Brokers

Verification

1. Use the kn command to list all existing brokers:

   $ kn broker list

   Example output

   NAME      URL                                                                     AGE   CONDITIONS   READY   REASON
   default   http://broker-ingress.knative-eventing.svc.cluster.local/test/default   45s   5 OK / 5     True

2. Optional: If you are using the OpenShift Container Platform web console, you can navigate to the Topology view in the Developer perspective, and observe that the broker exists:

   

Procedure

1. Create a Trigger object as a YAML file that has the eventing.knative.dev/injection: enabled annotation:

   apiVersion: eventing.knative.dev/v1
   kind: Trigger
   metadata:
     annotations:
       eventing.knative.dev/injection: enabled
     name: <trigger_name>
   spec:
     broker: default
     subscriber: 1
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: <service_name>

   1

   Specify details about the event sink, or subscriber, that the trigger sends events to.

2. Apply the Trigger YAML file:

   $ oc apply -f <filename>

1. Enter the following oc command to get the broker:

   $ oc -n <namespace> get broker default

   Example output

   NAME      READY     REASON    URL                                                                     AGE
   default   True                http://broker-ingress.knative-eventing.svc.cluster.local/test/default   3m56s

2. Optional: If you are using the OpenShift Container Platform web console, you can navigate to the Topology view in the Developer perspective, and observe that the broker exists:

   

1. Use the oc command to get the broker:

   $ oc -n <namespace> get broker <broker_name>

   Example command

   $ oc -n default get broker default

   Example output

   NAME      READY     REASON    URL                                                                     AGE
   default   True                http://broker-ingress.knative-eventing.svc.cluster.local/test/default   3m56s

2. Optional: If you are using the OpenShift Container Platform web console, you can navigate to the Topology view in the Developer perspective, and observe that the broker exists:

   

Procedure

1. Remove the eventing.knative.dev/injection=enabled label from the namespace:

   $ oc label namespace <namespace> eventing.knative.dev/injection-

   Removing the annotation prevents Knative from recreating the broker after you delete it.

2. Delete the broker from the selected namespace:

   $ oc -n <namespace> delete broker <broker_name>

Procedure

1. In the Developer perspective, navigate to +Add Broker. The Broker page is displayed.
2. Optional. Update the Name of the broker. If you do not update the name, the generated broker is named default.
3. Click Create.

1. In the Developer perspective, navigate to Topology.

2. View the mt-broker-ingress, mt-broker-filter, and mt-broker-controller components.

   

Procedure

1. In the Administrator perspective of the OpenShift Container Platform web console, navigate to Serverless Eventing.
2. In the Create list, select Broker. You will be directed to the Create Broker page.
3. Optional: Modify the YAML configuration for the broker.
4. Click Create.

Procedure

1. Modify the kafka-broker-config config map, or create your own config map that contains the following configuration:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: <config_map_name> 1
     namespace: <namespace> 2
   data:
     default.topic.partitions: <integer> 3
     default.topic.replication.factor: <integer> 4
     bootstrap.servers: <list_of_servers> 5

   1

   The config map name.

   2

   The namespace where the config map exists.

   3

   The number of topic partitions for the Kafka broker. This controls how quickly events can be sent to the broker. A higher number of partitions requires greater compute resources.

   4

   The replication factor of topic messages. This prevents against data loss. A higher replication factor requires greater compute resources and more storage.

   5

   A comma separated list of bootstrap servers. This can be inside or outside of the OpenShift Container Platform cluster, and is a list of Kafka clusters that the broker receives events from and sends events to.

   Important

   The default.topic.replication.factor value must be less than or equal to the number of Kafka broker instances in your cluster. For example, if you only have one Kafka broker, the default.topic.replication.factor value should not be more than "1".

   Example Kafka broker config map

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: kafka-broker-config
     namespace: knative-eventing
   data:
     default.topic.partitions: "10"
     default.topic.replication.factor: "3"
     bootstrap.servers: "my-cluster-kafka-bootstrap.kafka:9092"

2. Apply the config map:

   $ oc apply -f <config_map_filename>

3. Specify the config map for the Kafka Broker object:

   Example Broker object

   apiVersion: eventing.knative.dev/v1
   kind: Broker
   metadata:
     name: <broker_name> 1
     namespace: <namespace> 2
     annotations:
       eventing.knative.dev/broker.class: Kafka 3
   spec:
     config:
       apiVersion: v1
       kind: ConfigMap
       name: <config_map_name> 4
       namespace: <namespace> 5
   ...

   1

   The broker name.

   2

   The namespace where the broker exists.

   3

   The broker class annotation. In this example, the broker is a Kafka broker that uses the class value Kafka.

   4

   The config map name.

   5

   The namespace where the config map exists.

4. Apply the broker:

   $ oc apply -f <broker_filename>

Procedure

1. Create or modify a Trigger object and set the kafka.eventing.knative.dev/delivery.order annotation:

   apiVersion: eventing.knative.dev/v1
   kind: Trigger
   metadata:
     name: <trigger_name>
     annotations:
        kafka.eventing.knative.dev/delivery.order: ordered
   ...

   The supported consumer delivery guarantees are:

   unordered

   An unordered consumer is a non-blocking consumer that delivers messages unordered, while preserving proper offset management.

   ordered

   An ordered consumer is a per-partition blocking consumer that waits for a successful response from the CloudEvent subscriber before it delivers the next message of the partition.

   The default ordering guarantee is unordered.

2. Apply the Trigger object:

   $ oc apply -f <filename>