1. Knative Service 架构总览：核心组件、数据/控制平面分离与请求生命周期

Knative 是一个基于 Kubernetes 的无服务器平台，其核心设计哲学是数据平面与控制平面分离。理解这一架构是进行故障排查与恢复的基础。本章将拆解 Knative 的三大核心组件（Serving、Eventing、Tekton），并深入分析请求从入口到 Pod 的完整生命周期。

1.1 三大核心组件与职责

1.2 数据平面与控制平面分离原理

Knative 严格遵循 Kubernetes 的声明式 API 模式，将系统拆分为两个逻辑平面：

• 控制平面（Control Plane）：由 Knative 控制器（Controller）和 Webhook 组成。它负责监听 Kubernetes 资源变化，协调期望状态与实际状态。例如，当用户创建 ksvc 时，控制器会生成 Configuration、Revision 和 Route 对象。
• 数据平面（Data Plane）：由 Activator 和 Queue-Proxy 边车容器组成。它负责处理实际的请求流量、缓冲请求（当 Pod 从零缩放时）以及上报并发指标。

1.3 请求生命周期详解

一个外部 HTTP 请求到达 Knative Service 的完整路径如下，理解每个环节的故障模式至关重要：

1. Ingress 入口：请求首先到达集群入口网关（通常是 Istio Ingress Gateway 或 Kourier）。网关根据 Host 头将请求路由到对应的 Knative Service。
2. Activator 介入：如果目标 Revision 当前缩放为 0（无运行中 Pod），请求会被转发到 Activator。Activator 会缓冲该请求，同时触发 Autoscaler 启动一个新的 Pod。
3. Queue-Proxy 代理：当 Pod 启动后，请求被转发到 Pod 内的 Queue-Proxy 边车容器。Queue-Proxy 负责并发控制、请求超时管理以及向 Autoscaler 上报并发指标。
4. 用户容器处理：Queue-Proxy 将请求转发给同 Pod 内的 User Container（即你的应用代码）。应用处理完成后，响应沿原路径返回。
5. 直连模式：当 Revision 已有运行中 Pod 且流量稳定时，网关会绕过 Activator，直接将请求路由到 Pod 的 Queue-Proxy，减少网络跳转。

1.4 核心资源对象关系

Knative Service 在 Kubernetes 中表现为一组相互关联的资源对象。理解它们的关系是排查配置问题的关键：

# 一个典型的 Knative Service YAML 示例
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-world
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
          env:
            - name: TARGET
              value: "Knative"
---
# 上述 Service 会自动生成以下子资源：
# Configuration: hello-world
# Revision:       hello-world-00001
# Route:          hello-world

1.5 本章小结与故障排查思维导图

掌握 Knative 架构是故障排查的第一步。请记住以下核心原则：

• 控制平面负责“声明与协调”，数据平面负责“请求与转发”。
• 请求生命周期中的每个节点（网关 → Activator → Queue-Proxy → 用户容器）都可能成为故障点。
• 使用 kubectl get ksvc,configuration,revision,route 快速定位资源状态。
• 使用 kubectl logs -n knative-serving <controller-pod> 查看控制平面错误。