网卡中断不平衡（IRQ imbalance）会导致K8s网络抖动，表现为TCP重传增多、SYN_RECV堆积、Pod通信超时等；需通过检查/proc/interrupts与/proc/softirqs确认中断倾斜，调整smp_affinity_list绑定多队列到不同CPU，并配合RSS启用、卸载项关闭及NUMA对齐优化。
网卡中断不平衡（IRQ imbalance）在K8s集群中虽不常被直接归因为“网络隔离抖动”，但它确实会引发底层网络收发延迟升高、TCP重传增多、Pod间通信偶发超时甚至Service访问不稳定等现象，尤其在高吞吐或低延迟敏感场景下表现明显。这类问题通常表现为：容器内ping通但curl慢、netstat显示大量SYN_RECV堆积、ss -i查到重传率上升，而kubectl describe node和calicoctl ipam show又无异常——此时需下沉到宿主机内核与硬件层排查。
确认是否为IRQ不平衡导致的网络抖动
在疑似抖动的节点上执行以下检查：
- 查看软中断分布：
cat /proc/softirqs | grep -E "(NET_RX|NET_TX)"，若某CPU核心数值远高于其他（如相差5倍以上），说明网络软中断负载不均 - 查看硬中断绑定：
cat /proc/interrupts | grep -i eth（替换eth为实际网卡名，如ens1f0），观察各CPU列数值是否严重倾斜（例如仅CPU0接收95%以上中断） - 检查网卡多队列状态：
ethtool -l <iface>确认是否启用RSS（Receive Side Scaling），再用ethtool -S <iface> | grep rx_queue看各队列收包计数是否均衡 - 观察抖动时段的
/proc/net/snmp中TcpRetransSegs是否突增，结合dmesg -T | grep -i "irq"查有无“IRQ affinity changed”或“potential CPU stall”告警
调整网卡中断亲和性（IRQ Affinity）
目标是将同一网卡的多个RX/TX队列中断分散绑定到不同CPU核心，避免单核过载。操作分三步：
- 获取网卡支持的中断向量数：
cat /sys/class/net/<iface>/device/msi_irqs/* 2>/dev/null | wc -l - 生成均衡掩码（以8核为例）：
printf "%x\n" $((2#10101010))→ 得aa，表示绑定CPU0/2/4/6；也可用脚本自动分配（推荐使用irqbalance服务替代手动） - 写入中断亲和性：
echo aa > /proc/irq/<irq_num>/smp_affinity_list（需逐个IRQ设置，<irq_num>从/proc/interrupts中提取） -
持久化建议：禁用
irqbalance服务（systemctl stop --now irqbalance），改用systemd服务或rc.local在启动时运行自定义affinity脚本，避免被覆盖
优化网卡驱动与队列配置
仅调IRQ不够，还需配合硬件能力释放多队列性能：
- 启用RSS并校准队列数：
ethtool -L <iface> combined 8（设为CPU逻辑核数，最大不超过网卡规格） - 开启GRO/LRO（谨慎）：
ethtool -K <iface> gro on可减少中断次数，但可能增加延迟抖动，建议压测验证 - 关闭无用卸载项防干扰：
ethtool -K <iface> tso off gso off lro off（特别是虚拟化环境或旧驱动下） - 确认NUMA拓扑对齐：用
lscpu和numactl --hardware检查网卡PCIe插槽所属NUMA节点，并确保kubelet启动参数含--topology-manager-policy=static，让关键Pod绑定同NUMA节点CPU+内存
验证与可观测加固
调整后不能只看“不报错”，要建立量化基线：
- 持续采集
/proc/interrupts和/proc/softirqs差值，用Prometheus+Node Exporter暴露为指标node_interrupts_total和node_softirqs_total - 在Pod内部署轻量探针（如
iperf3或sockperf），定时测试跨节点Pod间RTT标准差，抖动下降30%以上视为有效 - 启用
kernel.trap_unhandled和net.core.netdev_max_backlog调优（如设为5000），缓解突发流量冲击 - 若使用Calico，检查
FELIX_LOGSEVERITYSYS是否开启，其日志中"failed to send packet"高频出现往往关联IRQ拥塞
这类问题不显于K8s抽象层，却真实影响业务SLA。关键是把“网络抖动”拆解为可测量的硬件事件，再用确定性手段收敛中断路径。调完别忘了压测对比，否则容易误判为“已修复”。
