Kubernetes Pod运行相同程序吞吐量低于GCloud VM，如何排查配置问题

你当前遇到的iperf带宽达标但业务程序吞吐量低的问题，核心是业务场景（大概率是小包/高并发传输）下的额外开销被放大，可按以下优先级调整配置：

1. Kubernetes网络层优化 #

• 验证CNI overhead影响：先将Pod的网络模式改为HostNetwork测试吞吐量，如果恢复到VM水平，说明损耗来自CNI插件：
  • 如果你当前用的是Calico/Flannel的VXLAN封装模式，替换为BGP无封装模式，可消除封包解包的CPU开销
  • 开启CNI插件的网卡offload配置，将校验和、分片计算卸载到物理网卡
• 调整kube-proxy转发模式：如果当前kube-proxy用的是iptables/userspace模式，切换为ipvs模式，同时调大ipvs哈希表大小、连接超时参数，高并发场景下转发性能可提升30%以上
• 排查Sidecar代理损耗：如果集群开启了Istio等服务网格Sidecar自动注入，进出Pod的流量都会被Sidecar代理转发，会产生20%~50%的性能损耗，可先关闭对应Pod的Sidecar注入验证，若确认为Sidecar导致，可调整Sidecar的资源配额、开启非业务端口的流量直通规则。

2. Pod内核参数适配 #

默认Pod的内核参数继承自CRI或节点全局配置，多数场景下没有做网络发送优化，可给Pod配置以下安全sysctl参数：

• 调大TCP收发缓冲区：net.core.wmem_max=16777216、net.core.rmem_max=16777216，net.ipv4.tcp_wmem="4096 87380 16777216"
• 调大网卡队列长度：net.core.netdev_max_backlog=10000
• 更换TCP拥塞控制算法为bbr，公网/跨节点传输场景下吞吐量表现优于默认的cubic算法
• 进入Pod执行ethtool -k 网卡名，确认tx/rx checksum offload、tcp segmentation offload功能已开启，未开启的话需要调整节点网卡配置。

3. CPU调度与NUMA拓扑优化 #

• 开启kubelet的Static CPU Manager策略：你当前Pod是Guaranteed QoS且CPU配置为整数核，开启该策略后Pod会被分配独占的物理CPU核心，消除进程跨核心调度的上下文切换开销
• 开启kubelet的Topology Manager策略：避免Pod的CPU、内存、网卡资源被分配到不同的NUMA节点，消除跨NUMA访问的额外延迟
• 检查Pod的节点亲和配置，确认Pod没有被调度到负载过高、或CPU/内存资源碎片化的节点上。

4. 其他配置检查 #

• 调整CRI运行时的默认ulimit配置：默认容器的最大文件句柄数ulimit -n通常为1024，高并发连接场景下会成为瓶颈，可在Pod的securityContext中调大该参数，或修改containerd/docker的全局默认ulimit配置
• 清理节点多余的iptables/ipvs规则：大量无用的匹配规则会延长数据包处理耗时，可执行iptables-save | wc -l统计规则数量，冗余规则过多的话做定向清理
• 小包传输场景下，可开启net.core.rps、net.core.rfs配置，将不同的TCP流分发到不同CPU核心并行处理，提升发送效率。

内容的提问来源于stack exchange，提问作者Tinyden