4. 故障场景分类：网络分区、etcd故障、Pod崩溃、配置错误

在Knative控制面故障恢复工程中，准确识别故障场景是制定恢复策略的前提。根据生产环境中的实际案例，我们将故障场景归纳为四大类：网络分区、etcd故障、Pod崩溃和配置错误。每类故障对Knative资源模型的影响路径、检测手段和恢复策略均有显著差异。

4.1 故障场景全景图

以下SVG图展示了四类故障在Knative控制面中的影响范围与传播路径。每个故障类型对应一组核心受损资源，并指向相应的恢复动作。

4.2 网络分区故障

网络分区是Knative控制面中最隐蔽、最难诊断的故障类型。当控制面组件之间的网络连通性被切断，但各组件进程仍在运行时，会出现脑裂现象。

4.2.1 故障特征

• Webhook不可达：Knative的MutatingWebhookConfiguration和ValidatingWebhookConfiguration无法被API Server调用，导致资源创建/更新被阻塞。
• 控制器脑裂：多个副本的控制器同时认为自己是Leader，导致资源状态反复覆盖。
• 资源同步中断：Service、Configuration、Revision等资源的Status字段无法被及时更新。

4.2.2 恢复策略

4.3 etcd故障

etcd作为Kubernetes和Knative的唯一数据源，其故障会直接导致整个控制面不可用。etcd故障分为数据面故障（如磁盘IO hang）和共识面故障（如Leader选举失败）。

4.3.1 故障特征

• 资源版本丢失：Knative资源的resourceVersion出现跳跃或回退，导致Informer的Watch机制失效。
• Watch中断：控制器无法通过ListWatch获取资源变更事件，状态机停滞。
• 数据不一致：etcd集群节点之间的数据出现分歧，导致同一资源在不同控制器副本中呈现不同状态。

4.3.2 恢复策略

4.4 Pod崩溃

Pod崩溃是Kubernetes中最常见的故障类型。在Knative控制面中，Pod崩溃会导致控制器、Webhook或Activator等组件的瞬时不可用。

4.4.1 故障特征

• 控制器重启：控制器Pod因OOM、panic或健康检查失败而重启，工作队列中的任务丢失。
• 队列积压：重启期间，未处理的工作项在API Server中积压，重启后需要快速消费。
• 资源状态丢失：控制器内存中的状态缓存被清空，需要重新从etcd同步。

4.4.2 恢复策略

4.5 配置错误

配置错误是人为因素导致的最常见故障。在Knative中，配置错误通常发生在ConfigMap、Webhook配置或资源定义层面。

4.5.1 故障特征

• 准入校验失败：Webhook拒绝所有资源创建请求，因为配置变更导致校验逻辑异常。
• 资源无法创建：错误的配置导致控制器无法生成正确的子资源（如Deployment、Service）。
• 级联错误：一个配置错误引发多个组件连锁故障，如网络配置错误导致Activator无法转发流量。

4.5.2 恢复策略

4.6 故障场景对比总结

以下表格从检测难度、影响范围、恢复复杂度和对Knative资源模型的影响四个维度对四类故障进行对比。