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