Multus-CNI共享挂载问题排查与解决方案

问题背景

在使用Multus-CNI项目时，用户可能会遇到DaemonSet无法正常启动的问题。具体表现为kubelet日志中反复出现错误信息："path '/opt/cni/bin' is mounted on '/' but it is not a shared mount"。这种情况通常发生在Kubernetes节点上，特别是当使用containerd作为容器运行时环境时。

技术原理分析

这个问题的本质是Linux挂载命名空间的共享属性配置问题。在Linux系统中，挂载点可以有不同的传播类型：

1. 私有挂载(PRIVATE): 挂载事件不会传播到其他挂载点
2. 共享挂载(SHARED): 挂载事件会双向传播
3. 从属挂载(SLAVE): 挂载事件只能单向传播

当容器运行时需要将主机目录挂载到容器内部时，如果原始挂载点是私有属性，就会导致挂载传播失败。这正是Multus-CNI DaemonSet启动时遇到的问题。

解决方案

解决这个问题的核心方法是修改根文件系统的挂载传播属性：

mount --make-rshared /

这条命令的作用是将根文件系统/的挂载传播属性改为"递归共享"(rshared)，这意味着：

1. 所有子挂载点都会继承这个共享属性
2. 挂载事件会在所有命名空间之间双向传播
3. 容器运行时可以正确地将主机目录映射到容器内部

深入理解

在Kubernetes环境中，CNI插件需要访问主机上的网络配置和二进制文件。Multus-CNI作为CNI的meta插件，需要将主机的/opt/cni/bin目录挂载到它的Pod中。当这个目录的挂载传播属性不恰当时，容器运行时(如containerd)就无法完成这个挂载操作。

最佳实践建议

1. 生产环境预处理: 在部署Kubernetes集群前，就应该在所有节点上设置好挂载传播属性
2. 安全考虑: 共享挂载会带来一定的安全风险，应该评估是否真的需要这种配置
3. 替代方案: 如果可能，考虑使用其他不需要共享挂载的CNI插件部署方式

总结

Multus-CNI作为Kubernetes多网络方案的关键组件，其正常运行依赖于正确的系统配置。理解Linux挂载命名空间和传播属性对于解决这类问题至关重要。通过适当配置挂载传播属性，可以确保Multus-CNI DaemonSet能够正常启动和工作，为Kubernetes集群提供灵活的多网络支持。