2. CNI基础回顾：CNI插件架构、常见CNI插件（Calico、Flannel、Cilium）对比
在深入蓝绿发布的网络回滚与防护之前，必须重新夯实CNI（Container Network Interface）的基础。CNI是Kubernetes网络插件的标准接口，它定义了容器运行时如何配置网络。理解其架构与主流插件的差异，是设计自动化回滚策略的前提。
2.1 CNI插件架构
CNI架构遵循“最小化、可组合”的设计原则。它不负责IPAM（IP地址管理）的持久化或跨节点路由策略，而是通过一个简单的JSON配置文件和二进制插件链来完成网络配置。
核心流程： kubelet（或容器运行时）在创建Pod时，按顺序调用CNI插件链。每个插件执行ADD/DEL操作，将结果通过标准输出返回给调用方。
2.2 常见CNI插件对比
当前生产环境最主流的三种CNI插件是Calico、Flannel和Cilium。它们在数据平面、网络策略支持和性能上存在显著差异，直接影响蓝绿发布中流量切换与回滚的复杂度。
| 特性维度 | Calico | Flannel | Cilium |
|---|---|---|---|
| 数据平面 | 纯三层路由（BGP）或eBPF | VXLAN / host-gw 二层覆盖 | eBPF（内核态） |
| 网络策略 | 完整K8s NetworkPolicy + 全局策略 | 不支持（需额外组件） | 完整K8s NetworkPolicy + L7策略 |
| 性能（吞吐/延迟） | 高（BGP模式接近原生） | 中（VXLAN有封装开销） | 极高（eBPF绕过iptables） |
| IPAM | 内置IP池管理 | 内置子网分配 | 内置或CRD自定义 |
| 回滚复杂度 | 中（需处理BGP会话与路由表） | 低（配置简单，覆盖网络易重建） | 高（eBPF程序需原子替换） |
| 适用场景 | 混合云、多集群、安全隔离 | 小规模、快速部署 | 高性能、可观测性、安全增强 |
选型建议： 对于蓝绿发布场景，如果网络策略是刚需（如金融、合规环境），Calico是首选；如果追求极致性能且团队有eBPF能力，Cilium是最佳选择；Flannel适合对网络策略无要求、追求极简运维的小规模集群。
2.3 核心差异详解
2.3.1 数据平面与封装机制
- Flannel（VXLAN）：在UDP之上封装二层帧，每个数据包增加50字节头部。优点是跨三层网络透明，缺点是CPU开销高、吞吐下降约10%-15%。
- Calico（BGP）：直接在三层路由，无封装。每个节点运行BGP Speaker，与ToR交换机或Route Reflector交换路由。性能接近宿主机网络。
- Cilium（eBPF）：通过eBPF程序在内核态直接处理网络包，绕过iptables和Netfilter。延迟可降低至微秒级，适合延迟敏感型应用。
2.3.2 网络策略实现
网络策略是蓝绿发布中控制流量隔离的关键。Calico和Cilium都支持Kubernetes原生NetworkPolicy，但扩展能力不同：
- Calico：提供GlobalNetworkPolicy，可跨命名空间生效，支持基于节点标签的规则。
- Cilium：支持L7协议（HTTP/gRPC/Kafka）策略，可基于请求方法、路径、Header做精细化控制。
- Flannel：本身不实现NetworkPolicy，需要配合Calico的policy-only模式或使用第三方组件（如Antrea）。
2.3.3 回滚场景下的关键差异
在蓝绿发布回滚时，CNI插件的配置变更（如IP池调整、路由策略修改、eBPF程序更新）必须可逆且原子化。下表总结了各插件在回滚中的关键风险点：
| 回滚操作 | Calico风险 | Flannel风险 | Cilium风险 |
|---|---|---|---|
| IP池变更回滚 | BGP路由收敛延迟，可能导致短暂丢包 | VXLAN隧道重建，影响较小 | eBPF Map更新需原子操作，失败可能残留 |
| 网络策略回滚 | 策略冲突检测，需保证旧策略完全覆盖 | 不涉及（无策略） | L7策略回滚需清理eBPF程序，复杂度高 |
| 插件版本回退 | 需同时回退Felix与BIRD配置 | 二进制替换即可，配置简单 | 需卸载旧eBPF程序并加载新版本，可能影响运行中Pod |
回滚防护要点： 在蓝绿发布中，如果CNI配置（如IP池、策略规则）作为发布的一部分被修改，回滚时必须确保CNI配置的原子性。对于Cilium，建议使用
cilium config的原子更新模式；对于Calico，建议使用calicoctl replace --allow-version-mismatch并配合BGP会话健康检查。