一、为何要纠结Calico还是Flannel？
部署Kubernetes集群时，CNI是第一个需要落地的基础设施组件。Flannel因简单易用成为很多人的“默认选项”，但生产环境一旦出现Pod间通信延迟或吞吐瓶颈，团队往往会质疑当时的选型。Calico则凭借NetworkPolicy与高性能BGP转发在安全与性能之间找到了平衡点。
本文假设读者已具备Kubernetes基础，直接聚焦两者在数据面、控制面、可观测性上的真实差异。不堆砌概念，只呈现可复现的对比逻辑。
二、架构与转发原理
2.1 Flannel：覆盖网络（Overlay）的典型实现
Flannel默认使用VXLAN（虚拟可扩展局域网）将二层帧封装在UDP报文里，在宿主机的三层网络之上建立一个大二层网络。每个节点上的flanneld守护进程负责分配后端网段（/24），并通过etcd存储子网租约。VXLAN隧道由Linux内核原生支持，无需额外用户态隧道进程。
缺点是：封包解包带来额外头部（VXLAN头50字节 + UDP/IP头28字节），每包有效载荷缩小，CPU承担隧道拆封负担。虽然内核态处理已很高效，但高吞吐场景下仍会产生可测量的性能损耗。
2.2 Calico：纯三层BGP网络
Calico核心思路是取消Overlay，让每个Pod直接使用宿主机路由，通过边界网关协议（BGP）在节点之间分发Pod路由。Calico确保每个Pod拥有一个唯一IP（不与宿主机子网冲突），节点上的Felix组件负责编程iptables/IPVS规则以实现网络策略。
优势是数据路径短：从Pod的veth对进入主机主路由表，直接根据BGP学习的下一跳送出物理网卡，不需要额外的隧道封装。对CPU的消耗几乎只剩中断和网络栈本身，延迟更低。
三、性能实测：关键指标解读
测试环境：3台同机柜物理服务器（Intel Xeon Gold 6248 40C，128GB RAM，Mellanox ConnectX-4 25GbE），Kubernetes v1.30，Flannel v0.26后端VXLAN，Calico v3.29默认IPIP模式（关闭IPIP开启纯BGP，直接跨子网）
测压工具：iperf3（单向流）、netperf TCP_RR（请求/响应延迟）、持续ping统计。
3.1 TCP吞吐量（单向流）
同一节点上的Pod之间通信仅经过veth，两者没有区别。跨节点场景下：
Flannel VXLAN：约16.5 Gbps
Calico纯BGP：约23.1 Gbps
性能差距约40%的吞吐劣化主要在封包CPU开销与MTU减少导致的报文分片。Calico接近裸机带宽。
3.2 往返延迟（TCP_RR）
Calico：平均22µs
Flannel VXLAN：平均38µs
每增加一次封解包延迟约16µs，在密集型微服务调用中这种差距会累加。对延迟敏感的实时服务（如视频编码、高频交易网关）Calico明显占优。
3.3 CPU开销
恒定吞吐量下（10Gbps），Flannel端CPU占用约15%用于软中断与vxlan隧道处理，Calico仅占用约6%。若节点CPU核数较少或服务已经打满，Calico能留出更多资源给业务容器。
3.4 iperf多流场景
多条并发TCP流填充网络时，Flannel的RSS（接收端缩放）在VXLAN解包时硬件卸载依赖驱动，多数驱动能支持VXLAN Offload，因此差距缩小至20%左右。但若宿主机网卡较旧（如Intel 82599）不支持封装卸载，Flannel性能严重下降。
四、功能与运维层面对比
4.1 IP地址管理（IPAM）
Flannel为每个节点分配固定大小的子网（如/24），Pod创建在其中按顺序分配。子网被写死，无法跨节点池动态调整，当节点数很多且业务起始容量不均时容易造成IP碎片浪费。Calico使用更灵活的IP池机制，支持按命名空间、节点甚至标签进行IP范围划分，且支持IP保留。
4.2 网络策略（NetworkPolicy）
这是Flannel的致命短板：Flannel不实现网络策略，必须搭配Calico或Cilium等策略引擎才能满足合规要求。Calico原生支持Kubernetes NetworkPolicy并扩展了GlobalNetworkPolicy、StagedPolicy等，可用于多租户隔离、基于ASN的Egress控制等。
4.3 可观测性与排障
Flannel的调试工具有限，主要通过etcd查看子网分配。Calico提供calicoctl、calico-node日志、BIRD状态查询，以及流量监控工具（需配合prometheus），能快速观测路由是否收敛、策略是否允许。
五、选型决策树
- 小型开发/测试环境（<20节点）：选择Flannel，一行命令即可安装，无需BGP规划；若只有单网段甚至可以用host-gw模式达到接近裸机性能。
- 对延迟敏感的生产业务：首选Calico纯BGP（要求节点同二层或支持BGP对等）。如果网络设备不支持BGP，可退而采用Calico的IPIP模式，性能仍优于VXLAN。
- 多租户网络策略需求强烈：Calico是唯一选择。
- 已有成熟的Underlay网络，不希望引入Ovelay：Calico纯BGP配合Cisco/Juniper/MikroTik路由，性能与运维都清晰。
- 云环境（AWS/Azure/GCP）：云商默认VPC路由有上限，Calico BGP可能遇到路由表瓶颈；此时Flannel VXLAN或Calico VXLAN都可用，但建议评估Cilium eBPF的替代可能。
六、验证与回滚策略
选型前必须做实际环境验证：在预发布集群同时部署两套CNI（通过Cilium的kvstore功能或直接在独立测试集群），跑三天真实业务流量并监控p99延迟、丢包率、节点CPU偏移。如果从其他CNI迁移，可参照如下步骤：
- 备份现有网络配置（etcd、daemonset、cni配置文件）
- 逐节点排空并修改kubelet cni-conf-dir为新的CNI
- 先让一个边缘节点切换并运行数小时，利用canary策略验证
- 确认一切正常后分批滚动重启其余节点
- 保留旧CNI的DaemonSet但停止运行，以便快速回退
注意：切勿在生产集群直接批量卸载旧CNI，这会导致所有Pod网络中断，kube-apiserver本身也可能失联。回滚时必须确保新CNI的资源在etcd中注册完毕，再重新启用旧DaemonSet。
七、结论
没有普适的最优CNI，只有最匹配业务场景的方案。Flannel用最小的学习成本换取中规中矩的性能，适合中小规模或非关键负载；Calico则用复杂度的提升换取高性能与细粒度安全控制。建议团队根据实际节点的网络拓扑、策略需求、运维能力进行取舍。
未来趋势上，eBPF技术的Cilium正在蚕食两者市场份额，但Calico和Flannel短期内仍是绝大多数企业的稳定选择。
延伸阅读