全面剖析 Knative Eventing 0.6 版本新特性

前言

Knative Eventing 0.6 版本已經於5月15號正式發佈。相比於0.5版本，這次發佈包含了一些重要特性及更新。針對這些新特性以及更新，咱們如何快速、精準的定位主要技術點。本篇文章針對這些進行技術剖析，但願能讓你們更好的理解這次發佈的重點內容，而且以此展望一下 Knative Eventing 後續版本的發展。
另外因爲目前 Eventing 依賴 Eventing-Sources, 關於 Eventing-Sources 0.6 主要更新也會相應的提到。

新特性

Registry

做爲事件消費者，以前是沒法事先知道哪些事件能夠被消費，若是能經過某種方式得到哪些 Broker 提供哪些事件,那麼事件消費者就能很方便經過這些 Broker 消費事件。Registry 就是在這樣的背景下被提出的，經過 Registry 機制，消費者能針對特定的 Broker 的事件經過 Trigger 進行事件訂閱消費。Registry 只是一個邏輯觀念，並不是一個具體的資源。
其實現圍繞如下幾個關鍵點：

• 以 Namespace 爲隔離邊界，每一個 Registry 對應一個 Namespace。
• 定義 EventType CRD 資源。每一個 Registry 中包括多個 EventType 資源。經過 EventType 來判斷事件是否能夠被消費。
• EventType 中須要包含 Trigger 訂閱時的必要信息。

示例以下：
$ kubectl get eventtypes -n default

NAME                                         TYPE                                    SOURCE                                              SCHEMA                                     BROKER     DESCRIPTION           READY    REASON
org.bitbucket.repofork                       org.bitbucket.repo:fork                 https://bitbucket.org/my-other-user/my-other-repo                                              dev        BitBucket fork        False    BrokerIsNotReady
com.github.pullrequest                       com.github.pull_request                 https://github.com/user/repo                        https://github.com/schemas/pull_request    default    GitHub pull request   True
dev.knative.source.github.push-34cnb         dev.knative.source.github.push          https://github.com/my-other-user/my-other-repo                                                 default                          True
dev.knative.source.github.pullrequest-86jhv  dev.knative.source.github.pull_request  https://github.com/my-other-user/my-other-repo                                                 default                          True

圍繞 Registry 事件註冊機制，CronJobSource 和 ApiServerSource 事件源會建立對應的 EventType 並註冊到 Registry 中。這裏須要注意一點目前這個特性只針對 Broker/Trigger 事件處理模型。

這裏簡單介紹一下 Eventing-Sources 組件，它用於給 Eventing 提供事件源支持，在0.5版本中提供的事件源包括：KubernetesEventSource、GitHubSource、GcpPubSubSource、AwsSqsSource、ContainerSource、CronJobSource、KafkaSource 以及 CamelSource 。
而在最新的 Eventing-Sources 0.6 版本中，CronJobSource 和 ContainerSource 已經遷移到了 Eventing 中， KubernetesEventSource 數據源也會被 Eventing 中的 ApiServerSource 所替代。

去掉 Istio 依賴

在 Eventing 0.5版本中使用了 Istio 來解決事件路由的問題：

1. 在建立 Channel 時，經過配置 Istio Virtual Service 將事件路由到對應 provisioner。
2. 在建立 Trigger 時，經過配置 Istio Virtual service 將事件路由到 Broker-Filter。

這裏其實咱們能夠經過爲每個 Channel 建立惟一ExternalName類型的 k8s service 解決 Channel 事件路由問題，而 Trigger 則直接經過 HTTP 路徑(如：http://foo-broker-filter-1da3a.default.svc.cluster.local/my-trigger)將事件路由到 Broker-Filter，而且結合社區去掉 Istio 依賴的建議(在 Serving 中已經建議不在依賴 Istio )。
所以在 Eventing 0.6版本中去掉了對 Istio 的依賴。另外若是你安裝了 Istio 的話，並不會影響 Eventing 正常工做。

事件追蹤支持

在 Eventing 中若是事件處理過程當中出現異常，咱們不能很快的定位具體的問題。針對這樣的場景，在全部的 Channel 中添加了事件追蹤支持，包括：

• Kafka Channel
• in-memory Channel
• NATSS Channel
• GCP-PubSub Channel

而且經過 config-tracing ConfigMap 配置 tracing 信息。

Metrics 支持

社區在針對 Eventing/Serving 等組件中採用不一樣的 controller 實現(例如 Eventing 中使用 controller runtime， 而 Serving 中經過 pkg/controller 方式)進行統一改造(預計在0.7版本完成)過程當中，發現 metrics 的實現方式也不一致，所以這次對全部的 controller 都添加了 metrics 統一實現，包括 Broker, Trigger, Channel, Subscription, ContainerSource, CronJobSource 以及 ApiServerSource。

新增 ApiServerSource

上面提到 KubernetesEventSource 在 Eventing-Source 0.6版本中已經去掉，新增 ApiServerSource，用於在 Eventing 中獲取 Kubernetes 中資源改變的事件源信息。

完善 ContainerSource

ContainerSource 代碼中新增了 Kubernetes 事件和條件判斷處理，便於出現問題時進行排查。

其它變動

• Trigger 經過path替換原有的host來訪問 Subscription。建立 Trigger 對象後，當前再也不須要建立 Kubernetes Service 和 Istio VirtualService 對象。若是系統中已經存在的 k8s Service 和 VirtualService 不會被主動刪除，只會在刪除 Trigger 的時候纔會被 GC 回收
• in-memory-channel provisioner 新添加了Deprecated類型的條件，計劃在0.7版本中in-memory-channel ClusterChannelProvisioner 會被移除掉
• 全部 Channel 會使用 ExternalName 類型的 Kubernetes Service 來替換 Istio VirtualService。
• Eventing 中的數據平面組件再也不強依賴 Istio sidecar 注入。

升級與兼容

對於這次的變動，如升級到 Eventing 0.6版本須要關注一下幾點：

• 因爲 in-memory-channel ClusterChannelProvisioner 計劃在0.7版本中移除掉，而且被 in-memory provisioner 取代。建議升級現有全部的 in-memory-channel 到 in-memory
• Trigger 中的BrokerExists條件如今稱爲 Broker。
• Kafka dispatcher 組件會使用 Deployment 替換原有的 StatefulSet。升級到0.6版本以後須要刪除eventing-sources/kafka-channel-dispatcher StatefulSet。
• CronJobSource 和 ContainerSource 已經做爲 Eventing 安裝的一部分，不須要經過其它方式再安裝(Eventing-Sources 0.6中已經被移除)。
• 因爲 in-memory ClusterChannelProvisioner 目前依賴config-tracing ConfigMap, 因此須要先安裝 Eventing。若是 in-memory 先安裝， 那麼 in-memory dispatcher 會啓動不了，直到 Eventing 安裝完成。
• CronJobSource 如今使用/apis/v1/namespaces//cronjobsources/做爲 CloudEvents 事件源。代替原來的/CronJob
• 若是 Eventing 升級到0.6版本, 相應的 Eventing-Sources 也須要升級到0.6版本

總結

Knative Eventing 0.6版本加強了事件處理的易用性如新增 Registy 便於事件消費，經過新增事件跟蹤機制以及 Metrics 加強了可用性，同時進一步簡化 Eventing 中的依賴處理，如去掉 Istio 依賴，而將 Eventing-Sources 中的數據源處理遷移到 Eventing 中，則進一步減小了對 Eventing-Sources 組件的依賴。

展望

咱們這裏能夠簡單展望一下，社區接下來會進一步加強 Trigger 過濾策略(支持正則表達過濾等), 而且針對目前使用同一個 Channel CRD 資源很難定位 Channel 中問題，接下來會爲每個 Channel 定義獨立 CRD 資源，這些特性計劃都會在0.7版本中推出。另外經過此次版本更新，不難看出 Eventing-Sources 會逐漸退出歷史。

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