300节点K8s集群从Calico迁移到Cilium：延迟降40%，但3个坑差点让我通宵

背景：为什么非要换网络插件？

我们有一个跑了3年的K8s集群，300个节点，5000+ Pod，之前一直用Calico的IPIP模式，搭配kube-proxy的iptables模式。说实话，平时没觉得有啥大问题，直到去年双十一大促，监控发现跨节点网络延迟P99飙到了2.5ms，而且节点上的iptables规则数量超过了2万条，CPU软中断（softirq）占用到了12%。当时我们以为是流量太大，后来抓包分析发现，IPIP隧道封装解封装的开销在高压下被放大了。

正好那段时间Cilium 1.13发布，宣传用eBPF替代iptables，还能绕过kube-proxy。我就在测试环境搭了一套，结果iperf3测试数据让我有点意外——延迟确实低，但没低到离谱。后来我们决定在生产环境灰度迁移，过程比想象中曲折。

实测对比：Calico IPIP vs Calico BGP vs Cilium

测试环境：3台物理机，10G网卡，内核5.4（后来升级到5.10），K8s 1.24，Calico 3.22，Cilium 1.13。我们用iperf3测了TCP吞吐和延迟，每个模式跑10次取平均。

看到没？Cilium native routing确实最快，但和Calico BGP的差距没有宣传的那么夸张。真正让我下决心换的是CPU软中断——从12%降到6%，意味着同样节点能多跑20%的Pod。不过native routing要求底层网络支持路由，我们机房是BGP EVPN，刚好满足。如果你们是普通VPC，只能用隧道模式，那提升就有限了。

迁移步骤：我是怎么一步步换掉的

先升级内核到5.10，因为Cilium的eBPF需要内核4.19+，但5.10对XDP支持更好。然后备份Calico配置：calicoctl get ippool -o yaml > ippool.yaml。接着安装Cilium CLI，用Helm部署，关键参数：

tunnel: disabled
ipam: kubernetes
enable-bpf-masquerade: true
kubeProxyReplacement: strict

注意，一定要先禁用kube-proxy，否则规则冲突。我们采用逐节点排水：kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data，然后卸载Calico，安装Cilium，再uncordon。300个节点花了大概6个小时，凌晨2点的时候差点想回滚。

踩坑记录：这3个问题官方文档没写

坑1：Pod CIDR冲突导致部分Pod IP重复。 Calico默认IP池是10.244.0.0/16，Cilium默认也是，但Cilium的ipam模式会重新分配，结果和Calico残留的IP冲突。解决方案：手动指定cluster-pool-ipv4-cidr和原来一致，并且清理Calico的iptables规则：iptables-save | grep cali | iptables-restore。

坑2：Hubble开启后流量丢失。 Hubble UI能看到数据，但部分Service访问超时。排查发现是relay端口4245被防火墙拦了，因为节点间安全组只开了Calico的VXLAN端口4789。加上4245后正常。

坑3：DNS解析偶尔超时。 迁移后CoreDNS日志出现connection refused，后来发现是Cilium的DNS proxy和CoreDNS的EDNS配置冲突。设置dnsproxy-enable-transparent-mode: true后解决。这个在Cilium 1.13的release note里提了一嘴，但没详细说。

最终效果与我的独立观点

迁移后，跨节点延迟P99从2.5ms降到1.2ms，整体网络延迟降了约40%，节点CPU使用率下降8%。但我要说句得罪人的话：如果你的集群小于50个节点，别折腾Cilium。Calico的BGP模式足够稳定，而且运维简单。Cilium的优势在100节点以上才明显，因为eBPF的map查找是O(1)，而iptables是O(n)，节点越多差距越大。

另外，别盲目开Hubble，它虽然好看，但每个节点会多消耗约200MB内存和5%的CPU。我们只在排查问题时临时开。最后，迁移前一定要在测试环境模拟Pod CIDR和Service CIDR的冲突，不然就会像我一样，凌晨3点对着报错喝红牛。