Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 6. Channels

6.1. Channels and subscriptions
Link kopieren

Channels are custom resources that define a single event-forwarding and persistence layer. After events have been sent to a channel from an event source or producer, these events can be sent to multiple Knative services or other sinks by using a subscription.

Channel workflow overview

You can create channels by instantiating a supported Channel object, and configure re-delivery attempts by modifying the delivery spec in a Subscription object.

After you create a Channel object, a mutating admission webhook adds a set of spec.channelTemplate properties for the Channel object based on the default channel implementation. For example, for an InMemoryChannel default implementation, the Channel object looks as follows: 

apiVersion: messaging.knative.dev/v1
kind: Channel
metadata:
  name: example-channel
  namespace: default
spec:
  channelTemplate:
    apiVersion: messaging.knative.dev/v1
    kind: InMemoryChannel

The channel controller then creates the backing channel instance based on the spec.channelTemplate configuration.

Note

The spec.channelTemplate properties cannot be changed after creation, because they are set by the default channel mechanism rather than by the user.

When this mechanism is used with the preceding example, two objects are created: a generic backing channel and an InMemoryChannel channel. If you are using a different default channel implementation, the InMemoryChannel is replaced with one that is specific to your implementation. For example, with the Knative broker for Apache Kafka, the KafkaChannel channel is created.

The backing channel acts as a proxy that copies its subscriptions to the user-created channel object, and sets the user-created channel object status to reflect the status of the backing channel.

6.1.1. Channel implementation types
Link kopieren

OpenShift Serverless supports the InMemoryChannel and KafkaChannel channels implementations. The InMemoryChannel channel is recommended for development use only due to its limitations. You can use the KafkaChannel channel for a production environment.

The following are limitations of InMemoryChannel type channels:

  • No event persistence is available. If a pod goes down, events on that pod are lost.
  • InMemoryChannel channels do not implement event ordering, so two events that are received in the channel at the same time can be delivered to a subscriber in any order.
  • If a subscriber rejects an event, there are no re-delivery attempts by default. You can configure re-delivery attempts by modifying the delivery spec in the Subscription object.

6.2. Creating channels
Link kopieren

Channels are custom resources that define a single event-forwarding and persistence layer. After events have been sent to a channel from an event source or producer, these events can be sent to multiple Knative services or other sinks by using a subscription.

Channel workflow overview

You can create channels by instantiating a supported Channel object, and configure re-delivery attempts by modifying the delivery spec in a Subscription object.

6.2.1. Creating a channel
Link kopieren

Using the OpenShift Container Platform web console provides a streamlined and intuitive user interface to create a channel. After installing Knative Eventing on your cluster, create a channel in the web console.

Prerequisites

  • You have logged in to the OpenShift Container Platform web console.
  • You have installed the OpenShift Serverless Operator and Knative Eventing on your OpenShift Container Platform 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 OpenShift Container Platform.

Procedure

  1. Navigate to +Add Channel.

  2. Select the type of Channel object that you want to create in the Type list.

    Note

    Currently only InMemoryChannel channel objects are supported by default. Knative channels for Apache Kafka are available if you have installed the Knative broker implementation for Apache Kafka on OpenShift Serverless.

  3. Click Create.

Verification

  • Confirm that the channel now exists by navigating to the Topology page.

    View the channel in the Topology view

6.2.2. Creating a channel by using the Knative CLI
Link kopieren

Using the Knative (kn) CLI to create channels provides a more streamlined and intuitive user interface than modifying YAML files directly. You can use the kn channel create command to create a channel.

Prerequisites

  • You have installed the OpenShift Serverless Operator and Knative Eventing on the 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 OpenShift Container Platform.

Procedure

  • Create a channel: 

    $ kn channel create <channel_name> --type <channel_type>

    The channel type is optional. If you specify it, you must use the Group:Version:Kind format. For example, you can create an InMemoryChannel object: 

    $ kn channel create mychannel --type messaging.knative.dev:v1:InMemoryChannel

    Example output

    Channel 'mychannel' created in namespace 'default'.

Verification

  • To confirm that the channel now exists, list the existing channels and inspect the output: 

    $ kn channel list

    Example output

    kn channel list
NAME        TYPE              URL                                                     AGE   READY   REASON
mychannel   InMemoryChannel   http://mychannel-kn-channel.default.svc.cluster.local   93s   True

Deleting a channel

  • Delete a channel: 

    $ kn channel delete <channel_name>

6.2.3. Creating a default implementation channel by using YAML
Link kopieren

You can use YAML files to create Knative resources through a declarative API. Define channels declaratively and reproduce the configuration consistently. To create a serverless channel by using YAML, you must create a YAML file that defines a Channel object, then apply it by using the oc apply command.

Prerequisites

  • You have installed the OpenShift Serverless Operator and Knative Eventing on the cluster.
  • Install the OpenShift CLI (oc).
  • You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.

Procedure

  1. Create a Channel object as a YAML file: 

    apiVersion: messaging.knative.dev/v1
kind: Channel
metadata:
  name: example-channel
  namespace: default

  2. Apply the YAML file: 

    $ oc apply -f <filename>

6.2.4. Creating a channel for Apache Kafka by using YAML
Link kopieren

You can use YAML files to create Knative resources through a declarative API. Define channels declaratively and reproduce the configuration consistently. You can create a Knative Eventing channel that uses Kafka topics by creating a Kafka channel. To create a Kafka channel with YAML, define a KafkaChannel object in a YAML file and apply the file by using the oc apply command.

Prerequisites

  • You have installed the OpenShift Serverless Operator, Knative Eventing, and the KnativeKafka custom resource on your OpenShift Container Platform cluster.
  • Install the OpenShift CLI (oc).
  • You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.

Procedure

  1. Create a KafkaChannel object as a YAML file: 

    apiVersion: messaging.knative.dev/v1beta1
kind: KafkaChannel
metadata:
  name: example-channel
  namespace: default
spec:
  numPartitions: 3
  replicationFactor: 1
    Important

    Only the v1beta1 version of the API for KafkaChannel objects on OpenShift Serverless is supported. Do not use the v1alpha1 version of this API, as this version is now deprecated.

  2. Apply the KafkaChannel YAML file: 

    $ oc apply -f <filename>

6.2.5. Next steps
Link kopieren

6.3. Connecting channels to sinks
Link kopieren

Events that have been sent to a channel from an event source or producer can be forwarded to one or more sinks by using subscriptions. You can create subscriptions by configuring a Subscription object, which specifies the channel and the sink (also known as a subscriber) that consumes the events sent to that channel.

6.3.1. Creating a subscription
Link kopieren

After you have created a channel and an event sink, you can create a subscription to enable event delivery. Using the OpenShift Container Platform web console provides a streamlined and intuitive user interface to create a subscription.

Prerequisites

  • You have installed the OpenShift Serverless Operator, Knative Serving, and Knative Eventing on your OpenShift Container Platform cluster.
  • You have logged in to the web console.
  • You have created an event sink, such as a Knative service, and a channel.
  • You have created a project or have access to a project with the appropriate roles and privileges to create applications and other workloads in OpenShift Container Platform.

Procedure

  1. Navigate to the Topology page.

  2. Create a subscription using one of the following methods:

    1. Hover over the channel that you want to create a subscription for, and drag the arrow. The Add Subscription option is displayed.

      Create a subscription for the channel
      1. Select your sink in the Subscriber list.
      2. Click Add.
    2. If the service is available in the Topology view under the same namespace or project as the channel, click the channel that you want to create a subscription for, and drag the arrow directly to a service to immediately create a subscription from the channel to that service.

Verification

  • After you create the subscription, the Topology view shows it as a line that connects the channel to the service.

    Subscription in the Topology view

6.3.2. Creating a subscription by using YAML
Link kopieren

After you create a channel and an event sink, create a subscription to deliver events. You can define Knative resources declaratively by using YAML files. To create a subscription, create a YAML file that defines a Subscription object, and then apply the file by using the oc apply command.

Prerequisites

  • You have installed the OpenShift Serverless Operator and Knative Eventing on the cluster.
  • Install the OpenShift CLI (oc).
  • You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.

Procedure

  • Create a Subscription object:

    • Create a YAML file and copy the following sample code into it: 

      apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
  name: my-subscription
      1 
      
  namespace: default
spec:
  channel:
      2 
      
    apiVersion: messaging.knative.dev/v1
    kind: Channel
    name: example-channel
  delivery:
      3 
      
    deadLetterSink:
      ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: error-handler
  subscriber:
      4 
      
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: event-display
      1
      Name of the subscription.
      2
      Configuration settings for the channel that the subscription connects to.
      3
      Configuration settings for event delivery. These settings define how the subscription handles events that the subscriber cannot receive. When you configure this option, the system sends failed events to the deadLetterSink. The system drops the event, does not try redelivery, and logs an error. The deadLetterSink value must be a Destination.
      4
      Configuration settings for the subscriber. The subscriber is the event sink that receives events from the channel.

    • Apply the YAML file: 

      $ oc apply -f <filename>

6.3.3. Creating a subscription by using the Knative CLI
Link kopieren

After you have created a channel and an event sink, you can create a subscription to enable event delivery. Using the Knative (kn) CLI to create subscriptions provides a more streamlined and intuitive user interface than modifying YAML files directly. You can use the kn subscription create command with the appropriate flags to create a subscription.

Prerequisites

  • You have installed the OpenShift Serverless Operator and Knative Eventing on your OpenShift Container Platform 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 OpenShift Container Platform.

Procedure

  • Create a subscription to connect a sink to a channel: 

    $ kn subscription create <subscription_name> \
  --channel <group:version:kind>:<channel_name> \
    1 
    
  --sink <sink_prefix>:<sink_name> \
    2 
    
  --sink-dead-letter <sink_prefix>:<sink_name>
    3
    1
    Use --channel to specify the source of CloudEvents to process. You can give the channel name. If you do not use the default InMemoryChannel defined by the Channel custom resource, prefix the channel name with <group:version:kind> for the channel type. For example, use messaging.knative.dev:v1beta1:KafkaChannel for an Apache Kafka channel.
    2
    Use --sink to specify the event destination. By default, the system treats <sink_name> as a Knative service with that name in the same namespace as the subscription. Use one of the following prefixes to specify the sink type:
    ksvc
    A Knative service.
    channel
    Specify the channel to use as the destination. Reference only default channel types.
    broker
    An Eventing broker.
    3
    Optional: Use the optional --sink-dead-letter flag to specify a sink that receives events when delivery fails.

    Example command

    $ kn subscription create mysubscription --channel mychannel --sink ksvc:event-display

    Example output

    Subscription 'mysubscription' created in namespace 'default'.

Verification

  • To confirm that a subscription connects the channel to the event sink, or subscriber, list the existing subscriptions and inspect the output by running the following command: 

    $ kn subscription list

    Example output

    NAME            CHANNEL             SUBSCRIBER           REPLY   DEAD LETTER SINK   READY   REASON
mysubscription   Channel:mychannel   ksvc:event-display                              True

Deleting a subscription

  • Delete a subscription: 

    $ kn subscription delete <subscription_name>

6.3.4. Creating a subscription with administrator privileges
Link kopieren

After you have created a channel and an event sink, also known as a subscriber, you can create a subscription to enable event delivery. You can create subscriptions by configuring a Subscription object that specifies the channel and the subscriber that receives events. You can also specify some subscriber-specific options, such as how to handle failures.

Prerequisites

  • You have installed the OpenShift Serverless Operator and Knative Eventing on your OpenShift Container Platform cluster.
  • You have logged in to the web console.
  • You have cluster-admin privileges on OpenShift Container Platform, or you have cluster or dedicated administrator privileges on Red Hat OpenShift Service on AWS or OpenShift Dedicated.
  • You have created an event sink, such as a Knative service, and a channel.

Procedure

  1. In the OpenShift Container Platform web console, navigate to Serverless Eventing.
  2. In the Channel tab, select the Options menu kebab for the channel that you want to add a subscription to.
  3. Click Add Subscription in the list.
  4. In the Add Subscription dialogue box, select a Subscriber for the subscription. The subscriber is the Knative service that receives events from the channel.
  5. Click Add.

6.3.5. Next steps
Link kopieren

  • Configure Event delivery parameters that are applied in cases where an event fails to be delivered to an event sink.

6.4. Default channel implementation
Link kopieren

You can use the default-ch-webhook config map to specify the default channel implementation of Knative Eventing. You can specify the default channel implementation for the entire cluster or for one or more namespaces. Currently the InMemoryChannel and KafkaChannel channel types are supported.

6.4.1. Configuring the default channel implementation
Link kopieren

You can configure the default channel implementation for Knative Eventing at the cluster or namespace level by using the KnativeEventing custom resource (CR). Specify the default channel implementation, such as InMemoryChannel, KafkaChannel, or other supported implementations, for newly created channels.

Prerequisites

  • You have administrator permissions on OpenShift Container Platform.
  • You have installed the OpenShift Serverless Operator and Knative Eventing on your cluster.
  • If you want to use Knative channels for Apache Kafka as the default channel implementation, you must also install the KnativeKafka CR on your cluster.

Procedure

  • Change the KnativeEventing custom resource to add configuration details for the default-ch-webhook config map: 

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  config:
    1 
    
    default-ch-webhook:
    2 
    
      default-ch-config: |
        clusterDefault:
    3 
    
          apiVersion: messaging.knative.dev/v1
          kind: InMemoryChannel
          spec:
            delivery:
              backoffDelay: PT0.5S
              backoffPolicy: exponential
              retry: 5
        namespaceDefaults:
    4 
    
          my-namespace:
            apiVersion: messaging.knative.dev/v1beta1
            kind: KafkaChannel
            spec:
              numPartitions: 1
              replicationFactor: 1
    1
    In spec.config, you can specify the config maps that you want to add modified configurations for.
    2
    You can use the default-ch-webhook config map to specify the default channel implementation for the cluster or for one or more namespaces.
    3
    The cluster-wide default channel type configuration. In this example, the default channel implementation for the cluster is InMemoryChannel.
    4
    The namespace-scoped default channel type configuration. In this example, the default channel implementation for the my-namespace namespace is KafkaChannel.
    Important

    Configuring a namespace-specific default overrides any cluster-wide settings.

6.5. Security configuration for channels
Link kopieren

Transport Layer Security (TLS) is used by Apache Kafka clients and servers to encrypt traffic between Knative and Kafka, as well as for authentication. TLS is the only supported method of traffic encryption for the Knative broker implementation for Apache Kafka.

Prerequisites

  • You have cluster or dedicated administrator permissions on OpenShift Container Platform.
  • The OpenShift Serverless Operator, Knative Eventing, and the KnativeKafka CR are installed on your OpenShift Container Platform 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 OpenShift Container Platform.
  • You have a Kafka cluster CA certificate stored as a .pem file.
  • You have a Kafka cluster client certificate and a key stored as .pem files.
  • Install the OpenShift CLI (oc).

Procedure

  1. Create the certificate files as secrets in your chosen namespace: 

    $ oc create secret -n <namespace> generic <kafka_auth_secret> \
  --from-file=ca.crt=caroot.pem \
  --from-file=user.crt=certificate.pem \
  --from-file=user.key=key.pem
    Important

    Use the key names ca.crt, user.crt, and user.key. Do not change them.

  2. Start editing the KnativeKafka custom resource: 

    $ oc edit knativekafka

  3. Reference your secret and the namespace of the secret: 

    apiVersion: operator.serverless.openshift.io/v1alpha1
kind: KnativeKafka
metadata:
  namespace: knative-eventing
  name: knative-kafka
spec:
  channel:
    authSecretName: <kafka_auth_secret>
    authSecretNamespace: <kafka_auth_secret_namespace>
    bootstrapServers: <bootstrap_servers>
    enabled: true
  source:
    enabled: true
    Note

    Make sure to specify the matching port in the bootstrap server.

    For example: 

    apiVersion: operator.serverless.openshift.io/v1alpha1
kind: KnativeKafka
metadata:
  namespace: knative-eventing
  name: knative-kafka
spec:
  channel:
    authSecretName: tls-user
    authSecretNamespace: kafka
    bootstrapServers: eventing-kafka-bootstrap.kafka.svc:9094
    enabled: true
  source:
    enabled: true

Simple Authentication and Security Layer (SASL) is used by Apache Kafka for authentication. If you use SASL authentication on your cluster, users must provide credentials to Knative for communicating with the Kafka cluster; otherwise events cannot be produced or consumed.

Prerequisites

  • You have cluster or dedicated administrator permissions on OpenShift Container Platform.
  • The OpenShift Serverless Operator, Knative Eventing, and the KnativeKafka CR are installed on your OpenShift Container Platform 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 OpenShift Container Platform.
  • You have a username and password for a Kafka cluster.
  • You have chosen the SASL mechanism to use, for example, PLAIN, SCRAM-SHA-256, or SCRAM-SHA-512.
  • If TLS is enabled, you also need the ca.crt certificate file for the Kafka cluster.
  • Install the OpenShift CLI (oc).

Procedure

  1. Create the certificate files as secrets in your chosen namespace: 

    $ oc create secret -n <namespace> generic <kafka_auth_secret> \
  --from-literal=protocol="SASL_SSL"
  --from-literal=sasl.mechanism="SCRAM-SHA-512" \
  --from-file=ca.crt=caroot.pem \
  --from-literal=password="SecretPassword" \
  --from-literal=user="my-sasl-user"

    • Use the key names protocol, sasl.mechanism, ca.crt, password, and user. Do not change them.

      Note

      The ca.crt key is optional if the Kafka cluster uses a certificate signed by a public CA whose certificate is already in the system truststore.

  2. Start editing the KnativeKafka custom resource: 

    $ oc edit knativekafka

  3. Reference your secret and the namespace of the secret: 

    apiVersion: operator.serverless.openshift.io/v1alpha1
kind: KnativeKafka
metadata:
  namespace: knative-eventing
  name: knative-kafka
spec:
  channel:
    authSecretName: <kafka_auth_secret>
    authSecretNamespace: <kafka_auth_secret_namespace>
    bootstrapServers: <bootstrap_servers>
    enabled: true
  source:
    enabled: true
    Note

    Make sure to specify the matching port in the bootstrap server.

    For example: 

    apiVersion: operator.serverless.openshift.io/v1alpha1
kind: KnativeKafka
metadata:
  namespace: knative-eventing
  name: knative-kafka
spec:
  channel:
    authSecretName: scram-user
    authSecretNamespace: kafka
    bootstrapServers: eventing-kafka-bootstrap.kafka.svc:9093
    enabled: true
  source:
    enabled: true
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red HatNach oben