为什么80%的码农都做不了架构师?>>>
作者| 阿里云智能事业群高级开发工程师 元毅
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 示意图:
虽然目前 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 是不可变对象,可以长期保留
资源关系图:
Eventing
Knative Eventing 旨在满足云原生开发中通用需求, 以提供可组合的方式绑定事件源和事件消费者。其设计目标:
- Knative Eventing 提供的服务是松散耦合,可独立开发和部署。服务可跨平台使用(如 Kubernetes, VMs, SaaS 或者 FaaS)
- 事件的生产者和事件的消费者是相互独立的。任何事件的生产者(事件源)可以先于事件的消费者监听之前产生事件,同样事件的消费者可以先于事件产生之前监听事件
- 支持第三方的服务对接该 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 呈现给我们的标准 Serverless 编排框架。
原文链接
本文为云栖社区原创内容,未经允许不得转载。