This is a cache of https://docs.openshift.com/container-platform/4.3/serverless/knative_eventing/serverless-channels.html. It is a snapshot of the page at 2024-11-23T02:18:55.351+0000.
Using channels - Knative Eventing | Serverless applications | OpenShift Container Platform 4.3
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history
×

Using channels

It is possible to sink events from an event source to a Knative Eventing channel. Channels are custom resources (CRs) that define a single event-forwarding and persistence layer. After events have been sent to a channel, these events can be sent to multiple Knative services by using a subscription.

The default configuration for channel instances is defined in the default-ch-webhook configmap. However, developers can still create their own channels directly by instantiating a supported channel object.

Supported channel types

Currently, OpenShift Serverless only supports the use of InMemoryChannel type channels as part of the Knative Eventing Technology Preview.

Using the default InMemoryChannel configuration

InMemoryChannels are for development use only, and should not be used in 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 type 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. Instead, the rejected event is sent to a deadLetterSink if this sink exists, or is otherwise dropped. For more information about configuring event delivery and deadLetterSink settings for a channel, see Using subscriptions to send events from a channel to a sink.

When you install Knative Eventing, the following custom resource definition (CRD) is created automatically:

apiVersion: v1
kind: configmap
metadata:
  namespace: knative-eventing
  name: config-br-default-channel
data:
  channelTemplateSpec: |
    apiVersion: messaging.knative.dev/v1
    kind: InMemoryChannel
Creating a channel using the cluster default configuration

  • Create a generic Channel custom object.

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

    When the Channel object is created, a mutating admission webhook adds a set of spec.channelTemplate properties for the Channel object based on the default channel implementation.

    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 that spec.channelTemplate configuration. 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, two objects are created: a generic channel, and an InMemoryChannel type channel.

The generic channel acts as a proxy that copies its subscriptions to the InMemoryChannel, and sets its status to reflect the status of the backing InMemoryChannel type channel.

Because the channel in this example is created in the default namespace, the channel uses the cluster default, which is InMemoryChannel.