4. Knative 核心概念：Service、Configuration、Revision、Route 与自动扩缩容机制

Knative Serving 是构建在 Kubernetes 之上的无服务器平台，它抽象了部署、路由和自动扩缩容的复杂性。理解其核心资源模型是掌握 Knative 故障恢复与事件驱动部署的基础。本章将深入剖析 Knative Service、Configuration、Revision、Route 四个核心概念，并详细解读其自动扩缩容机制。

4.1 核心资源模型概览

Knative Serving 通过四个相互关联的 Kubernetes 自定义资源（CRD）来管理无服务器工作负载。它们共同构成了一个声明式的、版本化的、可路由的部署模型。

资源名称 缩写 核心职责 生命周期管理
Service ksvc 作为用户入口，自动管理 Configuration 和 Route 的生命周期。 用户直接操作，负责创建、更新、删除。
Configuration config 定义服务的期望配置（镜像、环境变量、资源限制等），每次变更生成一个新的 Revision。 由 Service 自动管理，也可独立操作。
Revision rev 代表 Configuration 的一个不可变快照，包含代码和配置的特定版本。 由 Configuration 自动创建，不可手动修改。
Route route 将流量路由到指定的 Revision(s)，支持灰度发布、流量切分。 由 Service 自动管理，也可独立配置流量策略。
讲师提示： 在故障恢复场景中，Service 是用户与 Knative 交互的唯一入口。当我们需要回滚到上一个稳定版本时，实际上是通过修改 Service 的配置，触发 Configuration 创建新的 Revision，然后 Route 将流量指向该 Revision。理解这个链条是自动化恢复的关键。

4.2 资源关系与数据流

下图展示了 Knative Service 创建后，四个核心资源之间的协作关系与数据流。当用户提交一个 Service YAML 时，Knative 控制器会自动创建 Configuration 和 Route。Configuration 进一步生成 Revision，而 Route 则负责将外部请求路由到 Revision 管理的 Pod 上。

Knative Serving 核心资源关系与数据流 用户 (kubectl apply) Service (ksvc) Configuration (config) Route (route) Revision (rev) 流量路由规则： Route 根据配置将流量（如 100%） 路由到指定的 Revision 实例上。

4.3 核心概念详解

4.3.1 Service (ksvc)

Service 是 Knative 的最高层抽象，它负责自动创建和管理 Configuration 与 Route。用户只需定义 Service 的 YAML 清单，Knative 便会自动处理版本控制和流量路由。在故障恢复场景中，Service 的 spec.template 字段定义了 Pod 模板，任何对该模板的修改都会触发新的 Revision 创建。

4.3.2 Configuration (config)

Configuration 描述了服务的“期望状态”。每次 Configuration 的 spec 发生变化（例如更新镜像标签），Knative 都会创建一个新的 Revision。Configuration 维护了一个 Revision 列表，并标记了“最新就绪的 Revision”和“最新创建的 Revision”。

4.3.3 Revision (rev)

Revision 是 Knative 中不可变的版本快照。它包含了特定时刻的代码、配置和资源请求。每个 Revision 会自动扩缩容到零个或多个 Pod 实例。Revision 的名称由 Configuration 名称和版本号组成（例如 hello-world-00001）。在故障恢复时，我们可以通过 Route 将流量指向一个已知的、健康的 Revision 来实现快速回滚。

4.3.4 Route (route)

Route 负责将请求流量映射到一个或多个 Revision 上。它支持灵活的流量管理策略：

  • 主流量指向最新就绪 Revision：默认行为，确保用户始终访问最新稳定版本。
  • 流量切分：可以将流量按百分比分配到不同的 Revision，用于蓝绿部署或金丝雀发布。
  • 命名路由：可以为特定 Revision 创建独立的 URL（例如 canary.example.com）。

4.4 自动扩缩容机制 (Autoscaler)

Knative 的自动扩缩容是其作为无服务器平台的核心能力。它基于请求并发数（Concurrency）而非传统的 CPU/内存指标进行决策，实现了从零到 N 的快速伸缩。

4.4.1 核心组件与工作流程

自动扩缩容由 Activator 和 Autoscaler 两个核心组件协作完成：

  1. 缩容到零：当 Revision 的 Pod 在一段可配置的时间（默认 60 秒）内未收到任何请求时，Autoscaler 会将 Pod 数量缩减至 0。
  2. 冷启动：当新请求到达时，请求首先被 Activator 拦截。Activator 缓存请求，并通知 Autoscaler 启动新的 Pod。
  3. 快速扩容：Autoscaler 根据请求速率和并发数，快速创建新的 Pod。一旦 Pod 就绪，Activator 将请求转发给 Pod，并将后续请求直接路由到 Pod。
  4. 稳定运行：在流量稳定后，请求直接到达 Pod，Activator 不再参与数据路径，以减少延迟。
关键指标：
  • concurrency-target：每个 Pod 的目标并发请求数（默认 100）。
  • container-concurrency：Pod 内容器允许的最大并发请求数（硬限制）。
  • stable-window：稳定窗口期，用于判断是否缩容（默认 60 秒）。
  • panic-window：恐慌窗口期，用于快速扩容（默认 6 秒）。

4.4.2 自动扩缩容流程图

下图展示了从“无流量”到“高并发”再到“缩容到零”的完整生命周期，以及 Activator 和 Autoscaler 在不同阶段的作用。

Knative 自动扩缩容生命周期 阶段 1：缩容到零 Pod 数 = 0 无流量 请求到达 阶段 2：冷启动 Activator 拦截请求 Autoscaler 启动 Pod 阶段 3：快速扩容 Pod 数快速增长 请求直连 Pod 阶段 4：稳定运行 Pod 数稳定 Activator 退出路径 阶段 5：流量下降 Autoscaler 评估 逐步缩容 阶段 1：缩容到零 Pod 数 = 0 等待新请求 关键配置： stable-window=60s (缩容评估周期) | panic-window=6s (快速扩容触发) | container-concurrency=100 (Pod 最大并发)

4.5 故障恢复视角下的核心概念应用

在事件驱动部署和故障恢复的上下文中，理解这些概念至关重要：

  • 回滚操作：当新部署的 Revision 出现故障时，可以通过修改 Service 的 spec.template 回退到上一个 Configuration 的 spec，或者直接通过 Route 将 100% 流量指向已知健康的 Revision。
  • 流量灰度：在恢复过程中，可以先通过 Route 将 1% 的流量切到新 Revision 进行验证，确认无误后再逐步增加流量比例。
  • 自动扩缩容与故障：如果应用出现内存泄漏或响应变慢，Autoscaler 可能会错误地认为需要更多 Pod 来处理请求，导致资源耗尽。此时需要结合监控指标（如错误率、延迟）来触发自动回滚，而不是单纯依赖并发数。
实战注意： 在 Argo CD 事件驱动部署中，Git 仓库的变更会触发 Knative Service 的更新。如果更新后的 Revision 启动失败（CrashLoopBackOff），Knative 会自动保留上一个 Revision。Argo CD 的自动回滚策略应结合 Knative 的 Revision 状态（Ready 条件）来判断是否需要执行回滚操作，避免陷入“不断重试失败版本”的死循环。
← 上一章 📖 返回目录 下一章 →