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.
InMemoryChannel
and KafkaChannel
channel implementations can be used with OpenShift Serverless for development use.
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.
Apache Kafka on OpenShift Serverless 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 default-ch-webhook
config map can be used to specify the default channel implementation for the cluster or for one or more namespaces.
You can make changes to the knative-eventing
namespace config maps, including the default-ch-webhook
config map, by using the OpenShift Serverless Operator to propagate changes.
To do this, you must modify the KnativeEventing
custom resource.
You have cluster administrator permissions on OpenShift Container Platform.
You have installed the OpenShift Serverless Operator and Knative Eventing on your cluster.
Modify the KnativeEventing
custom resource to add configuration details for the default-ch-webhook
config map:
apiVersion: operator.knative.dev/v1alpha1
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 | The default-ch-webhook config map can be used 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 . |
Configuring a namespace-specific default overrides any cluster-wide settings. |
Developers can create channels by instantiating a supported Channel
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 |
The channel controller then creates the backing channel instance based on the spec.channelTemplate
configuration.
When this mechanism is used with the example above, two objects are created: a generic backing channel and an InMemoryChannel
channel.
If you are using a different default channel implementation, for example, Apache Kafka, a generic backing channel and KafkaChannel
channel are 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.
You can create a channel with the cluster default configuration by using the OpenShift Container Platform web console.
To create channels using the Developer perspective ensure that:
The OpenShift Serverless Operator and Knative Eventing are installed on your OpenShift Container Platform cluster.
You have logged in to the web console.
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.
In the Developer perspective, navigate to +Add → Channel.
Select the type of Channel
object that you want to create from the Type drop-down.
Currently only InMemoryChannel type |
Click Create.
Confirm that the channel now exists by navigating to the Topology page.
You can create a channel with the cluster default configuration by using the kn
CLI.
To create channels using the kn
CLI, ensure that:
The OpenShift Serverless Operator and Knative Eventing are installed on your OpenShift Container Platform cluster.
You have installed the 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.
Create a channel:
$ kn channel create <channel_name> --type <channel_type>
The channel type is optional, but where specified, must be given in the format Group:Version:Kind
.
For example, you can create an InMemoryChannel
object:
$ kn channel create mychannel --type messaging.knative.dev:v1:InMemoryChannel
Channel 'mychannel' created in namespace 'default'.
To confirm that the channel now exists, list the existing channels and inspect the output:
$ kn channel list
kn channel list
NAME TYPE URL AGE READY REASON
mychannel InMemoryChannel http://mychannel-kn-channel.default.svc.cluster.local 93s True
You can create a channel by using YAML with the cluster default configuration.
OpenShift Serverless Operator and Knative Eventing 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.
To create a Channel
object:
Create a YAML file and copy the following sample code into it:
apiVersion: messaging.knative.dev/v1
kind: Channel
metadata:
name: example-channel
namespace: default
Apply the YAML file:
$ oc apply -f <filename>
You can create a Kafka channel by using YAML to create the KafkaChannel
object.
The OpenShift Serverless Operator, Knative Eventing, and the KnativeKafka
custom resource 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.
Create a YAML file and copy the following sample code into it:
apiVersion: messaging.knative.dev/v1beta1
kind: KafkaChannel
metadata:
name: example-channel
namespace: default
spec:
numPartitions: 3
replicationFactor: 1
Apply the YAML file:
$ oc apply -f <filename>
Connecting a channel to an event source allows the channel to receive events from that source. These events can then be forwarded to an event sink by using subscriptions.
You can create multiple event source types in OpenShift Container Platform that can be connected to channels.
To connect an event source to a channel using the Developer perspective, ensure that:
The OpenShift Serverless Operator, Knative Serving, and Knative Eventing are installed on your OpenShift Container Platform cluster.
You have logged in to the web console.
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 created a channel by following the documentation on Creating a channel using OpenShift Container Platform web console.
Create an event source of any type, by following the documentation on Getting started with event sources.
In the Developer perspective, navigate to Event Sources.
In the Sink section of the Event Sources form view, select Resource. Then use the drop-down to select your channel.
Click Create.
You can verify that the event source was created and is connected to the sink by viewing the Topology page.
In the Developer perspective, navigate to Topology.
View the event source and click on the connected channel to see the channel details in the side panel.
You can delete a channel with the cluster default configuration by using the kn
CLI.
Delete a channel:
$ kn channel delete <channel_name>
After you have created a channel, see Using subscriptions for information about creating and using subscriptions for event delivery.