Knative Eventing中怎么實現(xiàn)一個Registry 事件注冊機制

Knative Eventing中怎么實現(xiàn)一個Registry 事件注冊機制，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

背景

作為事件消費者，之前是無法事先知道哪些事件可以被消費，如果能通過某種方式獲得哪些 Broker 提供哪些事件,那么事件消費者就能很方便通過這些 Broker 消費事件。Registry 就是在這樣的背景下被提出的，通過 Registry 機制，消費者能針對特定的 Broker 的事件通過 Trigger 進行事件訂閱消費。

訴求

• 每個Registry 對應一個 Namespace 作為資源隔離的邊界

• Registry 中包括事件類型列表，以提供事件發(fā)現(xiàn)機制，通過事件列表，我們可以決定對哪些 Ready 的事件進行消費

• 由于事件最終需要通過 Trigger 進行訂閱，因此事件類型信息中需要包括創(chuàng)建 Trigger 所需要的信息。

實現(xiàn)

定義 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命名規(guī)范

• type：遵循CloudEvent 類型設置。

• source: 遵循 CloudEvent source設置。

• schema: 可以是JSON schema, protobuf schema等。可選項。

• description: 事件描述，可選項。

• broker: 所提供 EventType 的 Broker。

事件注冊與發(fā)現(xiàn)

1.創(chuàng)建 EventType
一般我們通過以下兩種方式創(chuàng)建 EventType 實現(xiàn)事件的注冊。
1.1通過Event 事件源實例自動注冊
基于事件源實例，通過事件源控制器創(chuàng)建 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 事件源控制器可以創(chuàng)建事件類型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控制器）創(chuàng)建事件類型時生成，需要進一步討論。

• 我們給spec.type加上了dev.knative.source.github.前綴，這個也需要進一步討論確定是否合理。

1.2手動注冊
直接通過創(chuàng)建EventType CR資源實現(xiàn)注冊，如：

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訂閱事件
最后基于事件注冊列表信息，事件消費者創(chuàng)建對應的Trigger對Registry中的EventType進行監(jiān)聽消費
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 設計的初衷主要是針對事件消費者能夠發(fā)現(xiàn)事件并進行消費，因此它的出現(xiàn)主要是讓用戶創(chuàng)建Trigger進行事件訂閱

2. 如果僅僅創(chuàng)建 Event Source 通過Sink設置 KnService 進行事件消費(沒有Trigger), 是否也可以使用Registry?
   答：Registry 的設計主要是針對 Broker/Trigger 事件處理模型， 并且我們可以發(fā)現(xiàn) EventType 中的Broker字段是必需設置的。如果沒有發(fā)送事件到Broker， 就不會創(chuàng)建EventType注冊到Registry。在實現(xiàn)方面，我們可以檢查Event Source的Sink類型是否是Broker，如果是，則對其注冊EventType。

3. 是否可以通過CloudEvents subject 字段過濾資源
   答：EventType CRD資源不會包含subject字段， 因為我們認為subject是更高級別的過濾設置。不過社區(qū)后續(xù)會通過高級過濾規(guī)則 進行實現(xiàn)。例如：

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

看完上述內(nèi)容，你們掌握Knative Eventing中怎么實現(xiàn)一個Registry 事件注冊機制的方法了嗎？如果還想學到更多技能或想了解更多相關內(nèi)容，歡迎關注億速云行業(yè)資訊頻道，感謝各位的閱讀！