基于 eBPF 与 Linux 工具链定位容器网络延迟的实战方法

在 Kubernetes 集群中，偶发的请求延迟升高常常比持续故障更难排查。应用日志可能没有异常，CPU 使用率也看似正常，但用户仍会遇到请求超时。原因可能出现在应用、容器网络、宿主机协议栈或物理网络等多个层次。有效的排查方式不是一开始就抓取大量数据，而是先建立可验证的假设，再逐层缩小范围。

先明确观测边界与症状

首先确认延迟影响的范围：是单个 Pod、单个节点、某个服务，还是跨节点请求普遍变慢。对比同一服务的节点分布、请求方向和时间窗口，并记录请求延迟分位数、错误率、连接建立耗时及重传情况。平均延迟可能掩盖少量长尾请求，因此建议重点关注 P95、P99 等分位数。

如果只有跨节点流量异常，排查重点应转向节点间网络、隧道封装和路径 MTU；如果同节点 Pod 通信也异常，则还需检查节点资源竞争、网络设备队列及容器限额。先区分范围，可以避免把应用问题误判为网络问题。

从基础指标检查协议栈

在问题节点上，可使用 ss 查看连接状态和监听队列，使用 ip -s link 检查接口收发错误与丢包，并通过 nstat 观察 TCP 重传、连接重置等计数器。计数器要结合时间窗口判断：累计值较大并不一定说明当前存在故障，关键是观察问题期间的增量是否同步上升。

# 查看 TCP 连接状态与队列
ss -s
ss -lnt

# 检查网卡收发统计
ip -s link show dev eth0

# 查看 TCP 指标，并在问题前后对比变化
nstat -az | grep -E 'TcpRetransSegs|TcpExtTCPTimeouts|TcpExtListenOverflows'

# 抓取指定端口的短时流量样本
sudo tcpdump -i any -nn -s 128 -c 200 'tcp port 8080'

以上命令中的网卡名称和端口需要按实际环境调整。抓包可能包含敏感数据，应限制采集范围、控制保存位置和留存时间，并遵循组织的安全规范。若监听队列溢出持续增加，应进一步核对应用处理能力、accept 队列配置和连接突发情况，而不是单纯增大内核参数。

用 eBPF 观察延迟发生的位置

eBPF 能够在内核关键路径上采集事件，帮助观察系统调用、TCP 连接和网络包处理情况。常见发行版可使用 BCC 或 bpftrace 工具集，具体工具是否可用取决于内核版本、权限和发行版支持情况。实践中可以先用现成工具观察 TCP 重传与连接延迟，再结合进程、容器和节点信息定位异常来源。

需要注意，eBPF 观测结果不是脱离上下文的结论。例如，检测到重传只能说明传输过程中发生了重试，不能直接证明故障由某一块网卡造成。应将事件时间与 Pod 请求日志、节点接口计数器、负载变化和服务调用链对齐，逐步判断问题是拥塞、丢包还是接收端处理不及时。

验证瓶颈并实施可回滚优化

当证据指向软中断过载时，可检查节点 CPU 在软中断上下文的占用，以及网络队列分布；当证据指向连接队列时，先确认服务端是否来得及处理连接。任何 sysctl、网卡队列或容器资源调整，都应先在非生产环境验证，并记录变更前后的延迟分位数、错误率和资源指标。

如果问题与容器 CPU 限额相关，还应检查是否发生 CPU throttling。网络处理线程被限制在较少的 CPU 配额内时，可能表现为突发请求下响应变慢，即使宿主机总体 CPU 尚有余量。此时应结合容器指标、节点调度情况和业务负载评估资源请求与限制，避免仅靠放宽限制掩盖容量规划问题。

形成可重复的排障闭环

推荐将排查过程固定为“界定影响范围、确认时间窗口、检查基础指标、采集短时证据、关联应用与节点信息、验证假设、观察优化结果”。把常用命令、指标阈值和变更记录纳入运维手册，并为关键服务建立网络延迟与重传告警。这样既能提升单次故障的定位效率，也能帮助团队识别长期存在的容量和配置风险。

排查网络延迟的核心不是堆叠工具，而是以证据逐层缩小问题范围。Linux 工具适合快速确认协议栈状态，eBPF 则能补充内核路径上的细粒度观测。两者与应用指标、容器元数据结合后，才能把“请求变慢”转化为可验证、可复现并可持续治理的工程问题。