文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载Channel 是 Knative Eventing 中承担事件转发与持久化职责的核心抽象它作为 Kubernetes 自定义资源Custom Resource通过 Subscription 将收到的 CloudEvent 扇出fan-out到多个 Sink。本文基于官方文档与仓库源码系统讲解 Channel 的类型体系、default-ch-webhook默认配置机制、泛型 Channel 的创建原理以及 Subscription 的完整生命周期管理创建、查看、更新、删除帮助你在实际集群中构建可靠的事件投递链路。什么是 Channel事件转发与持久化层Knative Eventing 是一套 API 集合用于构建事件驱动架构事件生产者Sources产生事件事件消费者Sinks接收事件组件之间通过标准 HTTP POST 请求传递符合 [CloudEvents 规范]的事件详见 about-eventing.md。在这一体系中Channel 扮演着中间枢纽的角色。根据 Channels 概述文档 的定义Channels are Kubernetes custom resources that define a single event forwarding and persistence layer.Channel 本质上是一个 Kubernetes 自定义资源它定义了一个单一的事件转发与持久化层核心能力包括事件收容接收来自一个或多个事件源Sources发送的 CloudEvent扇出分发通过 Subscription 将收到的同一批事件复制、分发到多个目的地Sinks持久化由具体的 Channel 实现决定事件是否落地存储例如 Kafka 主题、内存缓存、Pub/Sub 等。Sink 的典型例子包括Broker和Knative Service。也就是说一条完整的事件链路通常是Source → Channel → Subscription → SinkBroker / Knative Service / 其他 Channel上图中的工作流展示了这种一对多扇出语义Source 1和Source 2产生事件后统一汇入 ChannelChannel 将事件转发给两个 Subscription再由每个 Subscription 各自将事件送达对应的 Sink。Knative Eventing 的组件是松散耦合的——生产者可以在没有任何活跃消费者之前就产生事件消费者也可以在没有任何生产者之前就表达对某类事件的兴趣这为构建解耦的事件系统提供了基础。Channel 的类型体系泛型对象与具体实现两种 Channel 使用方式Knative Eventing 定义了两种 Channel 概念理解它们的区别是正确选型的前提详见 Channel types and defaults泛型 Channel 对象generic Channel object即messaging.knative.dev/v1下的Channel资源。创建时不指定具体实现由集群管理员配置的默认实现来落地。适合不在乎具体实现特性如排序、持久化希望使用管理员选定实现的场景。具体 Channel 实现Channel implementations每个实现都有自己的 CRD例如InMemoryChannel、KafkaChannel。它们各自具备不同的事件投递机制和特性。不同实现的能力差异很大典型例子如下KafkaChannel以 Apache Kafka 主题为后端支持有序消费投递保证ordered consumer delivery guarantee——实现方式是每分区阻塞消费者CloudEvent 订阅者subscriber成功响应后才投递该分区的下一条消息从而保证同一分区内消息按序送达。InMemoryChannel纯内存实现零配置、适合开发调试但不适合生产环境。NatssChannel以 NATS Streaming 为后端。自定义 Channel 实现的投递机制各异可能是内存型也可能是 Broker 型。Broker 型实现的例子包括KafkaBroker与GCP Pub/Sub Broker。默认实现InMemoryChannelKnative 默认提供InMemoryChannel作为默认 Channel 实现。对于不希望配置特定实现类型如 Apache Kafka 或 NATSS Channels的开发者这一默认实现足够支撑开发和原型验证。可用 Channel 实现一览仓库通过 channels-crds.md 维护一份非穷尽的可用 Channel 实现清单列在其中不代表官方背书或任何支持级别的承诺NameStatusMaintainerDescriptionInMemoryChannelStableKnativeIn-memory channels are a best effort Channel. They should NOT be used in Production. They are useful for development.KafkaChannelBetaKnativeChannels are backed by Apache Kafka topics.NatssChannelAlphaKnativeChannels are backed by NATS Streaming.从状态列可以读出当前成熟度信号InMemoryChannel 为 StableKafkaChannel 为 BetaNatssChannel 为 Alpha。清单的维护机制channels.yaml 与生成器这份清单并非手写维护而是由数据文件 生成器自动产出的数据源channels.yaml 中以结构化 YAML 记录每个实现的name、url、status、maintainer、description模板ReadmeTemplate.gomd 是 Gotext/template模板遍历Channels列表渲染表格生成器main.go 按channels.yaml → 模板 → channels-crds.md的流程生成文档。从源码看main.go生成器通过三个命令行参数控制输入输出默认值分别为-yaml指向eventing/channels/channels.yaml、-template指向模板文件、-md指向输出的channels-crds.md。生成前还会对 Channel 列表按名称做稳定的字母序排序sortAlphabetically保证输出表格顺序一致。在仓库根目录下可用如下命令重新生成go run docs/versioned/eventing/channels/generator/main.go默认 Channel 类型配置default-ch-webhook 详解默认 ConfigMap 长什么样集群管理员可以通过修改knative-eventing命名空间下的default-ch-webhookConfigMap来调整默认 Channel 实现的配置。该 ConfigMap 的默认内容如下详见 Configure Channel defaultsapiVersion: v1 kind: ConfigMap metadata: name: default-ch-webhook namespace: knative-eventing labels: eventing.knative.dev/release: devel app.kubernetes.io/version: devel app.kubernetes.io/part-of: knative-eventing data: default-ch-config: | clusterDefault: apiVersion: messaging.knative.dev/v1 kind: InMemoryChannel namespaceDefaults: some-namespace: apiVersion: messaging.knative.dev/v1 kind: InMemoryChannel配置的核心在data.default-ch-config字段它包含两个子项clusterDefault决定集群全局的默认 Channel 类型namespaceDefaults按命名空间分别指定默认 Channel 类型。这段配置被 Channel 的自定义资源定义CRD消费用于创建平台相关的具体实现。集群级与命名空间级默认值的优先级默认 Channel 可以配置在集群级、命名空间级或两者同时配置。需要注意优先级规则!!! note 如果某个命名空间配置了默认 Channel 实现它将覆盖集群级配置。官方示例展示了集群默认 InMemoryChannel而example-namespace命名空间默认 KafkaChannel的组合配置来自 channel-types-defaults.mdapiVersion: v1 kind: ConfigMap metadata: name: default-ch-webhook namespace: knative-eventing data: default-ch-config: | clusterDefault: apiVersion: messaging.knative.dev/v1 kind: InMemoryChannel namespaceDefaults: example-namespace: apiVersion: messaging.knative.dev/v1beta1 kind: KafkaChannel spec: numPartitions: 2 replicationFactor: 1注意namespaceDefaults下的条目可以附带spec用于为具体实现传入定制参数——例如 KafkaChannel 的numPartitions分区数和replicationFactor副本因子。从 configuring-eventing-cr.md 的示例还可以看到更丰富的组合例如把 KafkaChannel 设为集群默认、同时为my-namespace配置带投递重试策略的 InMemoryChannelapiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: config: default-ch-webhook: default-ch-config: | clusterDefault: apiVersion: messaging.knative.dev/v1beta1 kind: KafkaChannel spec: numPartitions: 10 replicationFactor: 1 namespaceDefaults: my-namespace: apiVersion: messaging.knative.dev/v1 kind: InMemoryChannel spec: delivery: backoffDelay: PT0.5S backoffPolicy: exponential retry: 5修改默认配置的两种途径修改默认 Channel 实现设置有两种等价途径直接编辑 ConfigMap用kubectl edit修改knative-eventing命名空间下的default-ch-webhook通过 Eventing Operator CR如果集群使用 Knative Operator 管理可以在KnativeEventing自定义资源operator.knative.dev/v1beta1的spec.config.default-ch-webhook下声明同样的配置由 Operator 渲染下发。完整说明见 Configuring the Eventing Operator custom resource。如果使用基于 Channel 的 BrokerChannel-based Broker还可以通过config-br-default-channelConfigMap 单独设置 Broker 的默认 Channel 类型例如从 InMemoryChannel 切换为 KafkaChannel具体见同一文档的 Setting the default channel for the broker。配置生效时机与生产环境警告两个关键注意事项默认值只在创建时生效webhook 只会在 Channel、Sequence 等资源首次创建时应用默认配置。如果之后修改了默认配置新默认值只会作用于新建的 Channel、Broker 或 Sequence已有资源不会自动更新以采用新配置。InMemoryChannel 禁止用于生产环境它是尽力而为best effort的 Channel无持久化保障仅适用于开发场景。创建 Channel泛型对象与自动注入的 channelTemplate最小 YAML 模板与 kubectl apply开发者可以通过创建一个Channel对象实例来创建任意受支持实现类型的 Channel详见 create-default-channel.md。首先按以下模板创建 YAML 文件apiVersion: messaging.knative.dev/v1 kind: Channel metadata: name: example-channel namespace: namespace其中example-channel是要创建的 Channel 名称namespace是目标命名空间名称。然后应用该文件kubectl apply -f filename.yamlfilename为上一步创建的文件名。如果在default命名空间中创建该对象按照上一节default-ch-webhook的默认配置它会被落地为InMemoryChannel实现。webhook 自动注入 spec.channelTemplateChannel对象创建后一个**变更准入 webhookmutating admission webhook**会根据默认 Channel 实现自动设置spec.channelTemplate。创建后的对象等效于apiVersion: messaging.knative.dev/v1 kind: Channel metadata: name: example-channel namespace: namespace spec: channelTemplate: apiVersion: messaging.knative.dev/v1 kind: channel-template-kind其中example-channel是 Channel 名称namespace是命名空间channel-template-kind是根据默认 ConfigMap 解析出的实现类型例如InMemoryChannel或KafkaChannel。!!! notespec.channelTemplate属性创建后不可修改——因为它是由默认 Channel 机制设置的而不是用户设置的。底层机制代理对象与状态复制Channel 控制器Channel controller会根据spec.channelTemplate创建后端 Channel 实例。使用该机制时集群中会产生两个对象一个泛型Channel对象一个具体实现对象如InMemoryChannel。泛型对象充当具体实现对象的代理proxy它把 Subscriptions 复制到具体实现对象并把具体实现对象的状态同步回自身 status。这样用户始终面向统一的ChannelAPI 编程具体实现细节被透明封装。使用 Subscription 建立事件投递理解 Subscription 对象创建好 Channel 和 Sink 之后需要创建Subscription来启用事件投递详见 subscriptions.md。Subscription 由一个Subscription对象构成它指定了Channel事件的来源sourceSink也称 Subscriber事件的投递目标可选的 Sink 专属选项例如失败处理方式dead letter sink、回复reply目标等。使用 kn CLI 创建 Subscription在 Channel 与 Sink 之间创建 Subscription 的命令如下kn subscription create subscription-name \ --channel Group:Version:Kind:channel-name \ --sink sink-prefix:sink-name \ --sink-reply sink-prefix:sink-name \ --sink-dead-letter sink-prefix:sink-name各参数说明--channel指定待处理的 CloudEvent 来源。必须提供 Channel 名称。如果使用的不是由 Channel 资源默认支撑的 Channel就必须用Group:Version:Kind前缀指定 Channel 类型例如 Kafka 支撑的 Channel 前缀为messaging.knative.dev:v1beta1:KafkaChannel。--sink指定事件投递的目标目的地。默认情况下sink-name被解释为同命名空间下同名的 Knative Service。可以通过前缀指定 Sink 类型ksvcKnative ServicesvcKubernetes Servicechannel作为目的地的 Channel此处只能引用默认 Channel 类型brokerEventing Broker。--sink-reply可选参数指定 Sink 的回复事件reply发送到哪里命名约定与--sink一致。--sink-dead-letter可选参数指定失败时 CloudEvent 的投递位置死信 Sink命名约定与--sink一致。!!! note Sink 前缀是可选的。例如可以直接写--sink service-name省略ksvc前缀。示例创建一个名为mysubscription的 Subscription将mychannel的事件路由到名为myservice的 Knative Servicekn subscription create mysubscription \ --channel mychannel \ --sink myservice使用 YAML 创建 SubscriptionSubscription对象的标准 YAML 模板如下apiVersion: messaging.knative.dev/v1 kind: Subscription metadata: name: subscription-name # Name of the Subscription. namespace: default spec: channel: apiVersion: messaging.knative.dev/v1 kind: Channel name: channel-name # Name of the Channel that the Subscription connects to. delivery: # Optional delivery configuration settings for events. deadLetterSink: # When this is configured, events that failed to be consumed are sent to the deadLetterSink. # The event is dropped, no re-delivery of the event is attempted, and an error is logged in the system. # The deadLetterSink value must be a Destination. ref: apiVersion: serving.knative.dev/v1 kind: Service name: service-name reply: # Optional configuration settings for the reply event. # This is the event Sink that events replied from the subscriber are delivered to. ref: apiVersion: messaging.knative.dev/v1 kind: InMemoryChannel name: service-name subscriber: # Required configuration settings for the Subscriber. This is the event Sink that events are delivered to from the Channel. ref: apiVersion: serving.knative.dev/v1 kind: Service name: service-name关键字段语义spec.channelSubscription 连接的 Channel 引用spec.subscriber必填订阅者Subscriber即从 Channel 接收事件的事件 Sinkspec.reply可选订阅者回复事件的投递目标spec.delivery.deadLetterSink可选消费失败事件的处理目标——配置后消费失败的事件会被发送到死信 Sink事件被丢弃、不再重投并记录系统错误日志其值必须是 Destination 类型。应用方式与 Channel 相同kubectl apply -f filename.yaml管理 Subscription 的日常操作列出 Subscription使用knCLI 可以列出全部现有 Subscription# 列出所有 Subscription kn subscription list# 以 YAML 格式列出 kn subscription list -o yaml描述 Subscription查看单个 Subscription 的详细信息kn subscription describe subscription-name示例kn subscription describe mysubscription预期输出Name: mysubscription Namespace: default Annotations: messaging.knative.dev/creatoruserexample.com messaging.knative.dev/lastModifieruserexample.com Age: 1h Channel: Channel:mychannel (messaging.knative.dev/v1) Subscriber: URI: http://myservice.default.svc.cluster.local Reply: Name: myreply Kind: InMemoryChannel API Version: messaging.knative.dev/v1 DeadLetterSink: Name: mydlq Kind: Service API Version: serving.knative.dev/v1 Conditions: OK TYPE AGE REASON Ready 1h AddedToChannel 1h ChannelReady 1h输出中的 Conditions 是排障的关键依据Ready表示整体就绪AddedToChannel表示 Subscription 已被加入 ChannelChannelReady表示底层 Channel 已就绪。更新 Subscription更新方式有两种使用knCLI或应用更新后的 YAML 文件。方式一kn CLIkn subscription update mysubscription \ --sink ksvc:myservice \ --sink-dead-letter ksvc:error-handler \ --sink-reply channel:reply-channel可按需更新单个参数--sink更换订阅者事件投递目标--sink-dead-letter新增或更新失败投递的死信 Sink--sink-reply更新回复事件的发送目标。!!! note 更新 Subscription 时必须提供所有想要保留的配置参数。更新命令中未指定的参数将使用默认值。方式二kubectl# 1. 导出当前 Subscription 配置 kubectl get subscription subscription-name -o yaml subscription.yaml# 2. 编辑 YAML 文件修改 spec 部分 # 3. 应用更新后的文件 kubectl apply -f subscription.yaml删除 Subscription删除方式同样有两种# 使用 kn CLI kn subscription delete subscription-name# 使用 kubectl kubectl delete subscription subscription-name进阶Channel 在事件流Flows中的角色除了直连 SinkChannel 还是 Knative Eventing事件流Flows的基石。仓库在 flows 目录 中定义了基于 CRD 的组合原语Sequence定义一组有序执行的函数列表前一个函数的输出作为下一个的输入适合流水线式处理示例见 sequence.yamlParallel定义一组分支每个分支接收同一个 CloudEvent适合并行分发场景详见 parallel.md。在这些组合原语的实现中Channel 同样承担事件中转与扇出职责——例如 Sequence 内部会创建 Channel 将上游事件依次传导。这意味着你掌握的本篇能力默认 Channel 配置、Subscription 管理可以直接复用到事件流编排中。小结与延伸阅读Channel 是 Knative Eventing 中事件转发与持久化层的统一抽象泛型Channel对象配合default-ch-webhook默认机制与变更准入 webhook让开发者无需关心具体实现即可创建事件枢纽Subscription 则负责把 Channel 与 Sink 连接起来并通过 reply、dead letter sink 等选项精细控制投递语义。配置默认类型、创建 Channel、管理 Subscription 这三步构成了事件投递链路的完整闭环。继续深入可阅读Channel types and defaults默认类型与default-ch-webhook配置的完整示例Creating a Channel using cluster or namespace defaults泛型 Channel 创建与channelTemplate注入机制SubscriptionsSubscription 完整操作手册Available Channels list当前可用 Channel 实现清单Configure Channel defaultsdefault-ch-webhook默认配置的权威说明Configuring the Eventing Operator custom resource通过 Operator CR 配置默认 ChannelKnative Eventing 概述Eventing 整体架构与安装入口安装文档。赞分享文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载相关推荐Knative Eventing 中 Apache Kafka Channel 的安装、配置与实战指南Knative Eventing 中 Apache Kafka Channel 的安装、配置与实战指南 本篇技术指南以 code samples/eventin文档教程云原生react-native-exception-handler源码解析如何优雅拦截React Native崩溃react native exception handler源码解析如何优雅拦截React Native崩溃 react native exception hTypeGraphQL 订阅Subscription实战指南Subscription 装饰器、PubSub 事件触发与自定义订阅源TypeGraphQL 订阅Subscription实战指南Subscription 装饰器、PubSub 事件触发与自定义订阅源 GraphQL 的后端GraphQLAPI设计创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考