calico 和 flannel 是 kubernetes 主流 cni 插件，flannel 专注简单覆盖网络（如 vxlan 封装），calico 基于 bgp 实现三层直连与策略控制；选型取决于规模、策略需求及基础设施支持。
Calico 和 Flannel 都是 Kubernetes 中主流的 CNI 插件，但设计目标和实现机制差异明显：Flannel 专注简单可靠的基础连通性，Calico 则兼顾高性能路由与细粒度网络策略控制。
Flannel：轻量覆盖网络，靠封装实现跨节点通信
Flannel 的核心任务是为每个 Node 分配唯一子网，并让 Pod 获得集群内可路由的 IP 地址。它不处理网络策略，只解决“怎么通”的问题。
- 默认使用 VXLAN 模式，在内核层面完成二层封装：源 Pod 发出的数据包经 veth → cni0 → flannel.1（VTEP 设备），被封装成 UDP 报文，通过物理网络发往目标节点
- 目标节点的 flannel.1 收到后解封装，再转发给对应 cni0 网桥，最终送达目标 Pod
- 所有子网信息、主机网段映射关系都存于 etcd，各节点 flanneld 进程监听变更并同步本地路由表
- UDP 模式已弃用；Host-gw 模式仅适用于二层互通环境，要求所有 Node 在同一交换机下
Calico：基于 BGP 的三层直连网络，追求零封装
Calico 不依赖隧道封装，而是把每个 Node 当作一个 BGP Speaker，直接在物理网络上宣告 Pod 子网路由，实现三层可达。
- 每个 Node 上运行 calico-node 组件，通过 BGP 协议向其他 Node 广播本机管理的 Pod 网段（如 10.64.2.0/24）
- 物理路由器或对端 calico-node 接收路由后，自动更新转发表；Pod 流量直接以原始 IP 包形式转发，无额外封装开销
- 支持 NetworkPolicy 原生落地，策略规则由 Felix（calico-agent）实时注入 Linux iptables 或 eBPF，生效快、控制精细
- 适合大规模集群和对延迟敏感场景，但要求底层网络允许 BGP 路由传播（或启用纯内网模式 BIRD + IP-in-IP 封装作为兜底）
选型关键看三点：规模、策略需求、基础设施能力
没有绝对优劣，只有是否匹配当前环境。
- 小集群（
- 中大型集群、需 NetworkPolicy 实施微隔离、已有 BGP 支持或可配置内网路由 → Calico 是更可持续的选择
- 混合云或网络受限环境（如防火墙阻断 BGP/端口）→ 可考虑 Calico 的 IP-in-IP 模式，或 Flannel 的 VXLAN 模式兜底
CNI 插件本质是标准化接口，不是黑盒
CNI 规范本身只定义容器创建/销毁时的网络配置动作（分配 IP、设置路由、插入接口）。Flannel 和 Calico 都是这一规范的具体实现，它们的差异不在“能不能用”，而在于“怎么用得更稳、更安全、更高效”。
- 所有插件都依赖 kubelet 调用 CNI 二进制，传入 network namespace 和配置参数
- IPAM（地址分配）可插拔：Flannel 自带 host-local，Calico 可对接 Kubernetes API 或独立 IPAM
- 真正影响体验的是背后的数据面行为——是走内核 VXLAN 隧道，还是 BGP 路由反射，或是 eBPF 加速转发
