CNI 网络插件深度对比

选 CNI 看似简单，实则要命——集群上规模、上生产、上安全合规后，换 CNI 基本等于重建集群。 核心分水岭：Overlay（封装） vs Underlay（路由）。

一、底层技术路线图

跨节点流量要么走 Overlay（在现有网络之上叠加虚拟网络，通过封装传输数据），要么走 Underlay（直接利用底层物理网络路由，不封装）：

               Overlay（封装）             Underlay（路由）
               ─────────────             ──────────────
传统 iptables    Flannel (VXLAN)        Calico (BGP)
eBPF 数据面      Cilium (Overlay)        Cilium (Native Routing)

三大派系定位

二、Flannel：最简单的 Overlay

Flannel 由 CoreOS 开发，设计哲学是 "能做最简单的事，绝不做复杂的"。

核心机制

• 每个节点分配一个 /24 子网，Pod IP 从该子网分配
• VXLAN 模式（默认）：Pod 跨节点流量 → flannel.1 隧道设备 → 封装 VXLAN（UDP 8472）→ 对端解封装
• host-gw 模式：省去封装，直接写节点路由表，性能接近 Underlay（要求节点二层连通）
• UDP 模式（已淘汰）：纯用户态封装，性能差

关键特点

• 极简：无依赖（不需要 etcd 存储——Flannel 用 K8s API 做存储后端）
• 无 NetworkPolicy：Flannel 本身不实现网络策略，需要额外方案
• 无加密：VXLAN 流量明文传输
• 性能损耗：VXLAN 封装导致约 10-15% 吞吐下降，延迟增加

适用场景

• 开发测试环境
• 小规模集群（<50 节点）
• 对网络策略无要求
• 团队 K8s 经验不足，需要最快上手

三、Calico：BGP 让 K8s 网络变成数据中心网络

Calico 由 Tigera 开发，核心思想是 "K8s 网络不需要 Overlay，用标准 IP 路由就够了"。

核心机制

• BGP 路由分发：每个节点运行 BGP 客户端（Bird），将 Pod CIDR 路由广播给其他节点或物理网络路由器
• Felix agent：运行在每个节点上，负责编排 iptables 规则实现 NetworkPolicy
• 两种封包模式：
• BGP 模式（推荐、默认）：纯路由，无封装。要求节点二层可达，性能最佳
• IPIP 模式（跨网段时）：简单 IP-over-IP 封装，比 VXLAN 轻但无加密
• eBPF 数据面（可选）：替换 iptables，性能大幅提升

关键特点

• 性能优秀：BGP 模式下无封装损耗，接近宿主机网络
• NetworkPolicy 完整实现：iptables + 细粒度策略，K8s 原生 NetworkPolicy 的最完整实现之一
• 灵活的网络策略：支持 GlobalNetworkPolicy、GlobalNetworkSet 等高级特性
• 与物理网络集成：可配置为将 Pod 路由直接通告到物理路由器，实现 Pod IP 对外直接可达
• Windows 节点支持：TODO（可能存在）

适用场景

• 生产环境（50-500 节点）
• 需要 NetworkPolicy（安全隔离）
• 已有 BGP 基础设施的数据中心
• 裸金属部署（BGP 模式下性能最优）
• 需要混合云/跨集群网络时

注意事项

• BGP 模式下节点必须二层连通（跨可用区需 IPIP 或配置 BGP Peering）
• 大规模集群（500+ 节点）BGP 需要 Route Reflector 架构
• 调试比 Flannel 复杂（calicoctl 命令、BGP 路由排查）

四、Cilium：用 eBPF 重写整个网络栈

Cilium 由 Isovalent（被 Cisco 收购）开发，核心理念是 "eBPF 可以替代 iptables 做任何事情，而且做得更好"。

核心机制

• eBPF 数据面：通过在内核中加载 eBPF 程序，直接接管网络数据路径，完全绕过 iptables
• 两种转发模式：
• Overlay（VXLAN/Geneve）：与 Flannel 类似的封装模式
• Native Routing（Underlay）：直接路由，需底层网络配合
• Hubble：eBPF 驱动的网络可观测性层，可以看清每一个数据包的流向
• CiliumNetworkPolicy：比 K8s NetworkPolicy 更丰富的安全策略（DNS-aware、HTTP-aware、L7 策略）

关键特点

• 性能最佳：eBPF 数据面吞吐更高、延迟更低（相比 iptables 模式提升 2-3 倍）
• 丰富的可观测性：Hubble 提供 L3-L7 流量可视化、服务依赖图、TCP 指标
• L7 安全策略：支持 HTTP/gRPC 层面的请求过滤（如禁止访问 /api/internal）
• K8s 之外的负载：支持非 K8s 工作负载的安全策略
• Cluster Mesh：跨集群服务连通
• 加密：支持 WireGuard 透明加解密

适用场景

• 已上生产但仍可选时：强烈推荐（未来方向）
• 大规模集群（500+ 节点）：eBPF 数据面优势明显
• 需要网络可观测性：Hubble 提供开箱即用的流量可视化
• 高安全合规要求：L7 策略 + DNS 策略 + 加密通信
• 金融/银行/安全行业

注意事项

• 内核要求高：需要 5.10+（eBPF 全力发挥），较老内核可用但受限
• 部署复杂度最高：概念多（eBPF、Hubble、Cluster Mesh），学习曲线陡
• 与安全软件的兼容性：部分安全软件（如某些 HIDS）可能与 eBPF 冲突
• 可卸载等功能可能不完善：功能还在快速迭代中

五、横向对比表

六、按场景的选型建议

迁移注意事项

1. CNI 迁移必须重建节点（或重启 kubelet）：CNI 配置在节点初始化时写入，不能热切换
2. 已有 Service 会短暂中断：因为 kube-proxy 依赖的底层规则会变化
3. NetworkPolicy 需要验证：从 Flannel（无策略）切到 Calico/Cilium（有策略）时，缺省 Deny 会拦截未配置放行的流量
4. 必须事先做好备份和回滚方案：至少保留一个节点的原始 CNI 配置作为参考

关联页面