4. 网络配置风险：蓝绿切换中常见的网络配置错误

蓝绿发布的核心优势在于流量瞬间切换，但这一“瞬间”动作对底层网络配置的完整性和一致性提出了极高要求。在容器化环境中，CNI（Container Network Interface）插件负责为每个 Pod 分配 IP、配置路由和策略。当新旧版本集群同时运行，且流量入口从“蓝”切向“绿”时，任何网络配置的偏差都可能导致服务中断。本章将系统梳理三类最常见的网络配置错误：IP 冲突、路由丢失和策略失配。

4.1 三类核心风险概述

下表从故障现象、根因和影响范围三个维度，对三类风险进行对比，帮助读者建立全局认知。

4.2 IP 冲突：地址空间重叠

在蓝绿发布中，如果新旧版本集群共享同一个 IP 地址池（例如使用相同的 ClusterCIDR 或 ServiceCIDR），当新版本 Pod 启动时，CNI 的 IPAM 模块可能分配一个已被旧版本 Pod 占用的 IP 地址。这会导致网络栈出现重复地址检测（DAD）失败，进而引发 ARP 表混乱和连接中断。

防护要点：

• 为蓝绿版本分配独立的 IP 地址池（如 Calico IPPool 的 nodeSelector 或 namespaceSelector）。
• 在 CNI 配置中启用 resolvConf 和 ipam 的 strictAffinity 模式。
• 切换前执行 IP 地址预检，确保目标 CIDR 内无存活 Pod。

4.3 路由丢失：流量路径断裂

CNI 插件（如 Calico、Cilium）依赖 BGP 或 VXLAN 隧道维护节点间的路由表。蓝绿切换时，如果新版本节点加入集群后路由未正确发布，或旧版本节点退出时路由回收不及时，就会产生“黑洞”路由——流量被转发到一个已经不存在的 Pod 或节点。

防护要点：

• 使用 BGP 的 graceful restart 或 Cilium 的 kvstore 模式确保路由平滑迁移。
• 在切换脚本中增加路由收敛等待（如 calicoctl node status 确认所有路由已学习）。
• 部署路由监控探针，周期性验证关键 Service 的连通性。

4.4 策略失配：安全规则与版本脱节

Kubernetes NetworkPolicy 基于 Pod 标签进行流量控制。蓝绿发布时，新版本 Pod 通常使用新的标签（如 version: v2），而旧版本的 NetworkPolicy 可能只匹配 version: v1。如果策略未同步更新，会导致两种后果：

• 过度限制： 新版本 Pod 被策略拒绝，无法被 Service 访问。
• 过度放行： 旧版本策略未清理，允许已废弃的 Pod 继续接收流量。

策略失配的典型表现：

4.5 综合防护策略

针对上述三类风险，推荐在自动化回滚框架中嵌入以下防护措施：

1. 预检阶段： 扫描目标 CIDR 的 IP 占用情况，验证 BGP 路由表完整性，模拟 NetworkPolicy 匹配结果。
2. 切换阶段： 采用“先增后删”原则，先为新版本建立完整网络路径，再移除旧版本配置。
3. 回滚阶段： 保留旧版本的完整网络快照（IP 分配、路由表、策略规则），确保回滚时能原子化恢复。

4.6 风险矩阵与优先级

在实际生产环境中，三类风险的发生概率和影响程度不同。下表给出优先级排序，供 SRE 团队制定防护策略时参考。