解读

在国内一线互联网与金融云原生落地场景中，kube-proxy 的 iptables/ipvs 模式因“内核态-用户态-内核态”多次上下文切换、规则线性匹配、conntrack 锁竞争等问题，在 5k+ 节点、10w+ service 的压测下，P99 延迟常出现 2-3 ms 的“毛刺”。
面试官抛出“降 20%”并非让候选人背参数，而是考察三层能力：

1. 能否把“延迟”拆成可量化、可对比的指标；
2. 能否用 eBPF 的“零拷贝、早转发”特性做定向优化；
3. 能否给出可落地的灰度验证方案，并能在现网 SLA 1s 以内回滚。

知识点

1. 延迟分解：

   • SYN→SYN-ACK 路径：软中断、iptables 规则匹配、conntrack 创建、负载均衡选端点；
   • 数据路径：DNAT、SNAT、TCP 校验和、GRO/GSO、qdisc；
   • 观测工具：perf、bpftrace、tcprtt、pktlatencystat、Cilium Hubble。

2. eBPF 转发优势：

   • socket-level 负载均衡：BPF_PROG_TYPE_CGROUP_SOCK_ADDR 在 connect 阶段直接返回后端 Pod IP，绕过 DNAT；
   • 早转发（Early Demux）：BPF_PROG_TYPE_SK_LOOKUP 在 TCP 握手前选端点，减少一次 RTT；
   • 无锁哈希：eBPF map 预分配后端条目，查询复杂度 O(1)；
   • 零拷贝：eBPF + XDP 驱动模式可在网卡驱动层直接转发，节省 skb 分配；
   • conntrack 旁路：eBPF 自身维护 CT map，避免 nf_conntrack 全局锁。

3. 国内现网限制：

   • 内核版本：CentOS 7.9 默认 3.10，需升级到 5.10+ 或 使用 Alibaba Cloud Linux 3、TencentOS Server 3.1；
   • 芯片架构：x86_64 与 Kunpeng/Phytium 的 eBPF JIT 能力差异；
   • 安全合规：等保 2.0 要求 eBPF 程序具备签名与审计，需开启 CONFIG_BPF_JIT_ALWAYS_ON + lockdown LSM；
   • CNI 热迁移：金融场景要求原地替换 kube-proxy 时业务长连接 0 断流，需双写 iptables+eBPF 并做 session 同步。

答案

“降 20%”需分三步走：量化、优化、验证。

1. 量化基线
   在预发环境搭建 1:1 模型：使用 wrk2 模拟 2k RPS、100 并发连接，目标 service 50 个后端 Pod。
   指标：

   • tcp_rtt (SYN→SYN-ACK) P50/P99
   • 应用层 TTFB (first byte)
   • node_cpu_softirq 占比
     基线数据：kube-proxy ipvs 模式 P99 RTT 1.8 ms，TTFB 4.2 ms。

2. 优化动作
   a) 内核升级：统一升到 5.15 LTS，开启 BPF JIT + PREEMPT_RT，关闭 nf_conntrack 加速模块；
   b) Cilium 安装参数：
   kubeProxyReplacement=strict
   bpf.masquerade=true
   bpf.hostRouting=true
   encryption=false（先排除 IPsec 干扰）
   c) 调优 eBPF map 大小：
   –config bpf-map-dynamic-size-ratio=0.03%
   –config service-max-backend=512
   避免 map 满触发 rehash；
   d) 早转发：
   在 Cilium 1.13+ 启用 socket-LB 在 Pod init 命名空间生效，使 sidecar 也走 eBPF 路径；
   e) IRQ 亲和：
   把网卡队列绑定到与 Pod 所在 NUMA 相同的核心，减少跨 NUMA 延迟；
   f) 灰度：
   先替换 20% 节点，对比 P99 RTT 从 1.8 ms 降至 1.4 ms，降幅 22%，满足目标。

3. 验证与回滚
   使用 ChaosMesh 注入 5% 丢包，观察 eBPF 路径无 5xx；
   若延迟回弹，秒级回滚：
   kubectl rollout restart ds/kube-proxy && cilium uninstall –rollback-iptables，保证 iptables 规则 30s 内重建完成。

拓展思考

1. 如果业务是 RocketMQ、gRPC 长连接，eBPF 的 socket-LB 只在 connect 时选端点，长连接重均衡需结合 Cilium L7 Envoy 策略，或客户端主动重连，如何量化“重连”带来的额外延迟？
2. 在混合云场景，部分节点仍跑 CentOS 7.6（3.10 内核），无法升级，能否通过 eBPF offload 到智能网卡（如阿里云 eRDMA、华为 iNIC）把转发逻辑下沉硬件，实现“内核不升级也降 20%”？
3. 观测层面，eBPF 程序自身也会消耗 CPU，若开启 Hubble 全量解析 L7 header，可能把节省的 0.4 ms 又吃回去，如何设计“采样率动态调整”算法，在延迟与可观测性之间做权衡？