全面剖析 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 会逐渐退出历史。

原文连接 本文为云栖社区原创内容，未经容许不得转载。