Knative Eventing 0.6 版本新特性有哪些呢

本篇文章為大家展示了Knative Eventing 0.6 版本新特性有哪些呢，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

Knative Eventing 0.6 版本已經正式發布。相比于0.5版本，此次發布包含了一些重要特性及更新。針對這些新特性以及更新，我們如何快速、精準的定位主要技術點。

前言

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

上述內容就是Knative Eventing 0.6 版本新特性有哪些呢，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。