2. Knative 资源模型总览：CRD 体系、资源层级与依赖关系
Knative Serving 的资源模型是控制面故障排查的核心地图。它基于 Kubernetes 自定义资源定义（CRD）构建，通过四个核心资源——Service、Route、Configuration 和 Revision——形成清晰的层级与依赖关系。理解这套模型，是定位配置错误、路由异常、版本回滚失败等故障的前提。
2.1 CRD 体系：Knative 在 Kubernetes 中的扩展
Knative Serving 通过 CRD 向 Kubernetes API Server 注册了四个核心资源类型。每个 CRD 都定义了资源的规范（Spec）和状态（Status），控制面组件通过监听这些资源的变化来驱动实际状态。
| CRD 名称 | API 版本（示例） | 缩写 | 核心作用 |
|---|---|---|---|
services.serving.knative.dev |
v1 |
ksvc |
用户入口，管理整个应用生命周期 |
routes.serving.knative.dev |
v1 |
route |
流量路由与分配策略 |
configurations.serving.knative.dev |
v1 |
config |
配置模板，管理版本生成 |
revisions.serving.knative.dev |
v1 |
rev |
不可变快照，代表一个具体的代码+配置版本 |
故障排查提示： 使用
kubectl get ksvc,route,config,rev -n <namespace> 可以快速查看所有 Knative 资源的当前状态。如果某个资源卡在 Unknown 或 False 状态，通常意味着其依赖的下层资源存在问题。
2.2 资源层级：从 Service 到 Revision 的逐层分解
四个资源之间存在严格的“父-子”层级关系。用户通常只操作顶层的 Service，Knative 控制面会自动向下生成 Route、Configuration 和 Revision。
- Service（ksvc）：用户可见的唯一入口。它同时拥有一个 Route 和一个 Configuration 的引用。
- Configuration（config）：负责管理应用的“配置模板”。每次用户更新 Service 的镜像或环境变量时，Configuration 会生成一个新的 Revision。
- Revision（rev）：一个不可变的快照，包含代码、配置和运行时环境。Revision 是 Knative 自动扩缩容的最小单元。
- Route（route）：负责将流量路由到指定的 Revision。它支持按百分比分配流量，以及基于标签的定向路由。
2.3 资源间依赖关系：控制面流转的“因果链”
在控制面故障排查中，依赖关系决定了故障传播路径。一个上层资源的状态异常，往往是由其依赖的下层资源引起的。
2.3.1 核心依赖链
- Service → Configuration：Service 的
spec.template定义了 Configuration 的模板。当 Service 更新时，Configuration 会创建一个新的 Revision。 - Configuration → Revision：Configuration 的每次变更（如镜像版本更新）都会生成一个全新的 Revision。Revision 的名称由 Configuration 名称和版本号组成（例如
helloworld-00001）。 - Service → Route：Service 的
spec.traffic定义了 Route 的流量分配策略。Route 根据此配置将流量指向一个或多个 Revision。 - Route → Revision：Route 的
spec.traffic中的revisionName字段直接引用具体的 Revision。如果引用的 Revision 不存在或状态异常，Route 将无法正常提供服务。
2.3.2 依赖关系故障排查矩阵
| 故障现象（上层资源） | 可能的下层依赖根因 | 排查命令 |
|---|---|---|
Service 状态为 False |
Configuration 或 Route 创建失败 | kubectl describe ksvc <name> |
| Route 无法分配流量 | 引用的 Revision 不存在或处于 Failed 状态 |
kubectl get route <name> -o yaml |
| Configuration 不生成新 Revision | Service 的 spec.template 配置错误 |
kubectl describe config <name> |
Revision 状态卡在 Unknown |
底层 Pod 无法启动（镜像拉取失败、资源不足） | kubectl describe rev <name> |
常见陷阱： 不要直接删除一个正在被 Route 引用的 Revision。这会导致 Route 的流量目标失效，进而使 Service 进入
Failed 状态。正确的做法是先更新 Route 的流量配置，将流量切走，再删除旧的 Revision。
2.4 资源状态流转与故障信号
每个 Knative 资源都有三个核心状态条件：Ready、Unknown 和 Failed。控制面故障排查的核心就是追踪这些状态条件的变化。
- Ready (True)：资源正常工作，所有依赖都已就绪。
- Unknown：资源正在处理中，或等待下层资源就绪。这是故障排查中最常见的“中间状态”。
- Failed (False)：资源出现不可恢复的错误，需要人工介入。
排查要点： 当 Service 状态为
False 时，不要直接查看 Service 本身，而应沿着依赖链向下排查：ksvc → route/config → rev。通常，最底层的 Revision 会暴露真正的错误原因（如镜像拉取失败、健康检查超时）。