Knative Eventing 中如何實現 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，通常可能涉及到有以下問題：

1. Registry 是對 Trigger 訂閱事件，是否包括 Event Source 事件源的處理？
   答：Registry 設計的初衷主要是針對事件消費者可以發現事件並進行消費，所以它的出現主要是讓用戶建立Trigger進行事件訂閱
2. 若是僅僅建立 Event Source 經過Sink設置 KnService 進行事件消費(沒有Trigger), 是否也能夠使用Registry?
   答：Registry 的設計主要是針對 Broker/Trigger 事件處理模型， 而且咱們能夠發現 EventType 中的Broker字段是必需設置的。若是沒有發送事件到Broker， 就不會建立EventType註冊到Registry。在實現方面，咱們能夠檢查Event Source的Sink類型是不是Broker，若是是，則對其註冊EventType。
3. 是否能夠經過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

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。