Multus-CNI大规模部署中网络资源释放问题的深度解析

问题背景

在Kubernetes集群中使用Multus-CNI配合SR-IOV网络设备时，运维人员可能会遇到一个典型问题：当大规模部署Pod（例如600个Pod）并尝试删除这些Pod时，附加的CNI网络接口无法正常释放。这个问题在基于InfiniBand的SR-IOV虚拟功能(VF)场景下尤为突出。

问题现象

具体表现为Pod终止过程中出现以下关键错误信息：

Failed to destroy network for sandbox: plugin type="multus" name="multus-cni-network" failed (delete): 
delegateDel: error invoking ConflistDel - "sriov_gpu_ib4": conflistDel: error in getting result from DelNetworkList: 
error reading cached NetConf in /var/lib/cni/ib-sriov

技术分析

1. 根本原因

该问题的核心在于CNI插件在执行删除操作时无法正确读取缓存的网络配置(NetConf)。具体表现为：

• 当Pod被删除时，Multus-CNI需要依次删除所有附加网络接口
• SR-IOV CNI插件尝试从/var/lib/cni/ib-sriov目录读取缓存的网络配置
• 由于某些原因（可能是文件权限或并发访问问题），这些缓存文件无法被正确访问

2. 环境因素

典型的问题环境配置：

• Kubernetes 1.29.5
• Multus-CNI v3.8
• SR-IOV网络操作器v1.2.0
• Whereabouts IPAM v0.7
• 使用InfiniBand SR-IOV虚拟功能

3. 解决方案验证

经过验证，将ib-sriov-cni组件从v1.0.2升级到v1.0.3可以解决这个特定的缓存读取问题。这表明该问题可能是早期版本中的一个已知bug。

深入探讨

大规模部署的挑战

当扩展到更大规模的部署（如2400个Pod分布在300个节点上）时，会出现新的性能瓶颈：

1. CNI附加延迟：大量Pod同时创建会导致CNI插件处理请求积压
2. 超时问题：Kubernetes控制平面默认的超时设置可能不足
3. 资源竞争：多个Pod同时创建/删除导致CNI插件资源竞争

最佳实践建议

1. 版本控制：始终保持CNI插件的最新稳定版本
2. 分批部署：大规模部署时采用分批滚动更新策略
3. 监控配置：
   • 适当调整kubelet的Pod创建/删除超时参数
   • 监控/var/lib/cni目录的文件系统性能
4. 资源预留：为CNI插件操作预留足够的系统资源

结论

Multus-CNI与SR-IOV的结合为Kubernetes提供了强大的网络功能扩展能力，但在大规模部署时需要特别注意网络资源的生命周期管理。通过版本升级和合理的部署策略，可以有效解决网络资源释放问题。对于超大规模部署，建议进行充分的性能测试和容量规划，确保集群网络组件的稳定性。