痛点
kube-proxy 是 Kubernetes 默认的服务代理组件，但在大规模集群中它的 iptables/IPVS 模式存在明显性能瓶颈：
- iptables 模式：规则数量随 Service/Endpoint 线性增长，万级 Service 场景下规则链遍历延迟显著增加，每次规则更新需全量刷新
- IPVS 模式：虽比 iptables 好，但仍需 conntrack 表维护，UDP 场景下易出现 conntrack 表溢出，且与 NetworkPolicy 联动复杂
- 节点资源开销：kube-proxy 在每个节点生成大量 iptables 规则或 IPVS 条目，内存占用随集群规模增长
Cilium 利用 eBPF 直接在内核数据路径（datapath）实现 Service 负载均衡和网络策略，从根本上绕过了 iptables/IPVS 的架构限制。
方案
核心思路：用 Cilium 的 eBPF kube-proxy replacement 功能完全替代 kube-proxy，将 Service 路由、负载均衡、SNAT 全部下沉到 eBPF 程序执行。
关键收益： | 维度 | kube-proxy (iptables) | Cilium eBPF | |------|----------------------|-------------| | Service 路由延迟 | O(n) 规则遍历 | O(1) eBPF map 查找 | | 规则更新 | 全量刷新 | 增量更新 | | conntrack 依赖 | 强依赖 | 可选（CT offload） | | 内存占用(1000 Service) | ~300MB iptables 规则 | ~50MB eBPF map | | DSR（Direct Server Return） | 不支持 | 原生支持 |
实操步骤
第一步：环境准备与内核要求
Cilium kube-proxy replacement 要求 Linux Kernel ≥ 5.10（推荐 5.15+），确认节点内核版本：
uname -r
# 输出 >= 5.10 即可，例如 6.1.0-18-generic
# 确认 eBPF 支持
ls /sys/fs/bpf
# 应存在该挂载点
# 确认 BTF（BPF Type Format）支持
ls /sys/kernel/btf/vmlinux
# 文件存在说明内核支持 BTF，Cilium 可自动适配
第二步：部署 Cilium 并禁用 kube-proxy
使用 Cilium CLI 安装（推荐方式），核心参数是 kubeProxyReplacement=true：
# 安装 Cilium CLI
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
curl -L --remote-name-all \
https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-amd64.tar.gz
tar xzvf cilium-linux-amd64.tar.gz -C /usr/local/bin
# 安装 Cilium，启用 kube-proxy replacement
cilium install \
--set kubeProxyReplacement=true \
--set k8sServiceHost=${API_SERVER_IP} \
--set k8sServicePort=6443 \
--set bpf.masquerade=true \
--set loadBalancer.mode=dsr \
--set loadBalancer.algorithm=maglev
# 验证安装状态
cilium status --wait
如果是已有集群，先删除 kube-proxy：
# 删除 kube-proxy DaemonSet
kubectl -n kube-system delete daemonset kube-proxy
# 清理 kube-proxy 遗留的 iptables 规则
kubectl -n kube-system exec -it <cilium-pod> -- \
cilium-dbg cleanup-kube-proxy-rules
Helm 方式部署的等效配置：
# values.yaml
kubeProxyReplacement: true
k8sServiceHost: "10.0.0.1"
k8sServicePort: "6443"
bpf:
masquerade: true
loadBalancer:
mode: dsr # 或 snat/hybrid
algorithm: maglev # 一致性哈希，适合长连接
第三步：验证 kube-proxy replacement 生效
# 检查 Cilium 的 kube-proxy replacement 状态
kubectl -n kube-system exec -it ds/cilium -- cilium-dbg status | grep KubeProxyReplacement
# 期望输出:
# KubeProxyReplacement: True [eth0 (Direct Routing), ...]
# 查看 eBPF 实现的 Service map
kubectl -n kube-system exec -it ds/cilium -- cilium-dbg bpf lb list
# 输出示例：
# SERVICE ADDRESS BACKEND ADDRESS
# 10.96.0.1:443 10.0.1.5:6443
# 10.96.0.10:53 10.0.2.3:53, 10.0.2.4:53
第四步：性能对比验证
部署测试工具验证延迟和吞吐提升：
# 使用 netperf 做 TCP_RR 测试（衡量请求/响应延迟）
kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/main/examples/kubernetes/connectivity-check/connectivity-check.yaml
# 或用 cilium connectivity test
cilium connectivity test
# 用 wrk 对 ClusterIP Service 压测
kubectl run wrk --image=skandyla/wrk --rm -it -- \
-t4 -c100 -d30s http://my-service.default.svc.cluster.local/
典型对比结果（100 节点、2000 Service 集群）： - TCP_RR 延迟：kube-proxy iptables ~120μs → Cilium eBPF ~45μs（降低 62%） - Service 规则更新耗时：kube-proxy ~8s → Cilium <100ms - 节点内存占用减少约 200MB
避坑指南
1. NodePort 流量源 IP 丢失
DSR 模式下，NodePort 流量直接由后端 Pod 回复客户端，可保留源 IP。但如果后端 Pod 和客户端不在同一 L2 域，需确保回程路由正确：
# 确认 DSR dispatch 模式
kubectl -n kube-system exec ds/cilium -- \
cilium-dbg config | grep LoadBalancerDSRDispatch
# 若跨子网需设置为 "geneve" 或 "ipip" 封装模式
2. 内核版本不满足导致 fallback
Cilium 会在内核能力不足时静默降级为部分 eBPF 实现，需主动检查：
kubectl -n kube-system exec ds/cilium -- cilium-dbg status --verbose | grep -A5 "BPF"
# 确认所有 datapath feature 均为 "OK" 而非 "Disabled"
常见问题：缺少 CONFIG_BPF_JIT 或 CONFIG_BPF_STREAM_PARSER 内核配置。Ubuntu 22.04+ / Amazon Linux 2023 默认满足。
3. Maglev 哈希与滚动更新的冲突
Maglev 一致性哈希适合长连接负载均衡，但 Deployment 滚动更新时后端变化会导致部分连接重新哈希。解决方案：
# 对长连接 Service 启用 session affinity
apiVersion: v1
kind: Service
metadata:
name: my-stateful-svc
spec:
sessionAffinity: ClientIP
sessionAffinityConfig:
clientIP:
timeoutSeconds: 3600
总结
- 何时替代：集群 Service 数量 > 500、对网络延迟敏感、需要 DSR/源 IP 保留的场景，强烈建议用 Cilium 替代 kube-proxy
- 核心价值：eBPF O(1) 查找替代 iptables O(n) 遍历，增量更新替代全量刷新，内存占用大幅下降
- 落地建议：新集群直接无 kube-proxy 部署；存量集群先灰度（部分节点禁用 kube-proxy），确认无异常后全量推进
- 内核要求：Kernel ≥ 5.10 是硬性要求，生产环境推荐 5.15+ 以获得完整 eBPF 特性支持
Cilium 已经是 CNCF 毕业项目，Google GKE Dataplane V2、AWS EKS 均基于 Cilium 构建。如果你还在用 kube-proxy + iptables 扛大规模流量，是时候切换了。