通道和订阅 - 通道 | 事件 | Red Hat OpenShift Serverless 1.34

通道实现类型

通道是自定义资源，定义了单一的事件转发和持久层。事件从事件源或生产者发送到通道后，可以使用订阅将这些事件发送到多个 Knative 服务或其他接收器。

您可以通过实例化受支持的Channel对象来创建通道，并通过修改Subscription对象的delivery规范来配置重新交付尝试。

创建Channel对象后，变异接收 Webhook 会根据默认通道实现为Channel对象添加一组spec.channelTemplate属性。例如，对于InMemoryChannel默认实现，Channel对象如下所示

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

然后，通道控制器根据spec.channelTemplate配置创建后端通道实例。

创建后无法更改spec.channelTemplate属性，因为它们是由默认通道机制设置的，而不是由用户设置的。

当此机制与前面的示例一起使用时，将创建两个对象：一个通用的后端通道和一个InMemoryChannel通道。如果您使用的是不同的默认通道实现，则InMemoryChannel将被特定于您的实现的通道替换。例如，使用 Apache Kafka 的 Knative 代理，将创建KafkaChannel通道。

后端通道充当代理，它将它的订阅复制到用户创建的通道对象，并设置用户创建的通道对象的 status 来反映后端通道的状态。

通道实现类型

OpenShift Serverless 支持InMemoryChannel和KafkaChannel通道实现。由于InMemoryChannel通道的局限性，建议仅将其用于开发用途。您可以将KafkaChannel通道用于生产环境。

以下是InMemoryChannel类型通道的限制：

没有事件持久性。如果 Pod 宕机，则该 Pod 上的事件将丢失。
InMemoryChannel通道不实现事件排序，因此同时在通道中接收到的两个事件可以以任何顺序传递给订阅者。
如果订阅者拒绝事件，则默认情况下不会进行重新传递尝试。您可以通过修改Subscription对象的delivery规范来配置重新传递尝试。