3. 控制面架构剖析：Knative 控制面组件与通信机制

Knative 控制面由一组高度特化的 Kubernetes 原生组件构成，它们协同工作以完成从“用户提交 Service 资源”到“Pod 就绪并可路由”的完整生命周期管理。理解每个组件的职责边界、内部状态机以及组件间的通信协议，是进行控制面故障排查的前提。

3.1 核心组件职责与资源模型映射

Knative 控制面包含四个核心组件：Controller、Webhook、Activator 和 Queue-Proxy。其中 Queue-Proxy 虽以 Sidecar 形式运行在数据面 Pod 中，但其配置与状态由控制面驱动，因此纳入控制面架构讨论。

3.2 组件间通信机制与协议

Knative 控制面组件间的通信并非通过统一的内部 API 网关，而是依赖 Kubernetes 原生机制与轻量级 gRPC 协议。这种设计减少了单点故障，但也使得故障排查时需要追踪多条通信路径。

3.2.1 通信路径总览

3.2.2 关键通信路径详解

1. Webhook 准入控制路径：用户通过 kubectl apply 提交 Knative Service 时，API Server 会先调用 MutatingWebhook 注入默认值（如默认 concurrency limit），再调用 ValidatingWebhook 校验字段合法性。此路径故障通常表现为资源创建被静默拒绝。
2. Controller 调和路径：Controller 通过 Watch 机制监听 Knative CRD 变化，将 Revision 调和为 Deployment + K8s Service，并维护 Configuration → Revision → Route 的引用链。此路径故障会导致资源状态停滞。
3. Activator-Autoscaler 缩放路径：当 Revision 缩放至零后，Activator 成为流量入口。Activator 通过 gRPC 向 Autoscaler 报告请求指标，Autoscaler 决策扩容后通知 Activator 将流量转发至新启动的 Pod。
4. Queue-Proxy 指标上报路径：每个用户 Pod 内的 Queue-Proxy 通过 gRPC 流将并发请求数、请求延迟等指标上报至 Autoscaler。此路径中断会导致 Autoscaler 无法感知真实负载，进而触发错误的缩放决策。

3.3 组件内部状态机与故障边界

每个控制面组件内部都维护着有限状态机，故障排查的核心在于定位状态转换的阻塞点。

3.3.1 Controller 的 Reconciler 循环

// 简化的 Reconciler 循环伪代码
func (r *Reconciler) Reconcile(ctx context.Context, key string) error {
    // 1. 获取当前资源状态
    svc, err := r.ServiceLister.Get(key)
    if err != nil {
        return err // 资源已删除，清理下游资源
    }
    
    // 2. 获取期望状态（从 Configuration 推导）
    desired := r.buildDesiredState(svc)
    
    // 3. 调和 Deployment
    if err := r.reconcileDeployment(ctx, desired); err != nil {
        return fmt.Errorf("reconcile deployment: %w", err)
    }
    
    // 4. 调和 K8s Service
    if err := r.reconcileService(ctx, desired); err != nil {
        return fmt.Errorf("reconcile service: %w", err)
    }
    
    // 5. 更新资源状态
    return r.updateStatus(ctx, svc, desired)
}

故障排查时，若 Controller 日志反复出现 Reconciler error，应检查步骤 3 或 4 中是否因 RBAC 权限不足、资源配额耗尽或 CRD 版本不匹配导致调和失败。

3.3.2 Activator 的流量代理状态机

3.4 组件间依赖与故障传播

Knative 控制面的组件依赖并非线性，而是形成网状结构。一个组件的故障可能通过多条路径传播，导致看似无关的症状。

3.5 组件健康检查与可观测性

每个控制面组件都暴露了标准的 Kubernetes 健康探针和 Prometheus 指标，用于故障排查时的快速诊断。