1. 容器网络方案选型之争：Flannel与Calico深度对比
在容器化部署成为主流的今天，网络方案的选择直接决定了集群的通信效率和安全隔离能力。作为Kubernetes生态中最流行的两款CNI插件，Flannel和Calico的设计哲学截然不同——前者追求极简的Overlay网络，后者则主打高性能的BGP路由。我在多个生产集群中实测发现，当Pod数量超过500个时，两者的性能差异可达40%以上。本文将拆解它们各自的实现原理、适用场景和那些官方文档不会告诉你的调优技巧。
2. 核心架构与工作原理
2.1 Flannel的Overlay网络模型
Flannel采用经典的"覆盖网络"设计，通过在主机间建立虚拟隧道（默认为VXLAN）实现跨节点通信。其核心组件包括：
- flanneld：运行在每个节点的守护进程，负责分配子网租约
- backend：实际的数据平面实现（支持VXLAN、host-gw等）
当Pod A（10.244.1.2）访问Pod B（10.244.2.3）时，数据流向如下：
- 流量从Pod A发出，经cni0网桥进入主机网络栈
- flanneld查询etcd获取目标Pod所在节点的子网信息
- 通过VXLAN隧道将原始L2帧封装在UDP报文中（默认使用8472端口）
- 目标节点解封装后，通过cni0网桥送达Pod B
关键细节：Flannel默认每台主机分配一个/24子网，这意味着单个集群最多支持256个节点。这个值可以通过--subnet-length参数调整，但需要提前规划好IP地址空间。
2.2 Calico的BGP路由方案
Calico摒弃了Overlay带来的性能损耗，直接利用BGP协议宣告Pod路由。其架构包含：
- Felix：节点代理，负责配置路由和ACL规则
- BIRD：BGP客户端，与邻居交换路由信息
- Typha：用于大规模集群的Felix连接中继
典型通信流程：
- 每个Pod获得独立IP，并连接到calico虚拟接口
- Felix将本地Pod路由信息注入内核路由表
- BIRD通过BGP协议将路由广播给其他节点
- 跨节点通信直接通过底层网络转发，无需封装
实测数据：在同等硬件条件下，Calico的Pod间延迟比Flannel低15-20ms，吞吐量高出30%以上。但需要注意，这种方案要求底层网络支持主机间直接路由。
3. 功能特性对比
3.1 网络策略支持
Calico的最大优势在于其企业级网络策略能力：
- 支持L3-L4的精细ACL控制
- 可定义基于标签的出入站规则
- 内置威胁检测和日志审计功能
示例策略：限制default命名空间的Pod只能访问mysql服务的3306端口
apiVersion: projectcalico.org/v3 kind: NetworkPolicy metadata: name: mysql-access spec: selector: role == 'db' ingress: - action: Allow protocol: TCP destination: ports: [3306]相比之下，Flannel需要依赖Kubernetes原生的NetworkPolicy，功能较为基础。且必须安装kube-proxy配合iptables/ipvs实现，性能损耗明显。
3.2 安装与维护成本
Flannel的极简哲学：
- 单二进制部署，无外部依赖
- 配置仅需指定网络CIDR：
{ "Network": "10.244.0.0/16", "Backend": { "Type": "vxlan" } }Calico的复杂需求：
- 需要部署多个组件（Felix/BIRD/Typha）
- 依赖etcd或Kubernetes API存储数据
- BGP模式要求调整底层网络设备配置
- 镜像拉取问题常见（特别是离线环境）
针对calico镜像拉取失败的问题，建议采用以下方案：
- 提前下载离线镜像包：
docker pull calico/node:v3.26.0 docker save -o calico-node.tar calico/node:v3.26.0- 使用私有镜像仓库同步
- 修改manifest中的imagePullPolicy为IfNotPresent
4. 性能实测数据
在3节点集群（16核/32GB内存/10Gbps网络）的测试结果：
| 指标 | Flannel(VXLAN) | Calico(BGP) |
|---|---|---|
| Pod间延迟(avg) | 1.8ms | 0.3ms |
| TCP吞吐量 | 6.7Gbps | 9.2Gbps |
| 1000个Pod启动时间 | 4分12秒 | 3分45秒 |
| CPU占用(1000Pod) | 13% | 18% |
| 内存占用(per节点) | 120MB | 350MB |
值得注意的是，当启用网络策略后，Calico的CPU占用会上升至25%左右，而Flannel由于依赖iptables，可能出现规则爆炸问题。
5. 选型建议与调优技巧
5.1 何时选择Flannel
- 中小规模集群（节点数<50）
- 对网络策略需求简单
- 底层网络环境不可控（如公有云VPC）
- 资源受限的边缘设备
调优建议：
- 将backend从VXLAN改为host-gw可提升20%性能（需节点间二层互通）
- 调整MTU避免分片（公有云环境通常需要设为1400）
- 定期清理etcd中过期租约
5.2 何时选择Calico
- 需要符合等保要求的金融/政务云
- 混合云或多机房部署场景
- 高性能计算类应用（如AI训练）
- 已有专业网络运维团队
高级配置示例：优化BGP邻居设置
apiVersion: projectcalico.org/v3 kind: BGPConfiguration metadata: name: default spec: logSeverityScreen: Info nodeToNodeMeshEnabled: false # 关闭全互联模式 asNumber: 64512 listenPort: 179 prefixAdvertisements: - cidr: 192.168.0.0/16 aggregationLength: 246. 常见问题排查指南
6.1 Flannel典型故障
问题现象：Pod跨节点不通，flanneld日志显示"failed to acquire lease"
- 检查etcd集群健康状态
- 确认--subnet-marker参数与实际网络匹配
- 清理/run/flannel/subnet.env后重启服务
问题现象：VXLAN隧道建立失败
- 确认8472端口未被占用
- 检查内核模块加载：lsmod | grep vxlan
- 禁用firewalld或放行VXLAN流量
6.2 Calico常见异常
问题现象：BGP邻居无法建立
- 验证节点间TCP 179端口可达性
- 检查asNumber配置一致性
- 通过calicoctl node status诊断
问题现象：网络策略未生效
- 确认Felix日志无deny记录
- 检查Pod标签是否匹配selector
- 禁用IPIP模式测试（可能干扰策略执行）
在最近一次金融云项目中，我们遇到Calico策略导致性能下降的问题。最终发现是默认的profile规则与自定义策略冲突，通过以下命令解决：
calicoctl delete profile default7. 混合部署方案
对于需要兼顾性能和安全的大型集群，可以采用分层网络设计：
- 核心业务区使用Calico+BGP保证性能
- 边缘计算节点采用Flannel简化部署
- 通过NetworkPolicy实现分区隔离
具体实现步骤：
- 部署Cilium作为统一控制平面
- 配置ClusterIP范围分割
- 设置namespace标签进行区域划分
- 使用egress网关处理跨区流量
这种架构在某车企的300节点集群中，实现了15%的性能提升同时满足等保2.0要求。
