Knative Eventing 中如何实现 Registry 事件注册机制
摘要: 在最新的 Knative Eventing 0.6 版本中新增了 Registry 特性, 为什么要增加这个特性, 该特性是如何实现的。针对这些问题,希望通过本篇文章给出答案。
背景
作为事件消费者,之前是无法事先知道哪些事件可以被消费,如果能通过某种方式获得哪些 Broker 提供哪些事件,那么事件消费者就能很方便通过这些 Broker 消费事件。Registry 就是在这样的背景下被提出的,通过 Registry 机制,消费者能针对特定的 Broker 的事件通过 Trigger 进行事件订阅消费。这里需要说明一下,Registry 设计与实现目前是针对 Broker/Trigger 事件处理模型。
诉求
- 每个Registry 对应一个 Namespace 作为资源隔离的边界
- Registry 中包括事件类型列表,以提供事件发现机制,通过事件列表,我们可以决定对哪些 Ready 的事件进行消费
- 由于事件最终需要通过 Trigger 进行订阅,因此事件类型信息中需要包括创建 Trigger 所需要的信息。
实现
定义 EventType CRD 资源
定义 EventType 类型的CRD资源,示例yaml:
apiVersion: eventing.knative.dev/v1alpha1 kind: EventType metadata: name: com.github.pullrequest namespace: default spec: type: com.github.pull_request source: github.com schema: //github.com/schemas/pull_request description: "GitHub pull request" broker: default
- name: 设置时需要符合k8s命名规范
- type:遵循CloudEvent 类型设置。
- source: 遵循 CloudEvent source设置。
- schema: 可以是JSON schema, protobuf schema等。可选项。
- description: 事件描述,可选项。
- broker: 所提供 EventType 的 Broker。
事件注册与发现
1.创建 EventType
一般我们通过以下两种方式创建 EventType 实现事件的注册。
1.1通过Event 事件源实例自动注册
基于事件源实例,通过事件源控制器创建 EventType 进行注册:
apiVersion: sources.eventing.knative.dev/v1alpha1 kind: GitHubSource metadata: name: github-source-sample namespace: default spec: eventTypes: - push - pull_request ownerAndRepository: my-other-user/my-other-repo accessToken: secretKeyRef: name: github-secret key: accessToken secretToken: secretKeyRef: name: github-secret key: secretToken sink: apiVersion: eventing.knative.dev/v1alpha1 kind: Broker name: default
通过运行上面的yaml信息,通过GitHubSource 事件源控制器可以创建事件类型dev.knative.source.github.push以及事件类型dev.knative.source.github.pull_request这两个EventType进行注册,其中source为github.com以及名称为default的Broker。具体如下:
apiVersion: eventing.knative.dev/v1alpha1 kind: EventType metadata: generateName: dev.knative.source.github.push- namespace: default owner: # Owned by github-source-sample spec: type: dev.knative.source.github.push source: github.com broker: default --- apiVersion: eventing.knative.dev/v1alpha1 kind: EventType metadata: generateName: dev.knative.source.github.pullrequest- namespace: default owner: # Owned by github-source-sample spec: type: dev.knative.source.github.pull_request source: github.com broker: default
这里有两点需要注意:
- 通过自动生成默认名称,避免名称冲突。对于是否应该在代码(在本例中是GithubSource控制器)创建事件类型时生成,需要进一步讨论。
- 我们给
spec.type
加上了dev.knative.source.github.
前缀,这个也需要进一步讨论确定是否合理。
1.2手动注册
直接通过创建EventType CR资源实现注册,如:
apiVersion: eventing.knative.dev/v1alpha1 kind: EventType metadata: name: org.bitbucket.repofork namespace: default spec: type: org.bitbucket.repo:fork source: bitbucket.org broker: dev description: "BitBucket fork"
通过这种方式可以注册名称为org.bitbucket.repofork
, type 为 org.bitbucket.repo:fork
, source 为 bitbucket.org
以及属于dev
Broker 的 EventType。
2.获取 Registry 的事件注册
事件消费者可以通过如下方式获取 Registry 的事件注册列表:
$ kubectl get eventtypes -n default
NAME TYPE SOURCE SCHEMA BROKER DESCRIPTION READY REASON org.bitbucket.repofork org.bitbucket.repo:fork bitbucket.org dev BitBucket fork False BrokerIsNotReady com.github.pullrequest com.github.pull_request github.com //github.com/schemas/pull_request default GitHub pull request True dev.knative.source.github.push-34cnb dev.knative.source.github.push github.com default True dev.knative.source.github.pullrequest-86jhv dev.knative.source.github.pull_request github.com default True
3.Trigger订阅事件
最后基于事件注册列表信息,事件消费者创建对应的Trigger对Registry中的EventType进行监听消费
Trigger示例:
apiVersion: eventing.knative.dev/v1alpha1 kind: Trigger metadata: name: my-service-trigger namespace: default spec: filter: sourceAndType: type: dev.knative.source.github.push source: github.com subscriber: ref: apiVersion: serving.knative.dev/v1alpha1 kind: Service name: my-service
其它
针对 Registry,一般可能涉及到有如下问题:
- Registry 是对 Trigger 订阅事件,是否包括 Event Source 事件源的处理?
答:Registry 设计的初衷主要是针对事件消费者能够发现事件并进行消费,因此它的出现主要是让用户创建Trigger进行事件订阅 - 如果仅仅创建 Event Source 通过Sink设置 KnService 进行事件消费(没有Trigger), 是否也可以使用Registry?
答:Registry 的设计主要是针对 Broker/Trigger 事件处理模型, 并且我们可以发现 EventType 中的Broker字段是必需设置的。如果没有发送事件到Broker, 就不会创建EventType注册到Registry。在实现方面,我们可以检查Event Source的Sink类型是否是Broker,如果是,则对其注册EventType。 - 是否可以通过CloudEvents
subject
字段过滤资源
答:EventType CRD资源不会包含subject
字段, 因为我们认为subject
是更高级别的过滤设置。不过社区后续会通过高级过滤规则 进行实现。例如:
apiVersion: eventing.knative.dev/v1alpha1 kind: Trigger metadata: name: only-knative spec: filter: cel: expression: ce.subject.match("/knative/*") subscriber: ref: apiVersion: serving.knative.dev/v1alpha1 kind: Service name: knative-events-processor
作者:元毅
原文链接
本文为云栖社区原创内容,未经允许不得转载。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
开发函数计算的正确姿势——tensorflow serving
前言 首先介绍下在本文出现的几个比较重要的概念: 函数计算(Function Compute): 函数计算是一个事件驱动的服务,通过函数计算,用户无需管理服务器等运行情况,只需编写代码并上传。函数计算准备计算资源,并以弹性伸缩的方式运行用户代码,而用户只需根据实际代码运行所消耗的资源进行付费。函数计算更多信息参考。 Fun: Fun 是一个用于支持 Serverless 应用部署的工具,能帮助您便捷地管理函数计算、API 网关、日志服务等资源。它通过一个资源配置文件(template.yml),协助您进行开发、构建、部署操作。Fun 的更多文档参考。 备注: 本文介绍的技巧需要 Fun 版本大于等于 2.13.0。 依赖工具 本项目是在 MacOS 下开发的,涉及到的工具是平台无关的,对于 Linux 和 Windows 桌面系统应该也同样适用。在开始本例之前请确保如下工具已经正确的安装,更新到最新版本,并进行正确的配置。 Docker Fun Fcli Fun 和 Fcli 工具依赖于 docker 来模拟本地环境。 对于 MacOS 用户可以使用homebrew进行安装: brew...
- 下一篇
Solr搜索引擎 — SolrCloud介绍和环境准备
搞定了一切的一切之后下一步就是正式使用了,但是之前介绍的都是在单台服务器上进行的部署,如果在生产环境出现了单台故障怎么办呢?提供稳定性和性能的最直观的方式就是集群,solr官方提供了cloud的集群方式 附上: 喵了个咪的博客:http://w-blog.cn Solr官网:http://lucene.apache.org/solr/ PS:8.0.0版本已经发布,本文使用此时较为稳定的7.7.1版本 一,SolrCloud介绍 SolrCloud是基于Solr和Zookeeper的分布式搜索方案。它的主要思想是使用Zookeeper作为SolrCloud集群的配置信息中心,统一管理solrcloud的配置,比如solrconfig.xml和schema.xml。 SolrCloud(solr集群)是Solr提供的分布式搜索方案,一下场景能够比较好的使用SolrCloud 当你需要大规模,容错,分布式索引和检索能力时使用SolrCloud。 当索引量很大,搜索请求并发很高时,同样需要使用SolrCloud来满足这些需求。 不过当一个系统的索引数据量少的时候是没有必要使用SolrClou...
相关文章
文章评论
共有0条评论来说两句吧...