启用 --enable-bpf-lb 后 kube-proxy 默认仍在运行，cilium 会退入混合模式导致性能更差；必须手动删除 kube-proxy 或设 kubeproxyreplacement: strict 才能真正接管。
启用 --enable-bpf-lb 后，kube-proxy 还在运行吗？
默认情况下，--enable-bpf-lb 不会自动停掉 kube-proxy。Cilium 会检测到它存在，然后退回到“混合模式”：BPF 处理部分流量（如 NodePort），但 ClusterIP 仍走 kube-proxy 的 iptables 规则——这反而让性能更差、路径更乱。
实操建议：
- 必须手动删掉
kube-proxyDaemonSet（或用 Helm chart 设置kubeProxyReplacement: strict） - 确认
kube-proxy进程在所有节点上已退出：ps aux | grep kube-proxy - Cilium 日志里出现
"BPF host routing enabled"和"kube-proxy replacement: strict"才算真正接管
--enable-bpf-lb 实际加速了哪些流量？
它只加速三类请求：NodePort、LoadBalancer 类型 Service 的外部访问，以及从集群内 Pod 访问本机 NodePort。ClusterIP 流量默认不走 BPF LB，除非你额外开启 --enable-bpf-masquerade 并配置 bpf-lb-external-clusterip（1.14+）。
常见错误现象：
- 用
curl http://<cluster-ip>:80</cluster-ip>测试，发现延迟没变——这是正常的，ClusterIP 默认绕过 BPF LB - Service 类型是
ClusterIP，却期待 BPF 加速，结果全是 iptables 路径 - ExternalIP 或 HostNetwork Pod 访问 NodePort 时，因未开启
--bpf-lb-always-redirect，触发了非预期的 SNAT
对比测试时，为什么 iperf3 结果波动大、甚至不如 kube-proxy？
BPF LB 的优势不在单连接吞吐，而在连接建立速度和高并发小包场景。用 iperf3 -c <node-ip> -p 30000 -t 30 -P 64</node-ip> 测吞吐，容易受 TCP 栈参数、网卡 offload、CPU 频率影响，反而掩盖真实差异。
更有效的验证方式：
- 测新建连接 QPS：
ab -n 10000 -c 200 http://<node-ip>:30000/healthz</node-ip>（短连接） - 看 conntrack 条目增长：
conntrack -L | wc -l—— BPF LB 下几乎为 0 - 抓包看路径：
tcpdump -i cilium_host port 30000，确认没有经过iptables的KUBE-SERVICES链
注意：如果节点开了 net.ipv4.conf.all.rp_filter=1，BPF LB 的 Direct Server Return（DSR）模式会失败，回退到隧道模式，性能打五折。
Cilium 1.13+ 后，--enable-bpf-lb 和 --kube-proxy-replacement 怎么配才不冲突？
这两个参数不是互斥开关，而是分层控制：前者决定是否编译进 BPF 程序，后者决定运行时是否启用并接管。单独开 --enable-bpf-lb=true 但 --kube-proxy-replacement=disabled，BPF 程序会加载但不生效。
推荐组合（Cilium 1.14+）：
-
--enable-bpf-lb=true（必须） -
--kube-proxy-replacement=strict（强制接管，拒绝启动 if kube-proxy 存在） -
--bpf-lb-external-clusterip=true（可选，让 ClusterIP 也走 BPF，需配合--enable-bpf-masquerade）
容易被忽略的点：Cilium ConfigMap 更新后，必须重启 Cilium Agent（不是只 reload），否则新参数不生效；且 cilium status 输出里的 KubeProxyReplacement 字段必须显示 Strict，不是 Partial 或空。
