夜雨聆风给客户做私有化部署集群方案时，经常会有人问：
你们用的什么网络插件？为什么不用 Cilium？
问这话的，多半是客户或团队里比较懂行的人，语气里有时还带着一点「你们是不是技术栈偏旧」的意味。
这个问题很难用一句话回答。CNI 选型这件事，和「哪个更先进」关系不大，和「你的环境允许你用什么」关系很大。同一套业务，装到自建机房、银行信创环境、或者客户自己复制出来的几台虚拟机上，答案可能完全不一样。
下面把几个主流插件过一遍。重点不是参数表——那种网上一搜一大把——而是每个方案在什么条件下会咬人。
先说清楚 CNI 管哪一段
K8s 自己不实现网络，只规定了几条底线：
每个 Pod 有独立 IP Pod 之间可以直接通信，不需要 NAT Pod 和 Node 之间可以直接通信
具体怎么实现，交给 CNI。插件通常要做这些事：
给 Pod 分 IP（IPAM） 打通跨节点 Pod 通信（差异最大的地方） 实现 NetworkPolicy（可选，不是人人都做） 有的还会顺手接管 Service 转发、加密、可观测性
第 2 条是所有分歧的源头。跨节点通信本质上就两条路：
封装（Overlay）把 Pod 的包塞进另一个包里，从物理网卡发出去，对端拆开。VXLAN、IPIP、Geneve 都是这路。好处是不太挑底层网络；坏处是有封装开销，抓包排障要多剥一层。
路由（Underlay / 直接路由）不封装，让物理网络知道「这个 Pod 网段在哪台机器」。靠 BGP 或静态路由。性能好，但底层网络得配合。
记住这个二分法，后面看插件就清楚多了。
Flannel：够用，而且经常被低估
怎么干活
默认 VXLAN。每个节点起一个 flannel.1 当 VTEP，跨节点流量封装成 UDP 8472 发出去。路由表大概长这样：
ip route10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.110.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink
本节点网段走 cni0，别的节点网段丢给 flannel.1。逻辑简单到几乎不用解释。
好在哪
一个 YAML 就能装，配置项很少 出问题用 ip route、bridge fdb、tcpdump基本能定位对内核版本要求低，老系统也能跑 资源占用小
k3s 默认还带着 Flannel，这个选择本身说明问题。
坑在哪
不支持 NetworkPolicy。装了 Flannel 的集群，你写的 NetworkPolicy 对象能创建、能进 etcd，然后完全不生效——不报错，也不拦截。等安全审计才发现隔离压根没起作用。这个坑很多人踩过。
VXLAN 的 MTU。封装大约占 50 字节，flannel.1 的 MTU 一般是 1450 而不是 1500。底层 MTU 再叠一层隧道时，容易出现「小包通、大包卡死」：ping 通，小接口正常，一传文件就 hang。
ping <对端节点IP> -M do -s 1472-M do 禁止分片，1472 + 头刚好 1500。通了说明物理链路 MTU 没问题。
规模上去之后偏吃力。节点多了，转发表和封装开销会上来；也几乎没什么可观测能力，出问题只能自己抓包。
真实踩过的坑
有个环境五台虚拟机都是同一模板克隆的，结果所有节点 flannel.1 的 MAC 一模一样，VXLAN 转发表彻底乱掉：同节点通，跨节点全不通。
kubectl get node -o yaml | egrep -i vtepflannel.alpha.coreos.com/backend-data: '{”VNI”:1,”VtepMAC”:”46:8a:1f:c3:7e:2b”}'flannel.alpha.coreos.com/backend-data: '{”VNI”:1,”VtepMAC”:”46:8a:1f:c3:7e:2b”}'flannel.alpha.coreos.com/backend-data: '{”VNI”:1,”VtepMAC”:”46:8a:1f:c3:7e:2b”}'
根因是 /etc/machine-id 相同，systemd 按它生成虚拟网卡 MAC。严格说不完全是 Flannel 的锅，但它确实说明：Overlay 方案对底层一致性很敏感。
什么时候选
小规模、内部环境、不需要网络策略、没有专职网络同学。或者要装到各种不可预期的客户机器上，需要一个「破机器也能跑起来」的方案。
Calico：企业环境里最稳的那个
怎么干活
模式比较多：
BGP（无封装）：节点跑 BIRD，把 Pod 网段通告出去，性能最好 IPIP：跨子网封装，同子网直连，折中方案 VXLAN：底层不支持 BGP 时用，和 Flannel 思路接近
数据平面也有两套：传统 iptables/ipvs，以及后来的 eBPF。
好在哪
NetworkPolicy 扎实。除了标准 NetworkPolicy，还有 GlobalNetworkPolicy、NetworkSet，能做集群级策略、优先级。等保、多租户隔离时，这块经常是刚需。
成熟。项目跑很多年，生产案例多，排障时大多能搜到别人踩过的记录。对交付团队来说，这一点价值经常被低估——现场能不能搜到答案，直接决定当晚能不能收工。
Windows 节点。集群里有 Windows Worker 时，基本就它。
排障工具熟。iptables 模式下，iptables-save、ipset、calicoctl 都是老面孔，不用另学一套调试范式。
坑在哪
BGP 对底层网络要求高。要么节点二层可达做 full mesh，要么和交换机建 BGP 邻居——后者意味着要动客户网络组的交换机。私有化场景里，这句话经常等于「黄了」。现实里很多 Calico 最后退回 IPIP / VXLAN，性能优势也就没了。
iptables 规则膨胀。规模大、策略多时，规则数量和变更收敛时间会很难看。这也是它后来补 eBPF 数据平面的原因。
配置项多。灵活的另一面是要懂的东西多：IPPool、BGPPeer、CrossSubnet、和现有网段怎么不冲突，都得想清楚。
什么时候选
生产集群、要网络策略、要多租户隔离、有合规要求。网络部门肯配合且能跑 BGP 时，性价比很高。有 Windows 节点就直接它。
Cilium：技术上很强，但有门槛
怎么干活
基于 eBPF，把网络逻辑挂到内核 hook 上，不走传统 iptables 链。也可以完整替代 kube-proxy，Service 转发一并接管。
好在哪
性能。绕开 iptables 后，Service 数量上去对转发影响小得多。iptables 是线性匹配；eBPF 更像哈希查找。
L7 策略。可以写「只允许 GET /api/v1/users」这种粒度，也可以按 DNS 做出口过滤。安全要求高时很值钱。
Hubble。传统方案里跨节点不通，常常只能逐台 tcpdump；Hubble 能把服务间调用和 drop 点摊开看。排障效率不是一个量级。
生态在往上走。托管 K8s 和新建生产集群里，选 Cilium 的比例这几年涨得明显。
坑在哪
内核版本是硬门槛。当前稳定版要求内核≥ 5.10（或 RHEL 8.10 一类带足量回移植的 4.18）。社区还在讨论后续抬到 6.1 等价内核，选型时按「能长期跟上」来评估更稳妥。
uname -r私有化交付里，这一条经常直接筛掉一批环境：
CentOS 7（3.10）——出局 Ubuntu 20.04（默认 5.4）——通常不够 Ubuntu 22.04（5.15）——可以 部分麒麟版本——别想当然，单独确认
不是不能升内核，但客户生产里推一次全节点内核升级，审批和回归往往比换 CNI 还麻烦。
排障范式变了。出问题后 iptables-save 常常什么都看不到，因为规则不在那儿。要会：
kubectl -n kube-system exec ds/cilium -- cilium status --verbosekubectl -n kube-system exec ds/cilium -- cilium monitor --type drop
工具很强，但团队得有人真会用。故障夜里现学，成本很高。
资源占用相对高。小规格节点上要留意。
什么时候选
内核够、团队接得住、对性能和可观测性有真实需求，或者 Service 很多、要做 L7 策略。自己完全掌控的新集群，Cilium 经常是目前最优解之一。
反过来，节点内核都控不住——比如装到客户机器上——就要慎重。
Kube-OVN：多租户和信创场景更对口
怎么干活
底层是 OVN + OVS，把 SDN 能力搬进 K8s。这套东西在 OpenStack 时代就跑了很多年。
好在哪
真正的 VPC 多租户。别的插件做隔离多半靠 NetworkPolicy，本质是一张大网里做访问控制；Kube-OVN 可以给租户独立逻辑路由器，不同 VPC 的 IP 段还能重叠。做多租户平台时，这经常是刚需。
固定 IP、EIP、NAT、QoS、ACL、流量镜像。传统应用上容器时，最常听到的一句是「防火墙按 IP 配的，Pod IP 不能飘」。别的方案要绕，Kube-OVN 原生支持。
Underlay 灵活。Pod 可以直接用物理网 IP，和存量虚拟机同二层，对接老系统方便。
KubeVirt 友好。集群里既跑容器又跑虚拟机时，网络模型更接近传统 IaaS。
国内信创落地案例多。鲲鹏、海光、麒麟这类适配，政企评审时经常是加分项。
坑在哪
运维复杂度最高。要懂逻辑交换机、逻辑路由器、Port Binding、南北向库。排障看的是：
kubectl ko nbctl showkubectl ko vsctl show
和日常 K8s 工具链是两个世界。
组件多。ovn-central、ovs-ovn、controller、cni，任何一个挂了都要能定位。
社区体量不如前几个。冷门问题资料少，有时得自己啃代码或去社区问。
什么时候选
要 VPC 级隔离、IP 重叠、固定 IP、KubeVirt、信创或金融合规。如果只是「让 Pod 能互通」，用它属于杀鸡用牛刀，运维成本收不回来。
已经不太值得新上的
Weave Net曾经很流行，一行命令还能带加密。Weaveworks 关了，仓库也归档了，很多工具链已移除支持。存量可以排迁移，新项目别选。
CanalFlannel 负责连通 + Calico 负责策略。当年是给 Flannel 补 NetworkPolicy。现在直接用 Calico 通常更干净，没必要维护两套。
横向对比
性能这一列故意不写死数字。网上 benchmark 换个包长、并发模型，结论就能翻。真在意性能，拿自己的业务流量压一遍更靠谱。
定性排序大致是：
无封装直连（Calico BGP / Cilium 直连）> eBPF Overlay > 传统 VXLAN Overlay
小规模下差距常常感知不到。
选型：先问自己五个问题
比起死盯表格，更建议按这个顺序筛。
1. 节点内核多少，能不能改？
uname -rcat /etc/os-release
低于 5.10 且不能升级 → Cilium 先出局。这是硬约束。见过方案都评审完了，才发现客户是 CentOS 7，整套推倒重来。
2. 要不要 NetworkPolicy？
要 → Flannel 出局。别太轻易答「暂时不要」。等保、审计、多团队共集群，这些需求经常后出现，那时换 CNI 已经很贵。
3. 底层网络能不能配合？
能配 BGP、网络组肯配合 → Calico BGP 动不了物理网 → Overlay Pod 要直连物理网、和虚拟机同网段 → 看 Kube-OVN Underlay
4. 有没有多租户或固定 IP？
IP 段要重叠、要 VPC 隔离、要固定 IP → Kube-OVN 基本是答案。
5. 团队夜里接不接得住？
半夜服务不通，值班得在半小时内判断是不是网络问题。没人懂 eBPF，Cilium 再强也帮不上忙，反而因为「看不懂」拖长恢复。
能力匹配比技术先进重要。听着保守，做过几个项目后多半会认。
几个常见场景怎么选
实验室 / 演示 / 小集群Flannel。快、稳、少折腾。
一般生产，要策略隔离，没有 WindowsCalico（跑不了 BGP 就 IPIP/VXLAN）或 Cilium（内核够、团队熟）。
有 Windows WorkerCalico。
Service 极多、要 Hubble / L7 策略、内核够新Cilium。
多租户平台、固定 IP、信创、KubeVirtKube-OVN。
私有化交付、客户环境不可控优先确定性：Overlay + 成熟方案。很多团队默认 Flannel 或 Calico VXLAN/IPIP，不是不知道 Cilium 好，是内核版本都保证不了时，简单比先进更值钱。
最后提醒：换 CNI 不是改个配置
很多人低估迁移成本。
在跑着的集群上换 CNI，基本等于一次网络大手术。Pod IP 段、路由、iptables/eBPF 规则都要变，两套 CNI 也很难安全并存。常见操作是：
drain 节点 卸旧 CNI，清残留网卡和规则（ cni0、flannel.1、tunl0不删干净，新 CNI 很容易打架）装新 CNI 重建 Pod
期间业务会中断。Kubespray 一类工具明确不支持 CNI 迁移，就是因为这事自动化不到足够安全。
所以：CNI 是建集群时就要想清楚的决定，不是边跑边调的参数。新建时多花两天选型，比一年后停机迁移划算。
收个口
Flannel：简单可靠，不要策略时够用，交付兜底常见选项 Calico：企业生产稳妥答案，策略强，有 Windows 就它 Cilium：性能和可观测突出，前提是内核够、团队接得住 Kube-OVN：多租户、固定 IP、信创、KubeVirt 的专用解
没有「最好的」那个。先卡内核和底层网络两条硬约束，再看策略和多租户，最后看团队能力。三层筛下来，答案通常就剩一个。
各插件版本门槛和特性还在变，落地前以官方文档为准——尤其是 Cilium 的内核要求，后面大概率还会继续抬。
觉得有用就关注一下，后面继续分享 K8s / 运维实操和踩坑记录。
有问题欢迎留言。