In Simple Delivery, there is no
Channel and in Broker and Trigger
Delivery, you don't need to configure a
Channel object yourself.
However, if you're operating a Knative setup for production, you should change
Channel each namespace uses.
In Complex Delivery, you need to create
Channel corresponds to a topic in their respective implementation. For
example, if you're using Google Cloud Pub/Sub, each
Channel object correspond
to a Pub/Sub Topic.
You can see which type of
Channel is used in the namespace by querying:
$ kubectl get channel --namespace event-example NAME READY [...] AGE inmemorychannel.messaging.knative.dev/default-kne-ingress True [...] 52d inmemorychannel.messaging.knative.dev/default-kne-trigger True [...] 52d
This shows the current Channel in this namespace is
- When you label a namespace for eventing, a default Channel is provisioned for it.
- You can have multiple
Channels in a namespace, however, you'd need to configure a
Brokermanually to use the Channel of your choosing.
By default, Knative uses
InMemoryChannel implementation for every labeled
eventing namespace. This helps you get going without setting a persistent
You are recommended to change this default in a production cluster as otherwise the events would be lost when the container storing the events restart.
Changing the default Channel
You can configure other implementations to achieve persistence for the messages.
Configuring the default Channel is explained in Knative documentation.