Knative Serving 核心资源模型详解

Knative Serving 定义了四个核心资源对象：Service、Route、Configuration 和 Revision。这四个资源构成了 Knative Serverless 工作负载的完整生命周期管理模型，也是后续进行容量参数配置与网络瓶颈诊断的基础。

2.1 四层资源模型概述

Knative Serving 采用分层抽象的设计思想，将用户请求的流量管理、配置管理和版本管理解耦为独立的资源对象。下表总结了每个资源的核心职责与关键属性：

2.2 资源模型工作流程

下图展示了 Knative Serving 四层资源模型在用户部署一个 Serverless 应用时的完整工作流程：

2.3 各资源模型深度解析

2.3.1 Revision — 不可变版本快照

Revision 是 Knative Serving 中最核心的底层资源，代表一个特定版本的代码、配置和运行时环境的不可变快照。每次用户修改 Service 或 Configuration 的 template 时，Knative 都会创建一个新的 Revision。

以下是一个 Revision 的 YAML 示例，展示了关键的容量参数配置：

apiVersion: serving.knative.dev/v1
kind: Revision
metadata:
  name: helloworld-go-00001
  namespace: default
spec:
  containerConcurrency: 50          # 每个 Pod 最大并发请求数
  timeoutSeconds: 300               # 请求超时时间
  podAutoscaler:
    class: kpa.autoscaling.knative.dev
    metrics: concurrency            # 基于并发数扩缩容
    target: 10                      # 每个 Pod 目标并发数
  containers:
  - image: gcr.io/knative-samples/helloworld-go
    resources:
      requests:
        cpu: 250m
        memory: 128Mi
      limits:
        cpu: 500m
        memory: 256Mi

2.3.2 Configuration — 部署配置与版本管理

Configuration 负责管理部署模板和版本历史。它定义了 Pod 的期望状态（容器镜像、环境变量、资源限制等），并自动追踪每次变更生成的 Revision。

2.3.3 Route — 流量路由与灰度发布

Route 负责将外部请求按照配置的流量规则分发到不同的 Revision。它是实现灰度发布、蓝绿部署和流量回滚的核心组件。

Route 的流量分配规则支持两种模式：

• 按百分比分配：将流量按百分比拆分到多个 Revision，适用于 A/B 测试和金丝雀发布。
• 按标签分配：通过 HTTP Header 或 URL 参数将特定流量路由到指定 Revision，适用于内部测试。

apiVersion: serving.knative.dev/v1
kind: Route
metadata:
  name: helloworld-go
  namespace: default
spec:
  traffic:
  - revisionName: helloworld-go-00001
    percent: 90                    # 90% 流量到稳定版本
  - revisionName: helloworld-go-00002
    percent: 10                    # 10% 流量到新版本（金丝雀）
  - revisionName: helloworld-go-00003
    tag: latest                    # 通过标签访问，不参与百分比分配

2.3.4 Service — 用户统一入口

Service 是用户最常操作的资源，它自动管理 Route 和 Configuration 的生命周期。当用户创建或更新 Service 时，Knative 控制器会自动完成以下操作：

1. 更新 Configuration 的 template，触发新 Revision 的创建。
2. 更新 Route 的流量规则，默认将 100% 流量指向最新就绪的 Revision。
3. 自动创建 Knative 内部的 Cluster Local 域名，格式为：{service}.{namespace}.svc.cluster.local。

2.4 资源模型之间的协作关系

下图展示了 Service、Route、Configuration 和 Revision 之间的完整协作关系，以及它们如何共同实现 Serverless 工作负载的自动部署、流量管理和版本控制：

2.5 资源模型与容量参数的关系

理解四层资源模型是进行容量参数配置的前提。下表总结了每个资源层面对容量配置的影响：