html制作网站,推广最有效的办法,关于做网站的前言,在线制图网页版背景
作为事件消费者#xff0c;之前是无法事先知道哪些事件可以被消费#xff0c;如果能通过某种方式获得哪些 Broker 提供哪些事件,那么事件消费者就能很方便通过这些 Broker 消费事件。Registry 就是在这样的背景下被提出的#xff0c;通过 Registry 机制#xff0c;消…背景
作为事件消费者之前是无法事先知道哪些事件可以被消费如果能通过某种方式获得哪些 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.pullrequestnamespace: default
spec:type: com.github.pull_requestsource: github.comschema: //github.com/schemas/pull_requestdescription: GitHub pull requestbroker: 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-samplenamespace: default
spec:eventTypes:- push- pull_requestownerAndRepository: my-other-user/my-other-repoaccessToken:secretKeyRef:name: github-secretkey: accessTokensecretToken:secretKeyRef:name: github-secretkey: secretTokensink:apiVersion: eventing.knative.dev/v1alpha1kind: Brokername: 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: defaultowner: # Owned by github-source-sample
spec:type: dev.knative.source.github.pushsource: github.combroker: default
---
apiVersion: eventing.knative.dev/v1alpha1
kind: EventType
metadata:generateName: dev.knative.source.github.pullrequest-namespace: defaultowner: # Owned by github-source-sample
spec:type: dev.knative.source.github.pull_requestsource: github.combroker: default
这里有两点需要注意
通过自动生成默认名称避免名称冲突。对于是否应该在代码在本例中是GithubSource控制器创建事件类型时生成需要进一步讨论。我们给spec.type加上了dev.knative.source.github.前缀这个也需要进一步讨论确定是否合理。
1.2手动注册 直接通过创建EventType CR资源实现注册如
apiVersion: eventing.knative.dev/v1alpha1
kind: EventType
metadata:name: org.bitbucket.repoforknamespace: default
spec:type: org.bitbucket.repo:forksource: bitbucket.orgbroker: devdescription: 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-triggernamespace: default
spec:filter:sourceAndType:type: dev.knative.source.github.pushsource: github.comsubscriber:ref:apiVersion: serving.knative.dev/v1alpha1kind: Servicename: 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/v1alpha1kind: Servicename: knative-events-processor
原文链接 本文为云栖社区原创内容未经允许不得转载。
