K8s网络方案深度解析：Flannel vs Calico 怎么选？

在Kubernetes集群部署中，网络是贯穿始终的核心难题------如何让不同节点上的Pod顺畅通信，直接决定了集群的可用性和性能。而在众多CNI插件中，Flannel和Calico无疑是最主流的两种方案。它们的目标高度一致：实现跨节点Pod互通，但实现路径却大相径庭。今天就带大家深入拆解这两种方案的核心原理、通信流程，以及适用场景，帮你在实际部署中做出最优选择。

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

在聊具体方案前，我们得先明确K8s中Pod通信的三种常见情况，其中跨节点通信是CNI插件的核心解决目标：

同一Pod内的容器通信：同一Pod内的所有容器共享一个网络命名空间，就像在同一台物理机上的不同进程，直接通过localhost就能通信，最简单也最无需额外配置。
同一Node内不同Pod通信：每个Pod都有独立的IP地址，这些Pod会通过veth设备连接到节点的cni0（或docker0）网桥，属于同一网段。因此，它们可以直接通过Pod IP相互通信，无需跨网络转发。
不同Node上的Pod通信（重点难点）：这是最复杂的场景，也是CNI插件必须解决的核心问题。原因很简单：Pod IP是虚拟地址，外部网络并不认识；而不同Node之间只能通过宿主机的物理网卡通信。所以，要实现跨节点Pod通信，必须解决两个关键问题：一是保证所有Pod IP不冲突，二是让Pod IP能准确映射到对应的宿主机节点。

二、Flannel：用"隧道"搞定跨节点通信（小集群首选）

Flannel的核心思路非常直接：既然外部网络不认识Pod的虚拟IP，那就给数据包"穿一层外衣"，让它能在真实网络中传输------这就是典型的Overlay（叠加）网络模式，相当于在真实物理网络之上，再搭建一张虚拟网络。

1. Flannel的三种核心模式

Flannel支持三种部署模式，不同模式在性能和适用场景上差异较大，日常教学中重点了解即可：

**UDP模式：**基于用户态转发，性能最差，仅用于测试或演示，实际生产中几乎不用；
**VXLAN模式：**基于内核态封装，性能适中，配置简单，是目前最常用的模式；
**Host-gw模式：**直接通过路由直连，无需封装，性能较好，但对网络环境要求高（需要节点之间二层互通）。

2. 核心：Flannel VXLAN模式通信流程

VXLAN模式是Flannel的主流选择，我们结合通信流程，就能理解它的核心原理。简单来说，VXLAN模式通过"封装-传输-解封"三个步骤实现跨节点Pod通信：

Pod A发送数据：数据先通过veth设备传递到节点的cni0网桥；
判断目标位置：cni0网桥检查目标Pod IP，发现不在本机节点；
交给Flannel处理：数据被转发到节点的flannel.1虚拟网卡；
封装数据包：flannel.1将原始数据包封装成UDP包（VXLAN协议，默认端口4789），外层封装上宿主机的IP和MAC地址；
跨节点传输：封装后的数据包通过宿主机的物理网卡（如ens160）发送到目标Node；
解封并转发：目标Node的flannel.1虚拟网卡接收数据包后进行解封，还原出原始数据，再通过cni0网桥转发到目标Pod B。

一句话总结Flannel的本质：mac in udp，通过隧道传输虚拟网络数据 。

3. Flannel的优缺点与适用场景

Flannel的核心优势在于"简单"，但也存在明显的性能短板：

优点：部署配置简单，对运维能力要求低；小集群环境下能快速上手，满足基础通信需求。

缺点：数据包的封装和解封过程会带来一定的性能损耗；不支持复杂的网络策略，无法实现精细化的访问控制；高并发场景下性能不足。

适用场景：小规模测试集群、开发环境，或对网络性能要求不高的简单业务场景。

三、Calico：用"路由"实现高性能通信（生产首选）

如果说Flannel是"简单够用"，那Calico就是"性能优先"。Calico的核心思想完全不同：把每一台Node都当成一台独立的路由器 ，不使用隧道封装，不修改原始数据包，而是通过BGP（边界网关协议）同步全网的路由表，实现数据包的三层直接转发。

1. Calico的核心组件

Calico的架构相对复杂，核心组件主要有三个：

CNI插件：负责为Pod创建veth设备，完成Pod与节点网络的对接；
Felix：运行在每个Node上，负责配置节点的路由规则和iptables规则，保障数据包转发和访问控制；
BIRD：BGP协议的客户端，负责在各个Node之间同步路由信息，构建全网统一的路由表。

2. Calico的工作原理（通俗版）

Calico的通信流程比Flannel更直接，没有"封装-解封"的额外步骤：

**Pod发送数据：**数据通过veth设备传递到Node节点；
**查询路由表：**Node节点通过Felix配置的路由规则，查询到目标Pod所在的Node节点；
**直接转发：**通过BGP同步的路由信息，将原始数据包直接转发到目标Node；
**目标Node转发：**目标Node接收数据包后，再通过本地路由规则转发到对应的目标Pod。

核心优势：无封装、无性能损耗，直接三层转发，性能最优。

3. Calico的优缺点与适用场景

优点：性能优异，无数据包封装损耗；支持丰富的网络策略（如入站/出站规则、Pod间访问控制等），适合精细化运维；支持大规模集群部署，扩展性好。

缺点：架构和配置相对复杂，对运维人员的技术能力要求较高；部分模式（如BGP直连）对底层网络环境有一定要求。

适用场景：生产环境、大规模集群，或对网络性能、安全策略有较高要求的业务场景。

四、Flannel vs Calico 核心对比总结

为了方便大家快速选型，整理了两者的核心差异对比表：

对比维度	Flannel	Calico
网络模式	Overlay（叠加网络）	Underlay（路由网络）
是否封包	是（VXLAN/UDP封装）	否（直接转发原始数据包）
性能	一般（存在封装损耗）	高（无损耗，直接转发）
复杂度	低（部署配置简单）	高（架构复杂，需懂BGP/网络策略）
网络策略支持	弱（基本不支持）	强（丰富的访问控制规则）
适用场景	小规模集群、开发/测试环境	生产环境、大规模集群、高性能需求场景

五、实操扩展：Calico的快速部署步骤（基于K8s）

如果大家选择Calico作为生产环境的CNI插件，这里提供一份简单的部署步骤（在master01节点操作）：

上传Calico配置文件：将calico.yaml文件上传到/opt/k8s目录；
修改网段配置：编辑calico.yaml文件，修改CALICO_IPV4POOL_CIDR参数，确保与kube-controller-manager配置的cluster-cidr网段一致（示例：value: "10.244.0.0/16"，Calico默认是192.168.0.0/16，需按需调整）；
**部署Calico：**执行命令 kubectl apply -f calico.yaml；
验证部署结果 ：执行命令 kubectl get pods -n kube-system，查看calico-kube-controllers和calico-node相关Pod是否处于Running状态；
**确认节点就绪：**当所有Calico Pod都运行正常后，执行 kubectl get nodes，可看到节点状态变为Ready。

六、最后总结：如何选择？

如果你是开发/测试人员，需要快速搭建小规模集群，对性能和安全策略要求不高：选Flannel，简单高效；
如果你是运维人员，负责生产环境的大规模集群，对性能、安全策略和扩展性有较高要求：选Calico，性能更优、功能更全；
核心原则：小集群选Flannel，生产集群选Calico。

以上就是Flannel和Calico两种K8s网络方案的深度解析。希望能帮你理清两者的核心差异和适用场景。如果在部署过程中有具体问题，欢迎在评论区交流～

（注：文档部分内容可能由 AI 生成）