Multus CNI 插件中主CNI配置的实践指南

背景介绍

Multus CNI 作为 Kubernetes 中的多网络插件解决方案，允许 Pod 连接多个网络接口。在实际生产环境中，特别是当集群中存在多个 CNI 插件时，正确配置主 CNI（Primary CNI）变得尤为重要。本文深入探讨在 Multus 厚插件（Thick Plugin）模式下如何确保系统正确识别和使用主 CNI。

问题现象

在默认配置下，Multus 厚插件会将 multusConfigFile 参数设置为 "auto"，这意味着 Multus 会自动选择 CNI 配置文件。当集群中安装了多个 CNI 插件（如 AWS VPC CNI 和 Istio CNI 并存）时，这种自动选择机制可能导致 Multus 意外选择了非预期的 CNI 作为主 CNI。

解决方案

通过配置 multusMasterCNI 参数可以明确指定主 CNI，避免自动选择带来的不确定性。例如，在 AWS EKS 环境中使用 VPC CNI 作为主 CNI 时，可以在 Multus 的 daemon-config 中添加：

"multusMasterCNI": "10-aws.conflist"

这一配置明确告诉 Multus 使用指定的 CNI 配置文件作为主 CNI，确保网络连接的正确性和稳定性。

技术细节

厚插件与薄插件的区别

Multus 提供了两种部署模式：

1. 薄插件（Thin Plugin）：依赖主 CNI 的配置文件，通过 clusterNetwork 参数指定主 CNI
2. 厚插件（Thick Plugin）：包含完整的 Multus 功能，通过 multusMasterCNI 参数配置主 CNI

配置优先级

当存在多个 CNI 插件时，Multus 会按照以下顺序处理：

1. 检查是否明确配置了 multusMasterCNI
2. 如果没有明确配置，则尝试自动选择
3. 自动选择可能基于文件名的字母顺序或其他因素

生产环境建议

对于生产环境，特别是当集群中存在多个 CNI 插件时，强烈建议：

1. 明确配置 multusMasterCNI 参数
2. 避免依赖自动选择机制
3. 在文档中记录主 CNI 的选择和配置

实施步骤

1. 编辑 Multus 的 daemon-config 配置文件
2. 添加 multusMasterCNI 参数并指定主 CNI 的配置文件名称
3. 重启 Multus 相关组件使配置生效
4. 验证 Pod 网络连接是否符合预期

总结

正确配置 Multus 的主 CNI 对于 Kubernetes 集群的网络稳定性至关重要。通过明确指定 multusMasterCNI 参数，可以避免在多 CNI 环境下出现网络选择问题，确保集群网络的可靠性和一致性。这一实践对于使用 AWS VPC CNI 与 Istio CNI 等组合的环境尤为重要。