Minikube 端到端测试
通过 scripts/benchmark-minikube.py 脚本，让它自动完成一套验证流程：
- 检查 Minikube 是否运行。
- 编译 Linux 版本的 traffic-manager。
- 拷贝二进制到 Minikube 节点。
- 部署测试用的后端 Deployment 和 Siege 压测 Pod。
- 先不启动 Traffic Manager，跑一次 kube-proxy baseline。
- 启动 Traffic Manager，把 eBPF 程序挂到 cgroup 上。
- 等待 BPF Map pin 成功，并检查目标 Service 已经同步进 Map。
- 再跑一次 eBPF 路径下的压测。
- 输出 QPS 对比。
- 最后清理远端进程、BPF Map 和 dummy service。
我这么做是因为 eBPF 项目高度依赖运行环境：内核版本、cgroup v2、BPF filesystem、权限、Kubernetes 网络环境都会影响结果。单纯在本机跑 go test，只能证明控制逻辑大概没错，不能证明真正的 socket connect hook 生效了。所以我选择用 Minikube 搭一个尽量接近真实 Kubernetes 的小环境，把控制面和数据面一起拉起来测。
性能对照测试
性能测试里我做了两个关键对照：
- 正常 Service 数量下的对照：同一个后端服务、同一个 Siege 客户端、同样的并发数和压测时长，先测 kube-proxy，再测 Traffic Manager。
- rule bloat 场景：额外创建几百到上千个 dummy Service，让 kube-proxy 的 iptables 规则膨胀，再对比 eBPF Map 查找路径的表现。
这么测的原因是这个项目的核心卖点就是绕过 kube-proxy/iptables 规则链。iptables 规则数量多的时候，匹配路径会变长；而 eBPF 这里是通过 Hash Map 查 Service，再选 backend，理论上查找复杂度更稳定。所以只测小规模场景不够，必须人为制造 Service 数量膨胀的场景，才能验证这个设计在大规模集群下的优势是否真的存在。
生命周期和清理测试。
这个项目需要 root 权限加载 eBPF 程序，也会 pin BPF Map。如果退出时不清理，后续测试可能会受到旧 Map、旧进程、旧 cgroup attach 的影响。所以脚本里会做：
- 停止 Minikube 里的旧 traffic-manager 进程。
- 删除旧的 BPF Map pin 路径。
- rule bloat 测试后删除 dummy services。
- Siege 超时时杀掉残留 siege 进程。
测试方面的不足
性能测试还不够严谨
现在 Siege 测的是短连接 QPS，对比方向是对的，但还不够完整：
- 只测了 QPS，没有系统性记录 p50/p95/p99 延迟。
- 单次结果波动可能比较大，应该多轮运行取均值、标准差。
- Minikube 单节点环境和真实多节点集群还有差距。
- 没有区分 TCP 长连接、短连接、UDP 流量等不同模式。
- 没有统计 CPU 使用率、内核态开销、上下文切换、BPF Map 命中率等指标。
后续我会把压测结果结构化输出成 JSON/CSV，然后多轮跑，配合 Prometheus 或 perf/bpftool 去观察资源消耗，而不是只看一个最终 QPS。
故障场景覆盖不够
真实环境里会遇到很多动态变化，比如：
- 后端 Pod 滚动更新。
- Pod 被 kill。
- EndpointSlice 快速变化。
- Service 被删除又重建。
- Prometheus 暂时不可用。
- BPF Map 写入失败。
- 权重数据异常，比如全部为 0。
- controller 重启后需要重新同步已有 Service。
这些目前没有形成自动化 case。后续我会补一组 chaos/e2e 测试，比如在压测过程中持续扩缩容 Deployment，看连接成功率和错误率；或者故意让 Prometheus 不可用，看是否能降级到普通负载均衡。