K8s 网络插件选型：Flannel vs Calico 深度对比

前言

[一、先搞懂：K8s Pod 通信的 3 种核心场景](#一、先搞懂：K8s Pod 通信的 3 种核心场景)

[1. 同一 Pod 内的容器通信（最简单）](#1. 同一 Pod 内的容器通信（最简单）)

[2. 同一 Node 内的不同 Pod 通信（较简单）](#2. 同一 Node 内的不同 Pod 通信（较简单）)

[3. 不同 Node 上的 Pod 通信（核心难点）](#3. 不同 Node 上的 Pod 通信（核心难点）)

[二、Flannel：用 "隧道" 搞定小集群，简单优先](#二、Flannel：用 “隧道” 搞定小集群，简单优先)

[核心原理：数据包的 "打包之旅"](#核心原理：数据包的 “打包之旅”)

[Flannel 的 3 种模式（快速了解）](#Flannel 的 3 种模式（快速了解）)

[Flannel 的优缺点](#Flannel 的优缺点)

[三、Calico：用 "路由" 追求极致性能，生产首选](#三、Calico：用 “路由” 追求极致性能，生产首选)

[核心原理：路由表的 "智能同步"](#核心原理：路由表的 “智能同步”)

[Calico 的核心组件（不用深扒，知道作用即可）](#Calico 的核心组件（不用深扒，知道作用即可）)

[Calico 的优缺点](#Calico 的优缺点)

[四、Flannel vs Calico 终极对比表](#四、Flannel vs Calico 终极对比表)

六、选型建议：怎么选才不踩坑？

总结

前言

在 Kubernetes 集群中，网络是连接所有 Pod 的 "神经网络"------ 无论 Pod 分布在哪个节点，都要实现无感知通信。而 CNI（容器网络接口）插件正是解决这一问题的核心，其中Flannel 和Calico是最主流的两种方案。它们目标一致，但实现路径截然不同：一个用 "隧道" 简化部署，一个用 "路由" 追求性能。本文将从原理、对比、场景三个维度拆解，帮你快速选型！

一、先搞懂：K8s Pod 通信的 3 种核心场景

在聊插件之前，我们得先明确 K8s 网络要解决的核心问题。Pod 的通信本质分为 3 种情况，前两种简单，真正的难点在第三种：

1. 同一 Pod 内的容器通信（最简单）

同一个 Pod 里的所有容器共享一个网络命名空间，相当于在同一台物理机上 ------ 直接用 localhost 就能通信（比如 Pod 内的应用容器和日志收集容器）。

2. 同一 Node 内的不同 Pod 通信（较简单）

每个 Pod 都有独立的虚拟 IP，且通过 veth 设备连接到节点的 cni0（或 docker0）网桥，属于同一网段。就像同一局域网内的两台电脑，直接用 Pod IP 就能互通。

3. 不同 Node 上的 Pod 通信（核心难点）

这是 CNI 插件的核心使命！因为 Pod IP 是虚拟地址，不同节点之间只能通过物理网卡通信，必须解决两个关键问题：

Pod IP 不能冲突（集群内全局唯一）；
虚拟的 Pod IP 要能 "映射" 到对应的节点物理 IP，让数据包跨节点传输。

而 Flannel 和 Calico，正是针对第三种场景给出的两种截然不同的解决方案。

二、Flannel：用 "隧道" 搞定小集群，简单优先

Flannel 的设计思路特别直接：既然外部网络不认识 Pod 的虚拟 IP，那就给数据包 "穿件外套" 再传输 ------ 这就是Overlay 网络（在物理网络之上搭建虚拟网络），也叫 "隧道模式"。

核心原理：数据包的 "打包之旅"

以最常用的VXLAN 模式（内核态封装，性能最优）为例，跨节点通信流程如下：

当 Pod A（IP：10.244.1.2）向 Pod B（IP：10.244.4.2）发送数据时，数据传输流程如下：

数据首先到达源节点的 cni0 网桥，发现目标 Pod 不在当前节点
数据被路由至 Flannel 虚拟网卡 flannel.1
flanneld 进程将数据包封装为 UDP 格式（采用 VXLAN 协议，端口 4789），并添加节点物理 IP 作为外层地址（例如：源节点 192.168.42.2 → 目标节点 192.168.42.5）
封装后的数据包通过物理网卡 ens160 发送至目标节点
目标节点接收数据后，通过 flannel.1 网卡解封数据包，还原原始 Pod IP 信息
最终数据通过目标节点的 cni0 网桥转发至 Pod B

简单说：Flannel 是 "mac in UDP" 的封装模式，把 Pod 的虚拟 IP 包在物理 IP 里传输，绕开了跨节点虚拟 IP 识别的问题。

Flannel 的 3 种模式（快速了解）

模式	特点	适用场景
UDP	用户态转发，性能较差（存在二次拷贝）	测试环境、学习场景（生产环境基本不使用）
VXLAN	内核态封装，性能均衡，配置简单	中小规模集群首选方案（推荐）
Host-gw	无封装，采用直接路由转发	网络拓扑支持直连的特殊场景（对网络要求高）

Flannel 的优缺点

优点：

部署极简：几乎零配置，一键安装；
稳定性高：逻辑简单，故障率低；
兼容性好：支持所有 K8s 环境，无需特殊网络规划。

缺点：

性能损耗：封装 + 解封过程会消耗 CPU，高并发场景下瓶颈明显；
功能薄弱：不支持网络策略（比如限制 Pod 间访问）；
扩展性一般：集群节点过多时，隧道转发效率下降。

三、Calico：用 "路由" 追求极致性能，生产首选

如果说 Flannel 是 "简化派"，Calico 就是 "性能派"。它的核心思想是：把每个 K8s 节点当成一台路由器 ，通过 BGP（边界网关协议）同步路由表，实现数据包的三层直接转发 ------ 这就是Underlay 网络（基于物理网络的路由转发）。

核心原理：路由表的 "智能同步"

Calico 没有隧道封装，而是让数据包 "直达目的地"，流程如下：

Pod C（IP：10.100.1.2）发送数据到 Pod D（IP：10.100.2.3）；
源节点通过 Felix 组件（Calico 的核心代理）查询本地路由表，发现 Pod D 在目标节点；
源节点的 BIRD 组件（BGP 客户端）已通过集群内 BGP 协议，同步了目标节点的路由信息；
数据包直接通过物理网卡转发到目标节点（无任何封装）；
目标节点通过路由表定位到 Pod D，直接转发数据。

简单说：Calico 是 "路由直达" 模式，每个节点都知道 "哪个 Pod 在哪个节点"，数据包不用封装，直接跨节点转发，性能几乎接近物理机通信。

Calico 的核心组件（不用深扒，知道作用即可）

组件核心功能

组件	核心作用
CNI 插件	为 Pod 创建虚拟网卡(veth)，实现与节点网络的对接
Felix	维护节点路由规则和 iptables 策略，确保数据包正确转发
BIRD	通过 BGP 协议在集群内同步路由表，充当路由器间的"通信桥梁"

Calico 的优缺点

优点：

性能极致：无封装、无解包，CPU 损耗极低，支持高并发场景；
功能强大：支持网络策略（NetworkPolicy），可精细化控制 Pod 访问权限（比如只允许前端 Pod 访问后端 Pod）；
扩展性好：支持大规模集群（数千节点也能稳定运行），支持跨集群通信。

缺点：

配置复杂：需要一定的网络知识（比如 BGP、路由规划），部署和排障门槛高；
网络要求高：依赖物理网络支持三层转发，部分云环境或私有网络需要特殊配置；
资源占用略高：组件较多，对节点资源有一定消耗。

四、Flannel vs Calico 终极对比表

对比维度	Flannel	Calico
网络模式	Overlay（隧道封装）	Underlay（路由转发）
数据包处理	封装 + 解封（存在性能损耗）	直接转发（无封装）
性能表现	中等（适合中小流量场景）	优异（适合高并发、大流量场景）
部署复杂度	简单（一键部署，无需配置）	较高（需网络规划，支持 BGP）
网络策略	不支持	支持（提供精细化权限控制）
适用集群规模	小规模（100 节点以内）	中大规模（生产环境首选）
核心优势	简单易用、稳定性高、兼容性强	高性能、功能全面、扩展性优秀

六、选型建议：怎么选才不踩坑？

小集群 / 测试环境 / 学习场景：选 Flannel不用纠结网络配置，一键部署就能用，满足基本通信需求，稳定性拉满。
生产环境 / 大集群 / 高并发场景：选 Calico性能和功能都是刚需 ------ 高并发流量需要低损耗，生产环境需要网络策略做安全隔离，Calico 是最优解。
特殊场景补充：
- 若集群运行在公有云（如 AWS、阿里云），且需要对接云厂商网络策略：优先 Calico；
- 若网络环境受限（不支持 BGP、三层转发）：选 Flannel VXLAN 模式；
- 若追求极致性能且网络环境支持：Calico + Host-gw 模式（比 VXLAN 更快）。

总结

Flannel 和 Calico 没有绝对的优劣，只有 "适合与否"：

Flannel 的核心是 "简单"，用性能损耗换部署成本降低；
Calico 的核心是 "性能"，用配置复杂度换生产级稳定性和功能。