如何Knative中的Build、Serving和Eventing三大核心组件

本篇文章给大家分享的是有关如何Knative中的Build、Serving 和 Eventing三大核心组件,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。

创新互联公司是一家集成都网站设计、网站制作、网站页面设计、网站优化SEO优化为一体的专业的建站公司,已为成都等多地近百家企业提供网站建设服务。追求良好的浏览体验,以探求精品塑造与理念升华,设计最适合用户的网站页面。 合作只是第一步,服务才是根本,我们始终坚持讲诚信,负责任的原则,为您进行细心、贴心、认真的服务,与众多客户在蓬勃发展的市场环境中,互促共生。

如何Knative中的Build、Serving 和 Eventing三大核心组件

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

划重点

初识 Knative:  跨平台的 Serverless 编排框架 让我们对于 Knative 有了初步了解,Knative 主要由 Build、Serving 和 Eventing 三大核心组件构成。Knative 正是依靠这三个核心组件,驱动着 Knative 这艘 Serverless 巨轮前行,本文就来分别介绍一下这三个核心组件。

如何Knative中的Build、Serving 和 Eventing三大核心组件

Build

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

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

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

    * git 代码仓库

    * 任意容器镜像

  • 支持通过 BuildTemplate 创建可重复执行构建的模板

  • 支持 K8s ServiceAccount 身份验证

典型的 Build 示意图:

如何Knative中的Build、Serving 和 Eventing三大核心组件

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

如何Knative中的Build、Serving 和 Eventing三大核心组件

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 是不可变对象,可以长期保留

资源关系图:

如何Knative中的Build、Serving 和 Eventing三大核心组件

如何Knative中的Build、Serving 和 Eventing三大核心组件

Eventing

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

  • Knative Eventing 提供的服务是松散耦合,可独立开发和部署。服务可跨平台使用(如 Kubernetes, VMs, SaaS 或者 FaaS)

  • 事件的生产者和事件的消费者是相互独立的。任何事件的生产者(事件源)可以先于事件的消费者监听之前产生事件,同样事件的消费者可以先于事件产生之前监听事件

  • 支持第三方的服务对接该 Eventing 系统

  • 确保跨服务的互操作性

事件处理示意图:

如何Knative中的Build、Serving 和 Eventing三大核心组件

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

以上就是如何Knative中的Build、Serving 和 Eventing三大核心组件,小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注创新互联行业资讯频道。


文章题目:如何Knative中的Build、Serving和Eventing三大核心组件
本文地址:http://azwzsj.com/article/gidcjd.html