Kubernetes非主机网络部署时应用吞吐量周期性下降原因排查

核心原因 #

1. 应用CPU绑核与网络处理线程的资源竞争 #

当微服务被绑定到单个CPU核心并饱和运行时，内核的网络软中断（如NET_RX，负责处理数据包接收）以及Calico的网络转发组件（如felix、内核态iptables规则处理）会与应用线程争夺同一CPU的时间片。非HostNetwork模式下，Pod间通信必须经过Calico创建的虚拟网卡（cali*）和内核网络栈，这些操作依赖的内核线程/软中断若被应用线程长时间抢占，会导致数据包积压，进而引发周期性的吞吐量骤降——直到软中断被调度执行，积压的数据包被批量处理，吞吐量才会短暂恢复。

2. 内核网络队列的周期性溢出 #

应用CPU饱和时，无法及时处理内核网络接收队列中的数据包，当队列达到上限后会触发数据包丢弃。而由于绑核限制，内核无法快速调度其他CPU资源处理队列，只能等待当前CPU的应用时间片结束后才能清理队列，这就表现为周期性的吞吐量波动。

3. Calico网络模式的隐性开销 #

若Calico配置为VXLAN/IPIP隧道模式（即使同一节点），Pod间通信会额外增加数据包封装/解封装的开销。当应用CPU满负荷时，这些额外开销会加剧处理延迟，放大周期性的性能波动。

验证手段 #

• 监控内核软中断：执行watch -d cat /proc/softirqs，观察NET_RX列的数值变化，若某CPU的NET_RX出现周期性突增，说明该CPU的软中断被延迟处理。
• 检查Calico组件负载：执行kubectl top pods -n kube-system，查看calico-node的CPU使用率，若吞吐量下降时段其CPU占用明显波动，说明存在资源竞争。
• 查看网络队列状态：用ss -ti查看Pod监听端口的队列长度，或ethtool -S <cali-xxx>（替换为实际Calico虚拟网卡名）查看队列溢出统计。
• 调整绑核测试：临时解除应用的CPU绑核，或绑定到其他空闲CPU，观察周期性吞吐量下降是否消失。

解决建议 #

1. 分离应用与网络处理的CPU资源 #

• 将应用绑定到特定CPU核心，同时通过irqbalance服务或手动配置，将虚拟网卡（cali*）的中断请求分配到其他空闲CPU，避免网络软中断与应用线程竞争同一核心。
• 避免使用严格的cpuset绑核，改用CPU请求（requests）和限制（limits），让Kubernetes灵活分配CPU资源给内核和Calico组件。

2. 优化Calico配置 #

• 确认Calico使用同一节点直接路由模式：修改Calico的IPPool配置，设置spec.ipip.mode: Never和spec.vxlan.mode: Never，避免不必要的隧道封装开销。
• 为calico-node Pod配置合理的CPU资源请求与限制，确保其有足够资源处理网络规则与转发。

3. 调整内核网络参数 #

• 增大网络接收队列容量：执行sysctl -w net.core.rx_queue_len=4096（可根据实际情况调整），减少数据包丢弃。
• 启用软中断负载均衡：设置sysctl -w net.core.busy_read=50和sysctl -w net.core.busy_poll=50，让内核在高负载时更高效地处理网络中断。

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