Knative 核心概念介绍:Build、Serving 和 Eventing 三大核心组件-阿里云开发者社区

开发者社区> 阿里巴巴云原生> 正文

Knative 核心概念介绍:Build、Serving 和 Eventing 三大核心组件

简介: 作者| 阿里云智能事业群高级开发工程师 元毅 Knative 主要由 Build、Serving 和 Eventing 三大核心组件构成。Knative 正是依靠这三个核心组件,驱动着 Knative 这艘 Serverless 巨轮前行。

作者| 阿里云智能事业群高级开发工程师 元毅

Knative 主要由 Build、Serving 和 Eventing 三大核心组件构成。Knative 正是依靠这三个核心组件,驱动着 Knative 这艘 Serverless 巨轮前行。下面让我们来分别介绍一下这三个核心组件。

Build

Knative Build 是基于现有的 Kubernetes 能力之上,提供的一套标准化、可移植、可复用的容器镜像构建方式。通过在 Kubernetes 上运行复杂的构建任务,Knative Build 使你不必再单独开发和重复这些镜像构建过程, 从而通过系统化、工程化的方式,减少了镜像构建时间及成本。

Build 通过 Kubernetes 自定义资源定义(CRD)实现。 通过 Build 你可以自定义一个从运行到结束的构建流程。例如,可以使用 Knative Build 来获取、构建和打包代码。Build 具备以下功能:

  • 支持 Source 源挂载,目前支持的 Source 源包括:

    • git 代码仓库
    • 任意容器镜像
  • 支持通过 BuildTemplate 创建可重复执行构建的模板
  • 支持 K8s ServiceAccount 身份验证

典型的 Build 示意图:

3

虽然目前 Knative Build 并不提供完整的独立 CI/CD 解决方案,但它却提供了一个底层的构建模块,用户可单独使用该构建模块在大型系统中实现集成和利用。

Serving

Knative 作为 Severless 框架最终是用来提供服务的, 那么 Knative Serving 应运而生。

Knative Serving 构建于 Kubernetes 和 Istio 之上,为  Serverless 应用提供部署和服务支持。其特性如下:

  • 快速部署 Serverless 容器
  • 支持自动扩缩容和缩到 0 实例
  • 基于 Istio 组件,提供路由和网络编程
  • 支持部署快照

Knative Serving 中定义了以下 CRD 资源:

  • Service: 自动管理工作负载整个生命周期。负责创建 Route、Configuration 以及 Revision 资源。通过 Service 可以指定路由流量使用最新的 Revision 还是固定的 Revision
  • Route:负责映射网络端点到一个或多个 Revision。可以通过多种方式管理流量。包括灰度流量和重命名路由
  • Configuration: 负责保持 Deployment 的期望状态,提供了代码和配置之间清晰的分离,并遵循应用开发的 12 要素。修改一次 Configuration 产生一个 Revision
  • Revision:Revision 资源是对工作负载进行的每个修改的代码和配置的时间点快照。Revision 是不可变对象,可以长期保留

资源关系图:

4

Eventing

Knative Eventing 旨在满足云原生开发中通用需求, 以提供可组合的方式绑定事件源和事件消费者。其设计目标:

  • Knative Eventing 提供的服务是松散耦合,可独立开发和部署。服务可跨平台使用(如 Kubernetes, VMs, SaaS 或者 FaaS)
  • 事件的生产者和事件的消费者是相互独立的。任何事件的生产者(事件源)可以先于事件的消费者监听之前产生事件,同样事件的消费者可以先于事件产生之前监听事件
  • 支持第三方的服务对接该 Eventing 系统
  • 确保跨服务的互操作性

事件处理示意图:

5

如上图所示,Eventing 主要由事件源(Event Source)、事件处理(Flow)以及事件消费者(Event Consumer)三部分构成。

[]()

事件源(Event Source)

当前支持以下几种类型的事件源:

  • ApiserverSource:每次创建或更新 Kubernetes 资源时,ApiserverSource 都会触发一个新事件
  • GitHubSource:GitHub 操作时,GitHubSource 会触发一个新事件
  • GcpPubSubSource: GCP 云平台 Pub/Sub 服务会触发一个新事件
  • AwsSqsSource:Aws 云平台 SQS 服务会触发一个新事件
  • ContainerSource: ContainerSource 将实例化一个容器,通过该容器产生事件
  • CronJobSource: 通过 CronJob 产生事件
  • KafkaSource: 接收 Kafka 事件并触发一个新事件
  • CamelSource: 接收 Camel 相关组件事件并触发一个新事件

[]()

事件接收/转发(Flow)

当前 Knative 支持如下事件接收处理:

  • 直接事件接收

    通过事件源直接转发到单一事件消费者。支持直接调用 Knative Service 或者 Kubernetes Service 进行消费处理。这样的场景下,如果调用的服务不可用,事件源负责重试机制处理。
  • 通过事件通道(Channel)以及事件订阅(Subscriptions)转发事件处理

    这样的情况下,可以通过 Channel 保证事件不丢失并进行缓冲处理,通过 Subscriptions 订阅事件以满足多个消费端处理。
  • 通过 brokers 和 triggers 支持事件消费及过滤机制

从 v0.5 开始,Knative Eventing 定义 Broker 和 Trigger 对象,实现了对事件进行过滤(亦如通过 ingress 和 ingress controller 对网络流量的过滤一样)。

通过定义 Broker 创建 Channel,通过 Trigger 创建 Channel 的订阅(subscription),并产生事件过滤规则。

[]()

事件消费者(Event Consumer)

为了满足将事件发送到不同类型的服务进行消费, Knative Eventing 通过多个 k8s 资源定义了两个通用的接口:

  • Addressable 接口提供可用于事件接收和发送的 HTTP 请求地址,并通过status.address.hostname字段定义。作为一种特殊情况,Kubernetes Service 对象也可以实现 Addressable 接口
  • Callable 接口接收通过 HTTP 传递的事件并转换事件。可以按照处理来自外部事件源事件的相同方式,对这些返回的事件做进一步处理

当前 Knative 支持通过 Knative Service 或者 Kubernetes Service 进行消费事件。

另外针对事件消费者,如何事先知道哪些事件可以被消费? Knative Eventing 在最新的 0.6 版本中提供 Registry 事件注册机制, 这样事件消费者就可以事先通过 Registry 获得哪些 Broker 中的事件类型可以被消费。

[]()

总结

Knative 使用 Build 提供云原生“从源代码到容器”的镜像构建能力,通过 Serving 部署容器并提供通用的服务模型,同时以 Eventing 提供事件全局订阅、传递和管理能力,实现事件驱动。这就是 Knative 呈现给我们的标准 Serverless 编排框架。

版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里巴巴云原生
使用钉钉扫一扫加入圈子
+ 订阅

关注云原生中间件、微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生技术趋势、云原生大规模的落地实践

官方博客