1. 课程导论：证书轮换导致 kube-proxy 规则失效的典型场景与故障影响

1.1 故障全景：一个被低估的集群稳定性杀手

在生产 Kubernetes 集群中，证书轮换是保障通信安全的常规运维操作。然而，当 kube-proxy 所使用的客户端证书（通常挂载自 kube-system 命名空间的 kube-proxy Secret）被轮换后，若 kube-proxy 未正确重载新证书，将导致其与 API Server 的通信中断，进而引发 Service 规则无法同步、节点网络策略失效、ClusterIP 与 NodePort 不可达 等一系列连锁故障。

这类故障具有以下特征：

• 隐蔽性强：证书轮换本身是正常操作，初期无显式告警。
• 影响范围广：单个节点或整个集群的 Service 流量中断。
• 排查路径长：涉及证书、kube-proxy 进程、iptables/ipvs 规则、API Server 连接等多个层面。

1.2 典型故障场景：证书轮换触发链路断裂

以下表格列出了证书轮换导致 kube-proxy 规则失效的 4 种典型场景，覆盖了从手动轮换到自动轮换的常见操作：

1.3 故障影响评估：从局部到全局

证书轮换导致 kube-proxy 规则失效的影响程度，取决于故障节点的数量和 Service 的依赖关系。以下从 服务可用性、运维成本、数据面风险 三个维度进行量化评估：

• 服务可用性：
  • 单节点故障：影响该节点上所有 Pod 的出站/入站 Service 流量，约 5%-20% 的请求失败。
  • 全集群故障：所有 Service 的 ClusterIP 和 NodePort 不可达，业务完全中断。
• 运维成本：
  • 平均故障定位时间（MTTI）：30 分钟 - 2 小时（因涉及证书、进程、网络规则多层排查）。
  • 平均故障恢复时间（MTTR）：10 分钟 - 1 小时（取决于是否具备自动化重载机制）。
• 数据面风险：
  • iptables/ipvs 规则残留：旧规则未清理，可能导致流量黑洞或错误路由。
  • 连接中断：已建立的 TCP 连接可能被重置，影响有状态服务。

1.4 故障链路可视化：证书轮换 → 规则失效的完整路径

下图展示了从证书轮换操作到 kube-proxy 规则最终失效的 完整故障链路，帮助理解各环节的依赖关系：

1.5 课程学习路径与预期收获

本课程将围绕上述故障链路，从 原理剖析、排查工具、实战演练、预防方案 四个阶段展开：