Knative 技术概览¶

本全面概览将介绍 Knative 是什么，它解决了哪些问题，以及它的组件如何协同工作。无论您是在评估 Knative 是否适用于您的用例，还是需要背景信息来理解文档的其余部分，本节都将为您提供所需的概念基础。

什么是 Knative？¶

Knative 是一个基于 Kubernetes 的平台，它提供了一整套中间件组件，用于构建、部署和管理现代无服务器工作负载。Knative 扩展了 Kubernetes，提供了更高级别的抽象，从而简化了云原生应用程序的开发和运维。

Knative 解决的问题¶

Knative 解决了现代应用程序开发和部署中的几个关键挑战：

应用部署复杂性：传统的 Kubernetes 需要深入了解 Pod、Service、Deployment 和 Ingress 资源。这些构造提供了大量的灵活性和复杂性，而大多数应用程序并不需要。Knative 提供了更简单的抽象，可以自动处理这些细节。

无服务器运维：手动扩展、冷启动和流量路由的实现非常复杂。Knative 提供从零到数千个实例的自动扩展、智能流量路由和高效的资源利用。

事件驱动架构：构建可靠的事件驱动系统需要复杂的事件摄取、路由和传递基础设施。将事件路由和传递构建到您的应用程序中会限制您对事件传递和架构的选择；Knative 使用 CloudEvents 进行传递，并使用 Kubernetes 进行配置，在多个事件实现之间提供标准化的事件处理能力。

开发者体验：从代码到运行应用程序需要多个步骤和工具。Knative Functions 为将无状态函数构建和部署为标准容器提供了简化的标准化开发体验。无需 Kubernetes 即可在本地构建和测试，并在需要时避免管理 Dockerfile 和 Kubernetes 资源等构建细节。

平台锁定：云特定的无服务器解决方案会导致供应商锁定。Knative 运行在任何 Kubernetes 集群上，可在云提供商和本地环境之间实现可移植性。

背景知识¶

虽然您开始使用 Knative 并不需要任何特定的编程经验，但您会在此过程中掌握以下概念。Knative 会在后台管理其中很多内容，因此您可以在准备好深入学习时进行深入研究。

基础 Kubernetes 知识：对 Pod、Service 和 Deployment 的理解
容器概念：如何构建和管理容器镜像
HTTP/REST API：对 Web 服务基础知识的理解
基础 YAML：读取和编写 Kubernetes 资源定义的能力

对于事件驱动功能，熟悉： - 事件驱动模式：对生产者、消费者和消息路由的基本理解 - CloudEvents 规范：有帮助但非必需（Knative 会处理细节）

架构概览¶

Knative 由三个主要组件组成，它们协同工作以提供完整的无服务器平台：

Knative High-Level Architecture: Functions, Serving, and Eventing. Functions creates containers and defines event triggers, Serving runs containers, and Eventing routes events based on triggers.

Knative Serving：一个 HTTP 触发的自动扩展容器运行时，负责管理无状态 HTTP 服务的完整生命周期，包括部署、路由和自动扩展。

Knative Eventing：一个基于 HTTP 的 CloudEvents 异步路由层，为消耗和生成事件提供基础设施，从而实现事件生产者和消费者之间的松耦合。

Knative Functions：一个以开发人员为中心的函数框架，它利用 Serving 和 Eventing 组件，为构建和部署无状态函数提供简化的体验。

这些组件可以独立或组合使用，允许您根据需要逐步采用 Knative。

Knative Serving¶

Knative Serving 将一组对象定义为 Kubernetes 自定义资源定义 (CRD)。这些资源用于定义和控制无服务器工作负载在集群上的行为方式。

Diagram that displays how the Serving resources coordinate with each other.

主要的 Knative Serving 资源是 Service、Route、Configuration 和 Revision

Service：`service.serving.knative.dev` 资源自动管理工作负载的整个生命周期。它控制其他对象的创建，以确保您的应用程序具有路由、配置以及每次服务更新的新修订。服务可以定义为始终将流量路由到最新修订版或固定修订版。
Route：`route.serving.knative.dev` 资源将网络端点映射到一个或多个修订版。您可以通过多种方式管理流量，包括分数流量和命名路由。
Configuration：`configuration.serving.knative.dev` 资源维护部署的期望状态。它在代码和配置之间提供了清晰的分离，并遵循十二因素应用程序方法。修改配置会创建新的修订版。
Revision：`revision.serving.knative.dev` 资源是工作负载每次修改的代码和配置的时间点快照。修订版是不可变对象，可以保留到有用为止。Knative Serving 修订版可以根据传入流量自动扩缩。

有关资源及其交互的更多信息，请参阅 `serving` GitHub 存储库中的资源类型概述。

关键的服务特性¶

自动扩展：服务自动从零扩展以处理传入流量，并在空闲时缩减回，从而优化资源利用率和成本。

流量管理：内置支持蓝绿部署、金丝雀发布以及不同应用程序版本之间的流量分割。

网络：自动化的入口配置，支持自定义域名、TLS 终止以及与服务网格技术的集成。

Kubernetes 原生：Knative 构建在 Kubernetes Pod 抽象之上，可轻松访问 Service Account、加速器访问和容器沙箱等功能。

配置管理：应用程序代码和配置之间的清晰分离，遵循十二要素应用原则。

Serving 中的请求流程¶

Knative Serving data flow: requests arrive at an HTTP router, then travel to either the activator or a pod with a queue-proxy and the user application. The Knative autoscaler collects metrics from the activator and the queue-proxy to determine how many pods to run.

当向 Knative Service 发出请求时：

入口层：请求通过配置的网络层（Kourier、Istio 或 Contour）进入。
路由决策：根据当前的流量模式和扩展状态，请求会被路由到 Activator 或直接路由到应用程序 Pod。
扩展：如果没有运行的 Pod（零扩展），Activator 会排队等待请求，并通知 Autoscaler 创建 Pod。
Queue-Proxy：所有请求都经过 Queue-Proxy sidecar，它会强制执行并发限制并收集指标。
应用程序：请求到达您的应用程序容器。

有关详细信息，请参阅请求流文档。

GPU 资源和 LLM 推理¶

Knative Serving 可以利用 Kubernetes Pod 的能力来访问 GPU 等专用硬件资源，使其成为 AI/ML 推理工作负载的优秀平台。

GPU 资源访问：由于 Knative Service 是作为 Kubernetes Pod 实现的，您可以使用标准的 Kubernetes 资源规范请求 GPU 资源。这使得在受益于 Knative 的自动扩展和流量管理的同时，运行需要 GPU 加速的推理模型成为可能。

LLM 推理支持：Knative Serving 为大型语言模型 (LLM) 推理服务提供了理想的基础，提供：

根据请求需求从零到多个支持 GPU 的 Pod 进行**自动扩展**
用于 A/B 测试不同模型版本或配置的**流量分割**
在不使用时**缩减昂贵的 GPU 资源**以实现**资源效率**
用于模型服务和推理端点的**标准 HTTP 接口**

KServe 集成：对于生产级的 LLM 部署，请考虑使用 KServe，这是一个构建在 Knative Serving 之上的 Kubernetes 原生模型服务平台。KServe 提供：

标准化的推理协议和多框架支持
模型集成、可解释性和漂移检测等高级功能
流行 ML 框架（TensorFlow、PyTorch、ONNX 等）的优化服务运行时
内置支持自动扩展 GPU 工作负载和批量处理请求

无论直接使用 Knative Serving 进行自定义推理服务，还是通过 KServe 进行标准化模型服务，您都可以获得 Kubernetes 原生资源管理的好处以及无服务器的运维特性。

Knative Eventing¶

Knative Eventing 是一组 API，使您能够将事件驱动架构与您的应用程序一起使用。您可以使用这些 API 创建组件，将事件从事件生产者（称为源）路由到接收事件的事件消费者（称为 Sink）。Sink 也可以配置为通过发送响应事件来响应 HTTP 请求。

architecture-beta
    group eventing[Eventing]
    group sources[Event Sources]

    service source(cloud)[Event Source] in sources
    service broker(database)[Broker] in eventing
    service trigger(server)[Trigger] in eventing
    service sink(internet)[Event Target]

    source{group}:T --> B:broker
    broker:R -- L:trigger
    trigger:B --> T:sink

Knative Eventing 是一个独立的平台，为各种类型的工作负载提供支持，包括标准 Kubernetes 服务和 Knative Serving 服务。

Knative Eventing 使用标准 HTTP POST 请求在事件生产者和 Sink 之间发送和接收事件。这些事件符合CloudEvents 规范，这使得可以使用任何编程语言创建、解析、发送和接收事件。

Knative Eventing 组件是松散耦合的，可以独立开发和部署。任何生产者都可以在没有活动事件消费者监听这些事件之前生成事件。任何事件消费者都可以在没有生产者创建这些事件之前表达对一类事件的兴趣。

关键的事件概念¶

事件源 (Event Sources)：从外部系统（数据库、消息队列、云服务等）生成事件并将其发送到 Knative 事件网格的组件。

代理 (Brokers)：事件路由器，根据 CloudEvent 属性接收来自源的事件并将其转发给感兴趣的消费者。

触发器 (Triggers)：定义哪些事件应传递给哪些消费者，并使用事件元数据进行过滤的配置对象。

接收器 (Sinks)：接收和处理事件的事件消费者。它们可以是 Knative Service、Kubernetes Service 或外部端点。

通道 (Channels)：用于生产者和消费者之间点对点事件传递的低级原语。

Eventing 中的事件流程¶

Two event sources named 1 and 2 deliver events to a broker. One trigger attached to the broker delivers type 1 events to one sink (endpoint), and another trigger selects type 2 events to deliver to a different sink.

典型的事件流程包括：

事件生成：事件源检测到更改或条件，并创建一个 CloudEvent。
事件摄取：通过 HTTP POST 将事件发送到 Broker。
事件路由：Broker 评估 Triggers 以确定哪些消费者应接收事件。
事件传递：事件作为 HTTP 请求传递给匹配的消费者。
事件处理：消费者处理事件，并可以选择生成响应事件。

Eventing 用例¶

数据管道处理：通过多个处理阶段转换和路由数据。
集成模式：使用事件驱动通信连接不同的系统。
工作流编排：协调跨多个服务的复杂业务流程。
实时分析：处理流式数据以进行监控和告警。

Knative Functions¶

Knative Functions 提供了一个简单的编程模型，用于在 Knative 上使用函数，而无需深入了解 Knative、Kubernetes、容器或 Dockerfile。

Knative Functions 使您能够使用 `func` CLI 轻松创建、构建和部署无状态、事件驱动函数作为 Knative 服务。

当您构建或运行函数时，会自动为您生成开放容器倡议 (OCI) 格式容器镜像，并将其存储在容器注册表中。每次更新代码并运行或部署它时，容器镜像也会更新。

您可以使用 `func` CLI 或 Knative CLI 的 `kn func` 插件创建函数和管理函数工作流。

Functions 开发模型¶

Knative Functions 提供了一个简化的编程模型，可以抽象化基础设施的关注点。

函数签名：函数遵循简单的签名模式，利用标准库（如 HTTP 和 CloudEvents）来防止锁定。

内置模板：特定语言的模板提供了常见函数模式的起点，并与流行的框架集成。

本地开发：函数可以在部署到 Kubernetes 之前在本地构建、运行和测试。

自动容器化：func CLI 会自动从函数代码构建容器镜像，而无需 Dockerfile 专业知识。

轻松部署：函数容器可以在任何可以运行 HTTP 应用程序的地方运行。func 也可以将您的容器部署到 Knative Serving，您可以使用 kn CLI 或标准的 Kubernetes YAML 进行管理。

支持的语言和运行时¶

Functions 通过语言包支持多种编程语言：

Node.js：使用 Express 等流行框架。
Python：支持 Flask 和 FastAPI。
Go：原生 Go HTTP 处理程序。
Java：使用 Spring Boot 和 Quarkus。
TypeScript：支持 Node.js 的完整 TypeScript。

您还可以构建自己的语言包，根据自己的规范自定义输出容器。

Function 的部署和生命周期¶

flowchart TD
  init>"`<code>func init</code>
  to create a function`"]
  git@{ shape: lin-cyl, label: "fa:fa-git-alt local repo" }
  laptop@{ shape: win-pane, label: "Local Development fa:fa-docker" }
  oci@{ shape: procs, label: "Container Registry" }
  cluster@{ label: "fa:fa-dharmachakra Knative Serving" }

init --> git
git --  develop and test locally--> laptop
laptop --> git
git -- "`<code>func push</code>
push container to registry`" --> oci -.-> cluster
git -- deploy container and triggers --> cluster

开发：使用特定语言的模板编写函数。
构建：func CLI 创建优化的容器镜像。
部署：函数作为 Knative Service 部署，并自动扩展。
调用：函数可以通过 HTTP 请求或 CloudEvents 触发。
管理：使用熟悉的 Kubernetes 工具更新、删除和监控函数。

系统集成和互操作性¶

组件如何协同工作¶

虽然每个 Knative 组件都可以独立使用，但它们的设计旨在无缝协同工作：

Functions + Serving：Functions 被部署为 Knative Service，继承所有服务功能，如自动扩展和流量管理。

Functions + Eventing：Functions 可以由 CloudEvents 触发，从而实现事件驱动的函数执行和微服务编排。

Serving + Eventing：Services 可以充当事件源或接收器，参与复杂的事件驱动工作流。

与 Kubernetes 生态系统的集成¶

Knative 与标准的 Kubernetes 资源和第三方工具集成：

Kubernetes 原生资源：Serving 和 Eventing 作为 Kubernetes 自定义资源实现，这意味着您可以使用与 Kubernetes 相同的策略和 IAM 工具。

基于 Kubernetes：Serving 创建 Pod（因此您可以使用 GPU、Service Account 和其他 Kubernetes 功能），Eventing 可以轻松地将事件传递给 Kubernetes Service 以及 Serving Functions。

网络：与 cert-manager 集成以进行证书管理，并与 Gateway API 集成以进行入口。与 Istio、Envoy 和其他服务网格技术集成以进行高级流量管理和安全性。

监控：使用 OpenTelemetry，与 Prometheus、Grafana、Jaeger 以及许多其他可观察性工具集成以获取指标和监控。

CI/CD：与 GitOps 工作流、Tekton Pipelines 和其他持续部署工具兼容。

用例和何时选择 Knative¶

理想的用例¶

API 开发：快速开发和部署具有内置扩展和流量管理的 REST API。

事件驱动应用程序：以可靠的传递和错误处理方式处理来自各种源的事件。

推理服务：直接使用 Knative，或与 KServe 集成以轻松管理 AI 推理模型。

微服务架构：构建和部署松耦合的服务，并具备自动扩展和服务发现功能。

集成工作流：使用事件驱动模式连接遗留系统和 SaaS 应用程序。

边缘计算：将轻量级函数和服务部署到更靠近用户或数据源的位置。

开发环境：在不使用时自动缩减开发环境；当请求到来时再次启动。

评估标准¶

当您需要以下条件时选择 Knative：

无需供应商锁定的 **Kubernetes 原生无服务器**
**自动扩展**，包括零扩展能力
具有标准化事件处理能力的**事件驱动架构**
针对云原生应用程序的**开发者生产力**提升
通过高效的资源利用实现**成本优化**
**灵活性**，可以根据您的需求独立使用组件

当以下情况时，请考虑替代方案：

您需要极低的冷启动延迟（低于 100 毫秒）
您的工作负载需要持久化状态或长时间运行的进程

下一步¶

安装：开始使用 Knative 安装
快速入门：尝试 Knative 快速入门以获得实践经验
服务指南：详细了解 Knative Serving
事件指南：探索 Knative Eventing 功能
Functions 指南：构建您的第一个 Knative Function
示例：浏览示例应用程序和用例