文档章节

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

阿里云官方博客
 阿里云官方博客
发布于 05/20 10:52
字数 1659
阅读 6
收藏 0

前言

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


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

© 著作权归作者所有

阿里云官方博客
粉丝 169
博文 1523
码字总数 3719373
作品 0
杭州
程序员
私信 提问
MySQL8.0 - 新特性 - 安全及权限相关改进 | 5月20日云栖夜读

点击订阅云栖夜读日刊,专业的技术干货,不容错过! 阿里专家原创好文 1.MySQL8.0 - 新特性 - 安全及权限相关改进 本文讲述:MySQL8.0里引入了不少关于权限的改动,从这些改动可以看出来,权限...

yq传送门
05/20
0
0
《knative官方文档》翻译邀请

knative 是谷歌开源的 serverless 架构方案,旨在提供一套简单易用的 serverless 解决方案。knative框架非常新,2018年7月才对外发布第一个版本,最近也才更新几个版本。有兴趣了解的同学可以...

方 腾飞
01/05
0
0
Knative:重新定义 Serverless | GIAC 实录

Knative 是Google 发起的 Serverless 项目,希望通过提供一套简单易用的 Serverless 开源方案,将 Serverless 标准化。 本文根据敖小剑在 2018 年上海 GIAC 演讲内容整理,文末有PPT获取地址...

s花苞酱
01/02
0
0
基于 Kubernetes 与 Istio 的 Serverless 架构方案 - Knative

Knative(发音为 kay-nay-tiv)是谷歌开源的一套 Serverless 架构方案,它扩展了 Kubernetes,提供了一组中间件,提高了构建可在本地、云和第三方数据中心等地方运行的现代化、以源为中心且基...

匿名
2018/12/12
0
0
Knative-开源的Serverless架构方案

Knative(发音为 kay-nay-tiv)是谷歌开源的一套 Serverless 架构方案,它扩展了 Kubernetes,提供了一组中间件,提高了构建可在本地、云和第三方数据中心等地方运行的现代化、以源为中心且基...

openthings
05/13
0
0

没有更多内容

加载失败,请刷新页面

加载更多

使用druid连接池的超时回收机制排查连接泄露问题

在工程中使用了druid连接池,运行一段时间后系统出现异常: Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is......

xiaomin0322
20分钟前
5
0
一.Android省电开发之性能优化

电量优化 Android应用开发中的网络、定位、传感器等都是比较耗电的特性,我们应该正确使用API来有效降低应用的耗电量。 1.BroadcastReceiver: 在代码实现中需要尽量避免无用操作代码的执行,...

天王盖地虎626
27分钟前
2
0
大数据安全 Ranger

简介 Apache Ranger提供一个集中式安全管理框架, 并解决授权和审计。它可以对Hadoop生态的组件如HDFS、YARN、Hive、HBase等进行细粒度的数据访问控制。通过Ranger统一的管理控制台界面,管理...

ericSM
29分钟前
4
0
一个媲美淘宝大秒杀系统的高性能架构设计思路

小编有话说:本文为纯干货技术文章,建议先转发、收藏再观看。 导论 曾经被问过好多次怎样实现秒杀系统的问题。昨天又在技术交流群被问到了。因此这里把我设想的实现秒杀系统的架构设计分享出...

老道士
30分钟前
6
0
[ESXi 6.5] 设置ESXi宿主机开机自动启动虚拟机

在百度上面找了一圈都是讲ESXi6.0之前的版本,在VMware vSphere Client上开启。 1、选择host主机——>右侧选择“配置”页签——>选择“虚拟机启动/关机” 2、点击右侧“属性”——>勾选“允许...

大道无形
35分钟前
1
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部