1. 课程导入与网络性能全景

Kubernetes 把网络拆成了多个可插拔的层次：Pod 内容器通过 veth pair 接入节点上的网桥或 eBPF 数据面，跨节点流量再经过隧道封装或直接路由，最后经 Service 的虚拟 IP 与 kube-proxy/IPVS 或 eBPF 完成负载均衡。每一层都可能成为性能瓶颈，因此“优化”与“排障”本质上是一件事的两面：先建立可观测的指标基线，再定位是哪一层偏离了基线。

本课程的核心目标可以概括为三点：第一，能说清一个数据包从 Pod A 到 Pod B（或到集群外）究竟经过了哪些设备、规则和转发决策；第二，能用延迟、吞吐、丢包、连接数四类指标量化每一层的健康度；第三，能在出现抖动、超时、吞吐下降时，按“数据面 → 规则面 → 应用面”的顺序缩小范围，而不是盲目重启组件。

四类关键指标与它们的观测位置

延迟通常拆成单向时延与往返时延（RTT）。在容器网络里，值得关注的是 Pod 到 Pod 的 RTT、Pod 到 Service ClusterIP 的 RTT，以及经过 NodePort/Ingress 后的端到端时延。吞吐关注单流带宽与多流聚合带宽，前者受拥塞窗口和路径 MTU 影响，后者受网卡多队列、RPS/RFS 与 CPU 软中断分布影响。丢包要区分“链路丢包”和“规则丢包”：前者来自物理链路或隧道 MTU 不匹配，后者来自 NetworkPolicy、conntrack 表满或 iptables 规则丢弃。连接数则关注 conntrack 表使用率、TIME_WAIT 数量以及 NAT 端口耗尽风险。

这些指标并非孤立。例如 MTU 配置错误会同时表现为大包丢包、吞吐骤降和 TCP 重传升高；conntrack 表接近上限时，新连接建立延迟会明显上升，而老连接仍正常。因此排障时要把指标放在同一条数据链路上看，而不是单点看某个数字。

典型场景与学习路径

课程会围绕四类高频场景展开。第一类是“新建连接慢”：表现为客户端首次访问 Service 超时，重试后成功。常见原因是 kube-proxy 规则过多导致 iptables 链遍历变长，或 IPVS 调度器与后端权重不匹配。第二类是“大流量吞吐上不去”：单流 iperf3 只有几百 Mbps，而物理网卡是 10 Gbps，往往与 MTU 不一致、TCP 窗口受限或软中断集中在单个 CPU 有关。第三类是“间歇性丢包”：表现为 P99 延迟毛刺，需要结合 conntrack 插入失败计数与网卡 drop 计数判断是规则面还是链路面。第四类是“连接数打满”：conntrack 表使用率超过 80% 后，新连接被丢弃，需要调整 nf_conntrack_max 或优化连接复用。

学习路径建议按“先观测、再定位、后调优”推进。观测阶段掌握 kubectl exec 进入 Pod 执行 ping、traceroute、ss，以及在节点上使用 tcpdump、nstat、conntrack 的基本方法。定位阶段学会区分“数据面问题”和“规则面问题”：如果 tcpdump 在 Pod 网卡能看到请求但节点出口看不到，问题在本地转发；如果节点出口能看到但对端没收到，问题在隧道或物理链路。调优阶段再涉及 MTU 调整、kube-proxy 模式切换、eBPF 加速、网卡多队列与 RPS 配置。

一个可复用的排障判断顺序

当收到“服务变慢”的反馈时，可以按以下顺序快速缩小范围：先确认影响面是单个 Pod、单个节点还是整个集群；再确认是延迟升高、吞吐下降还是连接失败；接着在客户端 Pod 内执行 ss -s 看 TIME_WAIT 与重传，在节点上执行 nstat -az | grep -i drop 看丢包计数，最后用 conntrack -S 查看 insert_failed 是否增长。如果 insert_failed 持续增长，优先怀疑 conntrack 表容量或 NAT 端口耗尽；如果网卡 drop 增长而 conntrack 正常，则转向链路与 MTU 检查。