系列导航
本系列从 Pod 网络连通入手,逐步展开到 K8s 网络全景。
① 概念 → ② Flannel → ③ Calico → ④ 流量路径 → ⑤ Cilium → ⑥ 对比 → ⑦ 排障 ‖ ⑧ 开发 → ⑨ 多网卡 → ⑩ AI 演进
| 顺序 | 文章 | 定位 |
|---|---|---|
| ① | 概念与入门 | 基础——主机网络、Docker 网络、CNI 标准、方案分类树 |
| ② | Flannel 详解 | CNI 实现——Overlay 封装(UDP/VXLAN/HostGW)与抓包 |
| ③ | Calico 详解 | CNI 实现——三层路由(BGP/IPIP)+ NetworkPolicy |
| ④ | 流量路径全解析 | 全貌——Pod/Service/Ingress/Egress,揭示 CNI 的边界 |
| ⑤ | Cilium 详解 | 超越 CNI——eBPF 统一 Pod + Service + L7 + Hubble |
| ⑥ | 本篇 - 插件对比与选型 | 选型——5 插件横向对比 + 决策树 |
| ⑦ | 排障思路与常用命令 | 运维——工具链 + 场景排查 + 性能 |
| — | 核心路径 ↑ | 扩展展望 ↓ |
| ⑧ | CNI 插件开发指南 | 扩展——基于 CNI 规范开发自定义插件 |
| ⑨ | 多网卡方案详解 | 进阶——Multus + SR-IOV/ipvlan 多网口实战 |
| ⑩ | AI 时代网络演进 | 展望——GPU 网络、eBPF 加速、未来方向 |
CNI(Container Network Interface)意为容器网络接口,它是一种标准的设计,为了让用户在容器创建或销毁时都能够更容易地配置容器网络。
由Google和CoreOS联合定制的网络标准,是Kubernetes网络插件的基础。基于CNI标准,有如下常见的CNI网络插件产品。

目前主流的网络插件是Flannel、Calico、Cilium。这些插件既可以确保满足Kubernetes的网络要求,又能为Kubernetes集群管理员提供他们所需的某些特定的网络功能。
本文将通过Kubernetes集群中不同网络环境下,通过Pod之间流量分析来比较Flannel、Calico、Cilium、Canal处理网络流量的不同之处。
1. Canal网络插件介绍
2020年废弃不再维护,项目维护者认为应该将精力放在为flannel和calico项目增加功能上,而非深度整合两者。
Canal结合Flannel和Calico的网络功能。将Flannel叠加网络层和VXLAN封装与Calico的网络组件(如 Felix、主机代理和网络策略)集成在一起,
使用Flannel处理节点间的流量,使用 Calico 处理节点内流量和网络策略(Calico网络策略,可以在网络方面提供项目/命名空间隔离)。
总之,对于希望利用具有网络策略规则的覆盖网络模型来加强安全性的企业来说,Canal 是一个不错的选择。
优点: Flannel叠加网络且支持网络策略、提供了统一部署Flannel和Calico的方法
缺点: Flannel和Calico之间的集成度不高

Canal 要求在节点上安装
iptables或xtables-nft包。
2. Calico网络插件介绍
基于BGP的纯三层网络方案,与OpenStack\k8s\aws\gce都有良好集成,默认配置不启用任何网络策略
Calico在每个计算节点上实现一个高效的vRouter(使用Linux Kernel),负责数据转发。每个vRouter使用BGP协议在整个Calico网络中传播当前节点上运行的workload的路由信息。
这确保了workload之间的数据流量通过IP路由互联,无需额外的NAT、隧道或Overlay网络。此外,Calico还基于iptables提供了丰富和灵活的网络策略,用于实现多租户隔离、安全组和其他可达性限制。
优点: 支持网络策略、网络性能高、支持 SCTP
缺点: 不支持组播
3. Flannel网络插件介绍
Flannel通过给每个宿主机分配子网的方法为容器提供虚拟网络。基于
Linux TUN/TAP,使用UDP封装IP包来创建overlay网络,并依靠etcd来管理网络分配数据。
Flannel 是为 K8s 配置 L3 网络结构的简单方法。Flannel在每台主机上运行一个名为flanneld的二进制 Agent,flanneld负责从更大的预配置地址空间中为每台主机分配子网。
Flannel 通过k8s API或直接使用etcd来存储网络配置、分配的子网、以及其他辅助数据(例如主机的公共 IP)。数据包使用某种后端机制来转发,默认封装为 VXLAN。
默认情况下,封装的流量是不加密的。Flannel 提供了两种加密方案:
- IPSec:使用 strongSwan 在 Kubernetes worker 之间建立加密的 IPSec 隧道。它是加密的实验性后端。
- WireGuard:比 strongSwan 更快的替代方案。
优点: 支持IPsec加密、单一二进制安装和配置
缺点: 不支持网络策略、无法通过单个守护进程运行多台主机和多个网络,但可以为每台主机运行多个守护进程。

4. Weave网络插件介绍
Weave Net是一个去中心化的容器网络方案,各个host上的wRouter间通过建立Full Mesh的TCP连接,并通过Gossip来同步控制信息。
这种方式省去了集中式的K/V Store,一定程度上简化了部署复杂性,Weave将其称为data centric,而非Raft或者Paxos的algorithm centric。
在数据平面上,Weave通过UDP封装实现L2 Overlay,封装支持两种模式,一种是在用户空间运行的sleeve mode(Flannel的udp),另一种是在内核空间运行的fastpath mode(Flannel的vxlan)。
Sleeve mode通过pcap设备在Linux bridge上截获数据包并由wRouter完成UDP封装,支持对L2 traffic进行加密,还支持Partial Connection,但是性能损失明显。Fastpath mode通过OVS的odp封装VxLAN并完成转发,wRouter不直接参与转发,而是通过下发odp流表的方式控制转发,这种方式可以明显地提升吞吐量,但是不支持加密等高级功能。
fastpass相当于vxlan overlay, sleeve相当于udp overlay, 改进点在于:1. 支持网络策略;2.去除额外的中心化容器地址分配器,将配置存储功能集成至服务内部;
优点: 内核级通信、网络策略和加密支持、提供有偿故障排除支持
缺点: 由于基于内核的路由选择,只支持 Linux 系统、默认加密标准导致网络速度降低
5. Cilium网络插件介绍
Cilium 在 Kubernetes 中启用网络和网络策略(L3、L4 和 L7)。默认情况下,Cilium 使用 eBPF 技术在节点内部路由数据包,并使用 VXLAN 将数据包发送到其他节点。也可以配置非封装的技术。
Cilium 推荐大于 5.2 的内核版本,从而充分利用 eBPF 的能力。Kubernetes worker 需要打开 TCP 端口 8472(VXLAN)和 TCP 端口 4240(健康检查)。此外,还必须为健康检查启用 ICMP 8/0。
默认情况下,Cilium 不允许 Pod 与其他节点上的 Pod 通信。要解决此问题,请启用 Ingress Controller 以使用 “CiliumNetworkPolicy” 进行跨节点路由请求。
选择 Cilium CNI 并为新集群启用项目网络隔离后,配置如下:
| |
6. 各插件 CNI 功能对比
下表总结了 Rancher 中每个 CNI 网络插件支持的不同功能:
| 提供商 | 网络模型 | 路由分发 | 网络策略 | 网格 | 外部数据存储 | 加密 | 加密协议 | Ingress/Egress 策略 | 企业支持 |
|---|---|---|---|---|---|---|---|---|---|
| Canal | 封装(UDP/VXLAN/IPIP)、未封装(host-gw/BGP) | 否 | 是 | 否 | K8s API | 是 | IPsec、WireGuard | 是 | 否 |
| Flannel | 封装(UDP/VXLAN)或未封装(host-gw) | 否 | 否 | 否 | K8s API | 是 | IPsec | 否 | 否 |
| Calico | 封装(VXLAN/IPIP)或未封装(BGP) | 是 | 是 | 是 | Etcd 和 K8s API | 是 | IPsec | 是 | 是 |
| WeaveNet | 封装(UDP/VXLAN) | 是 | 是 | 是 | 否 | 是 | WireGuard | 是 | 是 |
| Cilium | 封装(VXLAN) | 是 | 是 | 是 | Etcd 和 K8s API | 是 | IPsec | 是 | 否 |
- 网络模型:封装或未封装。如需更多信息,请参阅 CNI 中使用的网络模型。
- 路由分发:一种外部网关协议,用于在互联网上交换路由和可达性信息。BGP 可以帮助进行跨集群 pod 之间的网络。此功能对于未封装的 CNI 网络插件是必须的,并且通常由 BGP 完成。如果你想构建跨网段拆分的集群,路由分发是一个很好的功能。
- 网络策略:Kubernetes 提供了强制执行规则的功能,这些规则决定了哪些 service 可以使用网络策略进行相互通信。这是从 Kubernetes 1.7 起稳定的功能,可以与某些网络插件一起使用。
- 网格:允许在不同的 Kubernetes 集群间进行 service 之间的网络通信。
- 外部数据存储:具有此功能的 CNI 网络插件需要一个外部数据存储来存储数据。
- 加密:允许加密和安全的网络控制和数据平面。
- Ingress/Egress策略:允许你管理 Kubernetes 和非 Kubernetes 通信的路由控制。
7. CNI 社区人气
下表总结了不同的 GitHub 指标,了解每个项目的受欢迎程度和活动。数据收集于 2023 年 8 月
| 提供商 | 项目 | Stars | Forks | Contributors |
|---|---|---|---|---|
| Canal | https://github.com/projectcalico/canal | 704 | 104 | 21 |
| Flannel | https://github.com/flannel-io/flannel | 8.2k | 2.9k | 223 |
| Calico | https://github.com/projectcalico/calico | 4.9k | 1.2k | 320 |
| Weave | https://github.com/weaveworks/weave/ | 6.5k | 673 | 87 |
| Cilium | https://github.com/cilium/cilium | 16.3k | 2.4k | 640 |
8. CNI 网络性能
理论上说,这些CNI工具的网络速度应该可以分为3个速度等级。
最快的是Romana、Gateway模式的Flannel、BGP模式的Calico。
次一级的是IPIP模式的Calico、Swarm的Overlay网络、VxLan模式的Flannel、Fastpath模式的Weave。
最慢的是UDP模式的Flannel、Sleeve模式的Weave。
Bare > Flannel(host-gw) ~ Calico(bgp) > Calico(ipip) ~ Flannel(vxlan) > Flannel(udp)

测试容器网络速度的具体方法
9. 选型决策树
从网络环境出发,按决策树选择最合适的方案:
| |
10. 选型推荐
按场景选择
| 场景 | 推荐插件 | 理由 |
|---|---|---|
| 开发环境、快速部署、追求简单 | Flannel | 配置最简单、社区成熟、学习成本低 |
| 生产环境、高网络性能、需要网络策略 | Calico | BGP 纯三层方案,性能优异,策略能力强 |
| 低内核版本生产环境、网络策略是强需求 | Canal | Flannel + Calico 策略层,兼容更老内核,2020 年已停止维护需慎重 |
| 高安全需求、可观测性、高性能 | Cilium | eBPF 技术栈,未来发展方向,L3/L4/L7 策略能力强 |
| 多集群跨节点通信、全 mesh 需求 | WeaveNet | 去中心化设计,全 mesh 连接,支持加密 |
推荐优先级(2024年现状)
首选:Calico / Cilium
- 社区最活跃,商业支持完善
- 性能领先,网络策略能力强
- 大型生产环境验证充分
次选:Flannel
- 学习成本最低,配置简单
- 社区活跃度下降,功能迭代慢
- 无网络策略能力,生产环境需额外补充
不推荐:Canal / WeaveNet
- Canal 2020 年已停止维护
- WeaveNet 社区活跃度低,问题修复慢
11. 常见坑
| 问题 | 说明 |
|---|---|
| VXLAN 的 VLAN 透传问题 | 很多机房交换机对 VXLAN 包(UDP 8472)有限速或校验,选型前需提前确认 |
| BGP 权限问题 | 公有云 VPC 一般不允许运行 BGP,只能用 Overlay 方案 |
| MTU 不匹配 | Overlay 封装增加 ~50 字节包头。若 Pod MTU 也是 1500,会频繁分片或丢包。Overlay 网络 Pod MTU 应设为 1450 |
| ARP 表爆炸 | Calico 纯三层无 ARP 问题,但 VXLAN 模式下 FDB 表项随节点数线性增长,大集群注意内核参数调优 |
| NetworkPolicy 性能 | iptables 实现的 NetworkPolicy 在规则 >1 万条时性能显著下降,大集群建议用 eBPF 模式(Cilium / Calico eBPF) |
