4. 网络性能指标：吞吐量、延迟、PPS、连接数、MTU 对性能的影响
在 Kubernetes 网络拓扑调优中，性能指标是衡量网络质量与瓶颈定位的标尺。吞吐量、延迟、PPS、连接数、MTU 这五个核心指标分别从带宽、响应速度、小包处理能力、并发规模和报文效率四个维度刻画网络行为。理解它们的物理含义、测量方法以及相互制约关系，是后续 Helm 参数协同调优的前提。
4.1 五大核心指标定义与测量单位
| 指标 | 英文全称 | 常用单位 | 描述 |
|---|---|---|---|
| 吞吐量 | Throughput | bps / Bps / pps | 单位时间内成功传输的数据量，受链路带宽和协议开销限制。 |
| 延迟 | Latency | ms / μs | 数据包从源端到目的端所经历的时间，包括传输、处理、排队时延。 |
| PPS | Packets Per Second | pps | 每秒处理的数据包数量，反映网络设备/内核的小包转发能力。 |
| 连接数 | Concurrent Connections | 个 | 系统同时维持的 TCP/UDP 连接数量，受端口范围、内存、文件描述符限制。 |
| MTU | Maximum Transmission Unit | 字节 | 网络接口层能传输的最大数据包大小，直接影响分片与传输效率。 |
调优视角： 在 K8s 环境中，吞吐量往往受限于 Pod 网络带宽和 CNI 插件封装开销；延迟则受节点间拓扑距离、iptables/IPVS 规则链长度影响；PPS 是 CPU 中断处理能力的瓶颈指标；连接数在 Service Mesh 场景下尤为关键；MTU 配置不当会导致大量分片重传，间接降低吞吐量。
4.2 指标间的制约关系与典型场景
五个指标并非独立存在，它们之间存在典型的“跷跷板”效应。例如：
- 吞吐量 vs. 延迟： 高吞吐量通常伴随队列积压，导致延迟上升（Bufferbloat 现象）。
- PPS vs. 吞吐量： 小包场景下，PPS 成为瓶颈，即使链路带宽未用满，吞吐量也无法继续增长。
- MTU vs. 吞吐量： 增大 MTU 可减少报文头开销和 CPU 中断次数，提升大文件传输吞吐量；但过大的 MTU 会增加丢包重传代价。
- 连接数 vs. 延迟： 连接数过高时，内核连接跟踪表（conntrack）和 epoll 轮询压力增大，导致新建连接延迟飙升。
K8s 典型场景： 在 Service Mesh（如 Istio）中，每个请求经过 sidecar 代理会增加 2~5ms 延迟；同时 sidecar 维护大量连接，PPS 和连接数指标会显著高于无 Mesh 场景。此时若 MTU 未对齐（如 overlay 网络额外封装 50 字节），则分片率上升，进一步恶化吞吐量。
4.3 MTU 对性能的影响机制
MTU 是网络性能调优中容易被忽略但影响深远的参数。在 K8s 环境中，数据包通常经历多层封装：
- Pod 内原始报文（如 1500 字节）
- CNI 封装（如 Calico VXLAN 额外 50 字节，Flannel VXLAN 额外 50 字节，Cilium 隧道模式额外 50~70 字节）
- 物理网络 MTU（通常为 1500 或 9000）
若物理网络 MTU 为 1500，而 CNI 封装后报文超过 1500 字节，则必须分片。分片导致：
- CPU 负担增加（分片与重组消耗内核资源）
- 延迟上升（分片包需全部到达才能重组）
- 吞吐量下降（分片丢失导致整个报文重传）
常见错误： 在公有云环境（如 AWS、GCP）中，底层网络 MTU 通常为 9000（巨型帧），但 Pod 网络 MTU 未同步调整，导致 CNI 封装后报文仍小于 9000，却因 Pod 接口 MTU 设置过小（如 1500）而主动分片。正确做法是将 Pod 接口 MTU 设置为
物理网络 MTU - 封装开销。
4.4 指标测量工具与 K8s 环境适配
| 指标 | 常用工具 | K8s 环境命令示例 |
|---|---|---|
| 吞吐量 | iperf3 / netperf | kubectl exec -it pod-a -- iperf3 -c <pod-b-ip> -t 30 |
| 延迟 | ping / mtr / sockperf | kubectl exec -it pod-a -- ping -c 100 <pod-b-ip> |
| PPS | sar -n DEV / pktgen / trex | kubectl exec -it pod-a -- sar -n DEV 1 10 |
| 连接数 | ss / netstat / conntrack | kubectl exec -it pod-a -- ss -s |
| MTU 探测 | ping -M do -s / tracepath | kubectl exec -it pod-a -- ping -M do -s 1472 <pod-b-ip> |
测量注意事项： 在 K8s 中测量网络性能时，务必使用 hostNetwork: true 或 DaemonSet 部署测量工具，避免 CNI 封装对测量结果引入额外变量。同时，应分别在同节点、跨节点、跨可用区三种拓扑下测量，以全面评估网络性能。
4.5 性能指标与网络拓扑的关联 SVG 图
下图展示了从 Pod 到 Pod 的完整数据路径，以及各路径节点上主导的性能指标：
4.6 性能指标调优优先级与 Helm 参数协同
在实际调优中，应根据业务场景确定指标优先级：
- 延迟敏感型业务（如实时音视频、交易系统）：延迟 > PPS > 吞吐量 > 连接数 > MTU
- 吞吐量敏感型业务（如大数据传输、日志采集）：吞吐量 > MTU > PPS > 延迟 > 连接数
- 高并发连接型业务（如 API 网关、消息队列）：连接数 > PPS > 延迟 > 吞吐量 > MTU
这些优先级将直接指导后续章节中 Helm Chart 参数的调整策略。例如：
- 若延迟优先，则 Helm 中应启用
kube-proxy.mode: ipvs并调小ipvs.scheduler: rr的 timeout 参数。 - 若吞吐量优先，则 Helm 中应设置
cni.mtu: 9000（需物理网络支持），并启用cni.tunnel: direct减少封装开销。 - 若连接数优先，则 Helm 中应调大
conntrack.max: 1048576和conntrack.tcp.timeoutEstablished: 86400。
核心结论： 网络性能调优不是追求单一指标的极致，而是在吞吐量、延迟、PPS、连接数、MTU 五个维度之间找到业务最优平衡点。Helm 参数协同的作用，正是将这种平衡策略转化为可重复、可版本化的配置声明。