×

Broker types

There are multiple broker implementations available for use with OpenShift Serverless, each of which have different event delivery guarantees and use different underlying technologies. You can choose the broker implementation when creating a broker by specifying a broker class, otherwise the default broker class is used. The default broker class can be configured by cluster administrators.

Channel-based broker

The channel-based broker implementation internally uses channels for event delivery. Channel-based brokers provide different event delivery guarantees based on the channel implementation a broker instance uses, for example:

  • A broker using the InMemoryChannel implementation is useful for development and testing purposes, but does not provide adequate event delivery guarantees for production environments.

  • A broker using the KafkaChannel implementation provides the event delivery guarantees required for a production environment.

Kafka broker

The Kafka broker is a broker implementation that uses Kafka internally to provide at-least once delivery guarantees. It supports multiple Kafka versions, and has a native integration with Kafka for storing and routing events.

Kafka broker is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

Creating a broker that uses default settings

OpenShift Serverless provides a default Knative broker that you can create by using the kn CLI. You can also create the default broker by adding the eventing.knative.dev/injection: enabled annotation to a trigger, or by adding the eventing.knative.dev/injection=enabled label to a namespace.

Creating a broker by using the Knative CLI

Brokers can be used in combination with triggers to deliver events from an event source to an event sink. Using the kn CLI to create brokers provides a more streamlined and intuitive user interface over modifying YAML files directly. You can use the kn broker create command to create a broker by using the kn CLI.

Prerequisites
  • The OpenShift Serverless Operator and Knative Eventing are installed on your Red Hat OpenShift Service on AWS cluster.

  • You have installed the Knative (kn) CLI.

  • You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in Red Hat OpenShift Service on AWS.

Procedure
  • Create the default broker:

    $ kn broker create default
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 Red Hat OpenShift Service on AWS web console, you can navigate to the Topology view in the Developer perspective, and observe that the broker exists:

    View the broker in the web console Topology view

Creating a broker by annotating a trigger

Brokers can be used in combination with triggers to deliver events from an event source to an event sink. You can create a broker by adding the eventing.knative.dev/injection: enabled annotation to a Trigger object.

If you create a broker by using the eventing.knative.dev/injection: enabled annotation, you cannot delete this broker without cluster administrator permissions. If you delete the broker without having a cluster administrator remove this annotation first, the broker is created again after deletion.

Prerequisites
  • The OpenShift Serverless Operator and Knative Eventing are installed on your Red Hat OpenShift Service on AWS cluster.

  • Install the OpenShift (oc) CLI.

  • You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in Red Hat OpenShift Service on AWS.

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>
Verification

You can verify that the broker has been created successfully by using the oc CLI, or by observing it in the Topology view in the web console.

  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 Red Hat OpenShift Service on AWS web console, you can navigate to the Topology view in the Developer perspective, and observe that the broker exists:

    View the broker in the web console Topology view

Creating a broker by labeling a namespace

Brokers can be used in combination with triggers to deliver events from an event source to an event sink. You can create the default broker automatically by labelling a namespace that you own or have write permissions for.

Brokers created using this method are not removed if you remove the label. You must manually delete them.

Prerequisites
  • The OpenShift Serverless Operator and Knative Eventing are installed on your Red Hat OpenShift Service on AWS cluster.

  • Install the OpenShift (oc) CLI.

  • You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in Red Hat OpenShift Service on AWS.

  • You have cluster or dedicated administrator permissions.

Procedure
  • Label a namespace with eventing.knative.dev/injection=enabled:

    $ oc label namespace <namespace> eventing.knative.dev/injection=enabled
Verification

You can verify that the broker has been created successfully by using the oc CLI, or by observing it in the Topology view in the web console.

  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 Red Hat OpenShift Service on AWS web console, you can navigate to the Topology view in the Developer perspective, and observe that the broker exists:

    View the broker in the web console Topology view

Deleting a broker that was created by injection

If you create a broker by injection and later want to delete it, you must delete it manually. Brokers created by using a namespace label or trigger annotation are not deleted permanently if you remove the label or annotation.

Prerequisites
  • Install the OpenShift (oc) CLI.

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>
Verification
  • 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
    No resources found.
    Error from server (NotFound): brokers.eventing.knative.dev "default" not found

Creating a broker by using the web console

After Knative Eventing is installed on your cluster, you can create a broker by using the web console. Using the Red Hat OpenShift Service on AWS web console provides a streamlined and intuitive user interface to create a broker.

Prerequisites
  • You have logged in to the Red Hat OpenShift Service on AWS web console.

  • The OpenShift Serverless Operator, Knative Serving and Knative Eventing are installed on the cluster.

  • You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in Red Hat OpenShift Service on AWS.

Procedure
  1. In the Developer perspective, navigate to +AddBroker. 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.

Verification

You can verify that the broker was created by viewing broker components in the Topology page.

  1. In the Developer perspective, navigate to Topology.

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

    View the broker components in the Topology view

Kafka broker

If a cluster administrator has configured your OpenShift Serverless deployment to use Kafka as the default broker type, creating a broker by using the default settings creates a Kafka-based Broker object. If your OpenShift Serverless deployment is not configured to use Kafka broker as the default broker type, you can use one of the following procedures to create a Kafka-based broker.

Kafka broker is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

The Kafka broker, which is currently in Technology Preview, is not supported on FIPS.

Creating a Kafka broker by using YAML

Creating Knative resources by using YAML files uses a declarative API, which enables you to describe applications declaratively and in a reproducible manner. To create a Kafka broker by using YAML, you must create a YAML file that defines a Broker object, then apply it by using the oc apply command.

Prerequisites
  • The OpenShift Serverless Operator, Knative Eventing, and the KnativeKafka custom resource are installed on your Red Hat OpenShift Service on AWS cluster.

  • You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in Red Hat OpenShift Service on AWS.

  • You have installed the OpenShift (oc) CLI.

Procedure
  1. Create a Kafka-based broker as a YAML file:

    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      annotations:
        eventing.knative.dev/broker.class: Kafka (1)
      name: example-kafka-broker
    spec:
      config:
        apiVersion: v1
        kind: ConfigMap
        name: kafka-broker-config (2)
        namespace: knative-eventing
    1 The broker class. If not specified, brokers use the default class as configured by cluster administrators. To use the Kafka broker, this value must be Kafka.
    2 The default config map for Knative Kafka brokers. This config map is created when the Kafka broker functionality is enabled on the cluster by a cluster administrator.
  2. Apply the Kafka-based broker YAML file:

    $ oc apply -f <filename>

Creating a Kafka broker that uses an externally managed Kafka topic

If you want to use a Kafka broker without allowing it to create its own internal topic, you can use an externally managed Kafka topic instead. To do this, you must create a Kafka Broker object that uses the kafka.eventing.knative.dev/external.topic annotation.

Prerequisites
  • The OpenShift Serverless Operator, Knative Eventing, and the KnativeKafka custom resource are installed on your Red Hat OpenShift Service on AWS cluster.

  • You have access to a Kafka instance such as Red Hat AMQ Streams, and have created a Kafka topic.

  • You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in Red Hat OpenShift Service on AWS.

  • You have installed the OpenShift (oc) CLI.

Procedure
  1. Create a Kafka-based broker as a YAML file:

    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      annotations:
        eventing.knative.dev/broker.class: Kafka (1)
        kafka.eventing.knative.dev/external.topic: <topic_name> (2)
    ...
    1 The broker class. If not specified, brokers use the default class as configured by cluster administrators. To use the Kafka broker, this value must be Kafka.
    2 The name of the Kafka topic that you want to use.
  2. Apply the Kafka-based broker YAML file:

    $ oc apply -f <filename>

Managing brokers

The kn CLI provides commands that can be used to list, describe, update, and delete brokers.

Listing existing brokers by using the Knative CLI

Using the kn CLI to list brokers provides a streamlined and intuitive user interface. You can use the kn broker list command to list existing brokers in your cluster by using the kn CLI.

Prerequisites
  • The OpenShift Serverless Operator and Knative Eventing are installed on your Red Hat OpenShift Service on AWS cluster.

  • You have installed the Knative (kn) CLI.

Procedure
  • 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

Describing an existing broker by using the Knative CLI

Using the kn CLI to describe brokers provides a streamlined and intuitive user interface. You can use the kn broker describe command to print information about existing brokers in your cluster by using the kn CLI.

Prerequisites
  • The OpenShift Serverless Operator and Knative Eventing are installed on your Red Hat OpenShift Service on AWS cluster.

  • You have installed the Knative (kn) CLI.

Procedure
  • Describe an existing broker:

    $ kn broker describe <broker_name>
    Example command using default broker
    $ kn broker describe default
    Example output
    Name:         default
    Namespace:    default
    Annotations:  eventing.knative.dev/broker.class=MTChannelBasedBroker, eventing.knative.dev/creato ...
    Age:          22s
    
    Address:
      URL:    http://broker-ingress.knative-eventing.svc.cluster.local/default/default
    
    Conditions:
      OK TYPE                   AGE REASON
      ++ Ready                  22s
      ++ Addressable            22s
      ++ FilterReady            22s
      ++ IngressReady           22s
      ++ TriggerChannelReady    22s