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

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 编排框架。