Knative Eventing是一个旨在满足云原生开发的常见需求的系统，并提供可组合的原语以启用后期绑定事件源和事件使用者。

设计概述

Knative Eventing是围绕以下目标设计的：

1. 原始事件服务是松散耦合的。这些服务可以在各种平台上（例如Kubernetes，VM，SaaS或FaaS）独立开发和部署。
2. 事件生产者和事件消费者是独立的。任何生产者（或源）都可以在有活动的事件使用者监听之前生成事件。在有生产者创建事件之前，任何事件消费者都可以对事件或事件类别表示兴趣。
3. 可以将其他服务连接到Eventing系统。这些服务可以执行以下功能：
   1. 创建新的应用程序而无需修改事件生产者或事件使用者。
   2. 从生产者那里选择事件的特定子集并将其作为目标。
4. 确保跨服务的互操作性。 Knative Eventing与由CNCF Serverless WG开发的CloudEvents规范一致。

事件消费者

为了能够交付到多种类型的服务，Knative Eventing定义了两个通用接口，可以由多个Kubernetes资源实现：

1. 可寻址对象能够接收和确认通过HTTP发送到其status.address.url字段中定义的地址的事件。作为一种特殊情况，核心的Kubernetes Service对象还实现了Addressable接口。
2. 可调用对象能够接收通过HTTP传递的事件并转换该事件，从而在HTTP响应中返回0或1个新事件。可以以与处理来自外部事件源的事件相同的方式来进一步处理这些返回的事件。

事件经纪人和触发器

从v0.5开始，Knative Eventing定义了Broker和Trigger对象，使过滤事件更加容易。

代理提供了一系列事件，可以通过属性选择事件。它接收事件并将其转发给由一个或多个匹配触发器定义的订户。

触发器描述了事件属性的过滤器，应将其传递给可寻址对象。您可以根据需要创建任意数量的触发器。

事件注册表

从v0.6开始，Knative Eventing定义了一个EventType对象，以使消费者更容易发现可以从不同的Broker消费的事件类型。

注册表包含事件类型的集合。注册表中存储的事件类型包含（全部）必需的信息，供消费者创建触发器而不使用某些其他带外机制。

若要了解如何使用注册表，请参阅事件注册表文档。

事件频道和订阅

Knative Eventing还定义了事件转发和持久层，称为Channel。每个通道都是一个单独的Kubernetes自定义资源。使用订阅将事件传递到服务或转发到其他渠道（可能是其他类型）。这使群集中的消息传递可以根据需求而变化，因此某些事件可能由内存中的实现处理，而其他事件则可以使用Apache Kafka或NATS Streaming持久化。

请参阅渠道实施清单。

更高级别的事件构造

在某些情况下，您可能希望一起使用一组协作功能，对于这些用例，Knative Eventing提供了两个附加资源：

1. 序列提供了一种定义功能的有序列表的方法。
2. 并行提供了一种定义事件分支列表的方法。

未来的设计目标

下一个Eventing版本的重点是使事件源的易于实现。源使用Kubernetes Custom Resources管理来自外部系统的事件的注册和传递。在Eventing工作组中了解有关Eventing开发的更多信息。

安装

目前，Knative Eventing要求安装的Istio版本> = 1.0或Gloo版本> = 0.18.16的Knative Serving。按照说明在您选择的平台上进行安装。

架构

事件基础结构目前支持两种形式的事件传递：

1. 从源直接传递到单个服务（可寻址端点，包括Knative服务或核心Kubernetes服务）。在这种情况下，如果目标服务不可用，则源负责重试或排队事件。
2. 使用渠道和订阅从源或服务响应向多个端点进行扇出交付。在这种情况下，通道实现可确保将消息传递到请求的目标，并且如果目标服务不可用，则应缓冲事件。

实际的消息转发是由多个数据平面组件实现的，这些组件提供可观察性，持久性以及不同消息传递协议之间的转换。

来源

每个源都是一个单独的Kubernetes自定义资源。这允许每种类型的Source定义实例化Source所需的参数和参数。 Knative Eventing在sources.eventing.knative.dev API组中定义了以下Sources。以下类型以golang格式声明，但在YAML中可以表示为简单列表等。所有源都应属于源类别，因此您可以使用kubectl get源列出所有现有源。当前实现的源描述如下。

除了核心资源（如下所述）外，您还可以安装其他资源。

如果您需要可用的Source实现中未涵盖的Source，则提供有关编写自己的Source的教程。

如果您的代码需要将事件作为其业务逻辑的一部分发送，并且不适合源模型，请考虑将事件直接馈送给Broker。

KubernetesEventSource

每当创建或更新Kubernetes事件时，KubernetesEventSource都会触发一个新事件。

规格字段：

• namespace：string要监视事件的名称空间。
• serviceAccountname：string用于连接到Kubernetes apiserver的ServiceAccount的名称。
• sink：ObjectReference对应该接收事件的对象的引用。

请参阅Kubernetes事件源示例。

GitHub源

GitHubSource为选定的GitHub事件类型触发一个新事件。

规格字段：

• ownerAndRepository：string从中接收事件的GitHub所有者/组织和存储库。该存储库可以保留下来以接收来自整个组织的事件。
• eventTypes：[]字符串“ Webhook事件名称”格式的事件类型列表（lower_case）。
• accessToken.secretKeyRef：包含用于配置GitHub Webhook的GitHub访问令牌的SecretKeySelector。必须设置此之一或secretToken。
• secretToken.secretKeyRef：SecretKeySelector，其中包含用于配置GitHub Webhook的GitHub秘密令牌。必须设置其中之一或accessToken。
• serviceAccountName：string用来运行容器的ServiceAccount的名称。
• sink：ObjectReference对应该接收事件的对象的引用。
• githubAPIURL：字符串可选字段，用于指定API请求的基本URL。如果未指定，则默认为公共GitHub API，但可以将其设置为要与GitHub Enterprise一起使用的域端点，例如https://github.mycompany.com/api/v3/。应始终在该基本URL后面加上斜杠。

参见GitHub Source示例。

GcpPubSubSource

每次在Google Cloud Platform PubSub主题上发布消息时，GcpPubSubSource都会触发一个新事件。

规格字段：

• googleCloudProject：字符串拥有该主题的GCP项目ID。
• topic：字符串PubSub主题的名称。
• serviceAccountName：字符串用于访问gcpCredsSecret的ServiceAccount的名称。
• gcpCredsSecret：ObjectReference对Secret的引用，其中包含用于与PubSub对话的GCP刷新令牌。
• sink：ObjectReference对应该接收事件的对象的引用。

请参阅GCP PubSub来源示例。

AwsSqsSource

每次在AWS SQS主题上发布事件时，AwsSqsSource都会触发一个新事件。

规格字段：

• queueURL：从中提取事件的SQS队列的URL。
• awsCredsSecret：用于轮询AWS SQS队列的凭证。
• sink：ObjectReference对应该接收事件的对象的引用。
• serviceAccountName：字符串用于访问awsCredsSecret的ServiceAccount的名称。

ContainerSource

ContainerSource将实例化一个容器映像，该映像可以生成事件，直到ContainerSource被删除。例如，可以使用它来轮询FTP服务器上的新文件，或在设定的时间间隔内生成事件。

规格字段：

• image（必填）：字符串要运行的容器的docker镜像。
• args：[] string命令行参数。如果未提供--sink标志，则将添加一个并用接收器对象的DNS地址填充。
• env：map [string] string要在容器中设置的环境变量。
• serviceAccountName：string用来运行容器的ServiceAccount的名称。
• sink：ObjectReference对应该接收事件的对象的引用。

•  

CronJobSource

CronJobSource根据给定的Cron时间表触发事件。

规格字段：

• schedule（必填）：字符串Cron格式的字符串，例如0 * * * *或@hourly。
• data：字符串发送到下游接收器的可选数据。
• serviceAccountName：string用来运行容器的ServiceAccount的名称。
• sink：ObjectReference对应该接收事件的对象的引用。

请参阅Cronjob源示例。

Kafka资

KafkaSource从Apache Kafka集群读取事件，并将事件传递给Knative Serving应用程序，以便可以使用它们。

规格字段：

• ConsumerGroup：字符串Kafka消费者组的名称。
• bootstrapServers：字符串用逗号分隔的Kafka Broker主机名：端口对列表。
• topic：字符串，用于吸收消息的Kafka主题的名称。
• net：可选的网络配置。
• sasl：可选的SASL身份验证配置。
• enable：布尔值如果为true，则使用SASL进行身份验证。
• user.secretKeyRef：包含要使用的SASL用户名的SecretKeySelector。
• password.secretKeyRef：包含要使用的SASL密码的SecretKeySelector。
• tls：可选的TLS配置。
• enable：布尔值如果为true，则在连接时使用TLS。
• cert.secretKeyRef：包含要使用的客户端证书的SecretKeySelector。
• key.secretKeyRef：包含要使用的客户端密钥的SecretKeySelector。
• caCert.secretKeyRef：包含要验证服务器证书时使用的服务器CA证书的SecretKeySelector。

参见Kafka Source示例。

CamelSource

CamelSource是事件源，可以代表提供用户端并允许将事件发布到可寻址端点的任何现有Apache Camel组件。每个Camel端点都具有URI的形式，其中方案是要使用的组件的ID。

CamelSource要求将Camel-K安装到当前名称空间中。

规格字段：

• 来源：有关应创建的骆驼来源类型的信息。
• component：默认类型的源，可通过配置单个Camel组件来创建EventSource。
• uri：字符串包含应用于将事件推送到目标接收器的骆驼URI。
• 属性：键/值映射包含Camel全局选项或特定于组件的配置。每个现有的Apache Camel组件的文档中都提供了选项。
• serviceAccountName：字符串，可用于运行源容器的可选服务帐户。
• image：字符串（可选）用于源pod的可选基本图像，主要用于开发目的。

参见CamelSource示例

 

原文：https://knative.dev/docs/eventing/

本文：

讨论：请加入知识星球【首席架构师圈】或者微信圈子【首席架构师圈】