K8s 组网方案深度解析：Flannel vs Calico 原理与选型

前言

在 Kubernetes 集群中，网络是连接所有组件的核心纽带，尤其是 Pod 间的跨节点通信、网络隔离等需求，直接决定了集群的稳定性和性能。目前主流的 K8s 网络插件有 Flannel、Calico、Cilium、Weave Net 等，其中 Flannel 以 "轻量易部署" 成为小集群首选，Calico 以 "高性能 + 强策略" 成为生产环境标配。本文将从组网方案对比、Pod 通信原理、核心插件详解三个维度，带大家彻底搞懂 K8s 组网逻辑。

一、K8s 组网方案整体对比

K8s 本身没有内置网络解决方案，而是通过 CNI（Container Network Interface，容器网络接口）规范，允许第三方插件实现网络功能。CNI 是 CNCF 维护的核心标准，定义了容器网络的配置、接口创建 / 删除、IP 分配等统一接口，所有主流网络插件都需遵循该规范。

主流组网方案核心对比表

|-----------|----------------------------|-------------------------|------------------------------|-------------------|--------------|
| 方案 | 核心原理 | 性能表现 | 功能支持 | 适用场景 | 部署复杂度 |
| Flannel | 隧道转发（VXLAN）/ 静态路由（host-gw） | VXLAN 模式中等，host-gw 模式优秀 | 仅支持网络连通性，原生无 NetworkPolicy | 小集群、测试环境、快速验证场景 | 低（一键部署） |
| Calico | BGP 三层路由 / 可选 IPIP 隧道 | 无隧道封装，转发效率高 | 原生支持 NetworkPolicy、IPAM、流量监控 | 生产环境、高负载集群、需要网络隔离 | 中（需简单配置） |
| Cilium | eBPF 加速转发 | 超高性能，延迟极低 | 高级网络策略、L7 流量控制、多集群互联 | 超大规模集群、高性能场景 | 中高（需熟悉 eBPF） |
| Weave Net | 网桥转发 + 隧道封装 | 性能中等 | 支持网络策略、跨集群互联 | 混合云场景、对部署灵活性要求高 | 中（自动组网） |

扩展知识点：CNI 规范的核心价值

CNI 的核心作用是 "解耦 K8s 与网络实现"：K8s 只需调用 CNI 接口完成容器网络配置，无需关心底层是隧道还是路由；而网络插件只需实现 CNI 定义的接口，即可接入 K8s 集群。这种设计让用户可以根据需求灵活替换网络插件，比如测试环境用 Flannel，生产环境无缝切换到 Calico。

二、K8s 中 Pod 网络通信的三种核心情况

Pod 是 K8s 的最小部署单元，其网络通信可分为 "同 Pod 内容器通信""同 Node 内不同 Pod 通信""跨 Node Pod 通信" 三类，每类的实现原理差异显著。

① 同一个 Pod 内的容器通信

核心原理：共享网络命名空间

K8s 中每个 Pod 都会创建一个特殊的 "pause 容器"，该容器不运行业务逻辑，仅负责管理 Pod 的网络命名空间（Network Namespace）和存储命名空间。Pod 内的所有业务容器都会共享 pause 容器的网络命名空间，意味着它们共用同一个localhost地址、网络接口（lo）和端口。

通信流程：本地回环直接转发

当 Pod 内容器 A 向容器 B 发送数据时，数据包无需经过宿主机网络栈，直接通过本地回环接口（lo）转发，延迟几乎可以忽略。例如：Pod 内有 "app 容器" 和 "sidecar 容器"，app 容器通过localhost:8080即可访问 sidecar 容器的服务。

扩展知识点：pause 容器的核心作用

• 作为 Pod 的 "网络锚点"：维持 Pod 的网络命名空间，即使所有业务容器重启，网络配置也不会丢失；

• 共享存储卷：Pod 内的业务容器可通过 pause 容器挂载相同的存储卷，实现数据共享。

② 同一个 Node 内，不同 Pod 通信

核心原理：网桥转发 + Veth Pair

每个 Node 节点上，CNI 插件会创建一个默认网桥（通常名为cni0），同时为每个 Pod 创建一对 "虚拟网络接口（Veth Pair）"------ 这是一种成对出现的网络设备，一端在 Pod 的网络命名空间内（命名为eth0），另一端挂载到宿主机的cni0网桥上。

通信流程：网桥二层转发

假设 Node 上有 Pod A（IP：10.42.0.10）和 Pod B（IP：10.42.0.11），通信流程如下：

1. Pod A 的应用发送数据包，目标 IP 为 Pod B 的 IP；

1. 数据包通过 Pod A 的eth0接口（Veth Pair 一端），传递到宿主机的 Veth Pair 另一端；

1. 数据包被转发到cni0网桥，网桥通过 ARP 协议查询 Pod B 的 MAC 地址；

1. 网桥将数据包转发到 Pod B 对应的 Veth Pair 一端，最终传递到 Pod B 的eth0接口。

扩展知识点：Veth Pair 的作用

Veth Pair 相当于 "虚拟网线"，将 Pod 的网络命名空间与宿主机的网桥连接起来，解决了 "容器内网络与宿主机网络隔离" 的问题，同时避免了 Pod 直接占用宿主机的物理网卡资源。

③ 不同 Node 上的 Pod 通信

核心难点：跨节点路由打通

不同 Node 上的 Pod 属于不同的 "子网"（例如 Node1 的 Pod 网段为 10.42.0.0/24，Node2 的 Pod 网段为 10.42.1.0/24），默认情况下，这些子网之间没有路由关联，Pod IP 无法跨节点可达。这也是 K8s 网络插件需要解决的核心问题 ------ 如何让跨节点的 Pod 像在同一网段一样通信。

解决方案：依赖网络插件的 "路由 / 隧道" 能力

• 隧道模式（如 Flannel VXLAN）：将 Pod 数据包封装在宿主机 IP 数据包中，跨节点传输后解封装，本质是 "借宿主机网络打通跨节点通道"；

• 路由模式（如 Calico BGP）：在节点间同步 Pod 网段的路由信息，让数据包通过三层路由直接转发，无需封装。

扩展知识点：Pod IP 的特性

Pod IP 是 K8s 集群内的 "虚拟 IP"，仅在集群内部可达，不属于宿主机的物理网卡 IP。当 Pod 被删除或重建时，IP 会重新分配（除非使用 StatefulSet 的固定 IP 功能），因此业务通信应通过 Service 的 ClusterIP 或 Ingress 实现，而非直接依赖 Pod IP。

三、Flannel 方案：用 "隧道" 解决问题（小集群首选）

Flannel 是 K8s 最早的网络插件之一，由 CoreOS 开发，核心定位是 "快速实现集群网络连通性"，无需复杂配置，是小集群和测试环境的首选。其核心依赖 etcd 存储集群网络配置（如 Pod 网段、子网掩码）和节点路由信息，确保所有节点同步网络拓扑。

Flannel 的三种核心模式

Flannel 支持三种转发模式，分别适配不同的网络环境：

1. VXLAN 模式（默认 / 通用）

• 核心原理：基于 VXLAN（Virtual Extensible LAN）技术，在宿主机之间创建 "虚拟隧道"，跨节点的 Pod 数据包会被封装在宿主机 IP 数据包中传输，到达目标节点后解封装。

• 关键组件：

• • VNI（Virtual Network Identifier）：虚拟网络标识，用于区分不同的 VXLAN 网络（Flannel 默认 VNI 为 1）；

• • VTEP（VXLAN Tunnel Endpoint）：隧道端点，每个节点的flannel.1接口就是 VTEP，负责数据包的封装和解封装。

• 适用场景：节点跨二层网络（如公有云不同子网、跨机房部署），无需依赖底层网络设备配置。

• 扩展知识点：VXLAN 封装会在原始数据包基础上增加约 50 字节的头部（含 VNI、VTEP IP 等信息），会轻微增加网络开销，但兼容性极强。

2. host-gw 模式（高性能）

• 核心原理：直接在每个节点的路由表中添加 "Pod 网段→目标节点 IP" 的路由规则，Pod 数据包无需封装，通过宿主机路由直接转发到目标节点。

• 适用场景：节点在同一二层网络（如私有云同网段、本地机房），底层网络支持节点间直接通信。

• 优势与限制：性能接近原生路由，无封装开销；但不支持跨子网部署（二层网络不通时，路由无法生效）。

3. UDP 模式（已淘汰）

• 核心原理：通过 UDP 协议对 Pod 数据包进行封装转发，是 Flannel 最早的模式。

• 缺点：性能极差（UDP 封装延迟高、CPU 占用率高），仅适用于老旧环境或兼容性测试，目前已基本淘汰。

四、Flannel VXLAN 模式通信流程（核心原理图示）

VXLAN 是 Flannel 的默认模式，也是最常用的模式，下面以 "Node A 的 Pod A→Node B 的 Pod B" 为例，详细拆解通信流程。

前提条件

• 集群环境：Node A（IP：192.168.1.10）、Node B（IP：192.168.1.11）；

• Pod 配置：Pod A（IP：10.42.0.10，部署在 Node A）、Pod B（IP：10.42.1.10，部署在 Node B）；

• 核心组件：Node A 和 Node B 均有cni0网桥、flannel.1接口（VTEP）。

通信流程图解

Pod A（10.42.0.10）

↓

Pod A的eth0接口（Veth Pair一端）

↓

Node A的Veth Pair另一端 → cni0网桥（Node A）

↓

Node A路由表匹配：10.42.1.0/24 → 下一跳192.168.1.11（Node B IP）

↓

flannel.1接口（Node A，VTEP）：对数据包进行VXLAN封装（添加VNI=1、源VTEP=192.168.1.10、目标VTEP=192.168.1.11）

↓

Node A物理网卡：将封装后的数据包发送到Node B

↓

Node B物理网卡：接收数据包，转发到flannel.1接口（Node B，VTEP）

↓

flannel.1接口（Node B）：解封装，剥离VXLAN头部，还原原始Pod数据包

↓

cni0网桥（Node B）

↓

Node B的Veth Pair另一端 → Pod B的eth0接口

↓

Pod B（10.42.1.10）

关键说明

• 封装和解封装过程由flannel.1接口自动完成，无需用户干预；

• 节点间的路由信息由 Flannel 通过 etcd 同步，每个节点都会维护一份 "Pod 网段→节点 IP" 的路由表；

• 数据包跨节点传输时，底层使用宿主机的物理网络，无需额外配置网络设备。

扩展知识点：Flannel 与 etcd 的联动

etcd 在 Flannel 中扮演 "网络拓扑数据库" 的角色：

1. Flannel 启动时，会从 etcd 读取集群 Pod 网段配置（如 10.42.0.0/16）；

1. 每个节点的 Flannel 进程会将自身的 "节点 IP+Pod 子网" 信息写入 etcd；

1. 当节点加入 / 退出集群时，Flannel 会自动更新 etcd 中的路由信息，并同步到所有节点的路由表。

五、Flannel 方案总结：优缺点

优点

1. 部署简单：通过kubectl apply一键部署，无需复杂配置，新手友好；

1. 兼容性好：支持所有 K8s 版本和主流云环境（公有云、私有云、本地机房）；

1. 资源占用少：Flannel 进程轻量，对宿主机 CPU、内存消耗极低，不会给集群带来额外负担。

缺点

1. 网络策略支持弱：原生 Flannel 不支持 NetworkPolicy（K8s 原生的网络隔离规则），若需实现 Pod 间访问控制，需额外集成 Calico 等插件；

1. 性能瓶颈：VXLAN 模式的封装 / 解封装会增加延迟和网络开销，不适用于高吞吐、低延迟场景（如大数据、实时计算）；

1. 功能单一：仅解决 "网络连通性" 问题，无流量监控、多集群互联、L7 层路由等高级功能。

六、Calico 方案：用 "路由" 解决问题（生产首选）

Calico 是由 Tigera 公司开发的开源网络插件，核心思想是 "摒弃隧道封装，基于 BGP 协议实现三层路由转发"，以 "高性能 + 强网络策略" 成为生产环境的首选方案。其设计理念是 "将每个节点视为一个路由器"，通过 BGP 协议在节点间同步路由信息，实现 Pod 数据包的直接转发。

Calico 的核心思想

1. 三层路由转发：Pod IP 是三层可达的，跨节点通信无需封装，直接通过路由转发，性能接近原生网络；

1. BGP 路由协议：利用 BGP（边界网关协议，常用于互联网路由交换）在节点间同步 "Pod 网段→节点 IP" 的路由信息，构建全集群的路由表；

1. 网络策略原生支持：通过 Calico NetworkPolicy 实现细粒度的访问控制（如 "只允许 Web Pod 访问 DB Pod 的 3306 端口"）。

扩展知识点：BGP 协议的优势

BGP 是一种 "路径向量协议"，核心优势是 "动态路由同步 + 容错性强"：

• 当节点加入 / 退出集群时，BGP 会自动同步路由信息，无需人工配置；

• 若某节点故障，BGP 会快速切换到备用路由，确保网络连通性；

• 支持大规模集群扩展，理论上可支持上万节点的集群。

Calico 架构组件

Calico 的架构由 5 个核心组件组成，各司其职实现网络功能：

|-------------|-----------------------------------------------------------------|
| 组件 | 作用 |
| Felix | 运行在每个节点的代理进程，核心职责：管理宿主机路由表、配置网络规则（iptables）、维护 Pod 的 veth 接口 |
| Bird | BGP 客户端，运行在每个节点，负责与其他节点的 Bird 进程交换路由信息，同步 Pod 网段路由 |
| Calico IPAM | IP 地址管理器，负责为 Pod 分配集群唯一的 IP 地址，支持静态 IP、动态 IP 分配策略 |
| Calicoctl | Calico 的命令行工具，用于管理 Calico 配置（如网络策略、IP 池、节点配置）、监控网络状态 |
| Typha | 可选组件，用于大规模集群优化：缓存 Calico 的配置信息，减少 Felix 与 etcd 的直接通信，降低 etcd 压力 |

Calico 工作原理（跨节点通信流程）

以 "Node A 的 Pod A（10.43.0.10）→ Node B 的 Pod B（10.43.1.10）" 为例，通信流程如下：

1. IP 分配 ：Calico IPAM 为 Pod A 分配 IP 10.43.0.10，为 Pod B 分配 IP 10.43.1.10，同时在 etcd 中记录 IP 与节点的关联；

1. 路由配置 ：Node A 的 Felix 进程在宿主机路由表中添加规则：10.43.0.10/32 → Pod A的veth接口；同理，Node B 的 Felix 添加规则：10.43.1.10/32 → Pod B的veth接口；

1. 路由同步 ：Node A 的 Bird 进程与 Node B 的 Bird 进程建立 BGP 连接，交换路由信息，Node A 会获取 "10.43.1.0/24 → Node B IP（192.168.1.11）" 的路由，Node B 获取 "10.43.0.0/24 → Node A IP（192.168.1.10）" 的路由；

1. 数据包转发：

• • Pod A 发送数据包，目标 IP 为 10.43.1.10，通过 veth 接口传递到 Node A 的宿主机；

• • Node A 查询路由表，匹配到 10.43.1.0/24 的下一跳是 192.168.1.11，直接将数据包转发到 Node B；

• • Node B 接收数据包后，查询路由表，匹配到 10.43.1.10 的下一跳是 Pod B 的 veth 接口，将数据包转发到 Pod B。

扩展知识点：Calico IPIP 模式

当集群节点跨三层网络（如公有云不同子网）时，BGP 路由无法直接生效（三层网络不转发二层广播），此时 Calico 支持 IPIP 模式：

• 原理：将 Pod 数据包封装在 IP 数据包中（类似 VXLAN，但封装更简单，开销更小）；

• 组件：每个节点会创建tunl0接口，负责 IPIP 封装和解封装；

• 适用场景：节点跨三层网络，无法使用纯 BGP 路由的场景。

七、Flannel vs Calico 深度总结与选型建议

核心维度对比

|-------|---------------------------------|--------------------------------|
| 对比维度 | Flannel | Calico |
| 核心原理 | VXLAN 隧道封装 /host-gw 静态路由 | BGP 三层路由 / 可选 IPIP 隧道 |
| 性能表现 | VXLAN 模式：中等（封装开销）；host-gw 模式：优秀 | 纯 BGP 模式：优秀（无封装）；IPIP 模式：良好 |
| 网络策略 | 原生不支持，需额外集成 | 原生支持，细粒度访问控制 |
| 功能扩展 | 仅支持网络连通性 | 支持流量监控、多集群互联、L7 策略 |
| 资源占用 | 低（轻量进程） | 中（Felix+Bird 进程，占用少量 CPU / 内存） |
| 部署复杂度 | 低（一键部署） | 中（需配置 IP 池、BGP 模式等） |
| 适用规模 | 小规模集群（≤50 节点） | 中大规模集群（≥50 节点，支持上万节点） |

选型建议

1. 小集群 / 测试环境 / 快速验证：选 Flannel

• • 优势：部署简单、资源占用少，能快速实现网络连通性，适合开发测试、POC 验证场景；

• • 注意：若需网络隔离，可搭配 Calico NetworkPolicy 插件（Flannel 负责连通，Calico 负责策略）。

1. 生产环境 / 高负载集群 / 需要网络隔离：选 Calico

• • 优势：高性能、强网络策略、支持大规模扩展，能满足生产环境的稳定性和安全性需求；

• • 注意：纯 BGP 模式适合节点在同一二层网络，跨三层网络可使用 IPIP 模式。

1. 超高性能场景（如实时计算、大数据）：选 Cilium

• • 若对延迟和吞吐量要求极高，可选择基于 eBPF 的 Cilium 插件，其性能比 Calico 提升 30% 以上，且支持更灵活的网络策略。

扩展知识点：Flannel+Calico 混合部署

在部分场景中，可采用 "Flannel 负责网络连通性，Calico 负责网络策略" 的混合方案：

• 部署 Flannel：实现 Pod 跨节点通信；

• 部署 Calico：仅启用 NetworkPolicy 功能，不启用 Calico 的网络路由功能；

• 优势：兼顾 Flannel 的简单性和 Calico 的网络策略能力，适合中小规模生产集群。