前言

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 來解決事件路由的問題：

在創建 Channel 時，通過配置 Istio Virtual Service 將事件路由到對應 provisioner。

在創建 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 會逐漸退出歷史。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的全面剖析 Knative Eventing 0.6 版本新特性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。