3. 网络带宽基础：带宽定义、吞吐量、PPS（包每秒）、延迟之间的关系，以及它们在K8s环境中的测量方法
在Kubernetes网络性能调优中，理解带宽、吞吐量、PPS和延迟这四大核心指标是诊断CNI插件瓶颈的前提。这四个指标相互制约，共同决定了Pod的网络服务质量。本节将厘清它们的定义、数学关系，并给出在K8s环境中的标准测量方法。
3.1 核心指标定义与对比
| 指标 | 英文 | 单位 | 核心含义 |
|---|---|---|---|
| 带宽 | Bandwidth | bps (bit/s), Gbps | 链路或接口的理论最大传输速率，是物理或虚拟网卡的容量上限。 |
| 吞吐量 | Throughput | bps (bit/s), Gbps | 实际应用中成功传输数据的速率，受协议开销、CPU、内存、CNI封装等因素影响，通常低于带宽。 |
| 包每秒 | PPS (Packets Per Second) | pps | 网络设备或节点每秒能处理的数据包数量，反映小包场景下的转发能力。 |
| 延迟 | Latency | ms, μs | 数据包从源端到目的端所花费的单向或往返时间（RTT）。 |
关键认知： 带宽是“水管粗细”，吞吐量是“实际水流”，PPS是“水滴数量”，延迟是“水流速度”。在K8s中，CNI插件的Overhead（如VXLAN封装）会同时降低吞吐量和PPS，并增加延迟。
3.2 四者之间的制约关系
这四个指标并非独立存在，它们之间存在经典的性能三角关系。理解这些关系有助于在调优时做出权衡。
- 带宽 vs. 吞吐量： 吞吐量 ≤ 带宽。协议头开销（TCP/IP、VXLAN、Geneve）会消耗部分带宽，导致吞吐量永远无法达到理论带宽值。
- PPS vs. 吞吐量： 吞吐量 = PPS × 平均包大小（含帧头）。当包大小固定时，PPS越高，吞吐量越大。但在小包场景（如64字节），CPU中断和内核协议栈处理成为瓶颈，PPS先达到上限，导致吞吐量远低于带宽。
- 延迟 vs. 吞吐量： 在链路未饱和时，延迟通常较低且稳定。当吞吐量接近带宽上限时，网络队列开始堆积，导致延迟急剧上升（即“拐点”）。
- PPS vs. 延迟： 高PPS意味着频繁的中断和上下文切换，这会增加CPU处理延迟，进而影响应用层的响应时间。
K8s调优启示： 对于Redis、Memcached等延迟敏感型应用，应优先关注PPS和延迟，而非单纯追求带宽。对于大数据传输（如Spark Shuffle），则需优先保障吞吐量。
3.3 指标关系示意图
下图展示了在典型K8s节点上，随着负载增加，吞吐量与延迟之间的非线性关系，以及PPS对吞吐量的影响。
3.4 K8s环境中的测量方法
在Kubernetes集群中测量网络指标，需要区分节点级和Pod级两个维度。以下是标准工具和命令。
3.4.1 节点级测量（宿主机视角）
- 带宽/吞吐量： 使用
iperf3在两个Node之间或Node与外部测试机之间进行TCP/UDP流测试。 - PPS： 使用
sar -n DEV 1或ethtool -S eth0 | grep rx_packets查看网卡收发包速率。 - 延迟： 使用
ping或mtr测量节点间RTT。
节点级命令示例：
# 在Node A启动服务端
iperf3 -s -p 5201
# 在Node B启动客户端，测试TCP吞吐量（30秒）
iperf3 -c <NodeA_IP> -p 5201 -t 30
# 查看节点eth0的PPS
sar -n DEV 1 5 | grep eth0
# 测量节点间延迟
ping -c 100 <NodeB_IP>3.4.2 Pod级测量（容器视角）
Pod级测量需要绕过Service负载均衡，直接使用Pod IP。由于CNI插件的存在，Pod的网络性能可能与宿主机有显著差异。
- Pod间吞吐量： 在同一个Node或跨Node的Pod之间运行
iperf3。注意Pod的CPU Limit可能成为瓶颈。 - Pod间PPS： 使用
netperf的TCP_RR或UDP_STREAM测试，或使用sockperf进行更精细的PPS测量。 - Pod间延迟： 使用
ping直接对Pod IP进行测试。对于微秒级精度，建议使用sockperf或qperf。
K8s专用测量工具： 推荐使用
k8s-netperf 或 Kubernetes Netperf Operator，它们可以自动化部署测试Pod并收集跨Node的性能数据，避免手动配置的繁琐。
3.4.3 测量注意事项
| 注意事项 | 说明 |
|---|---|
| CPU绑定 | iperf3等工具是CPU密集型，建议将测试Pod绑定到独占CPU核心（使用Guaranteed QoS），避免干扰。 |
| MTU一致性 | 确保Pod网络MTU与宿主机底层网络MTU一致，避免分片导致性能下降。 |
| CNI Overhead | VXLAN/Geneve封装会额外消耗20-50字节，导致有效MTU降低，影响大包吞吐量。 |
| 多轮测试 | 网络性能波动较大，建议每项测试至少运行5次，取中位数或平均值。 |
常见误区： 不要仅依赖
ping 的延迟结果来评估网络性能。ping使用的是ICMP协议，优先级高且不经过协议栈的复杂处理，其延迟通常远低于实际TCP/UDP应用的延迟。务必使用应用层工具（如iperf3、sockperf）进行验证。