安装NetworkManager后导致Cloud-Init注入失败的核心原因在于网络配置权的冲突，即NetworkManager与Cloud-Init默认使用的网络渲染器（如networkd或eni）争夺/etc/network/interfaces或相关配置文件的控制权，解决方案是统一配置渲染器并调整Cloud-Init的配置优先级。
当用户在云服务器环境中安装 networkmanager 之后，经常会遇到Cloud-Init无法正常注入用户密码或SSH密钥的问题，这并非软件本身的缺陷，而是系统内部网络管理组件协同工作的机制冲突，Cloud-Init在初始化阶段需要操作网络配置来确保实例能被正确管理，而NetworkManager作为强大的网络控制工具，往往会接管系统网络配置，导致Cloud-Init的配置指令被覆盖或忽略，要彻底解决这一问题，必须深入理解两者的交互逻辑，并进行针对性的配置隔离。
问题根源深度解析：配置渲染器的“争夺战”
要解决注入失败问题,首先要明白为什么会失败，在Linux系统中，网络配置可以通过多种方式管理，Cloud-Init和NetworkManager默认的“工作对象”可能并不一致。
-
渲染器机制冲突
Cloud-Init支持多种网络配置渲染器，常见的包括networkd（Systemd-networkd）和netplan，在旧版本中则直接操作/etc/network/interfaces，默认情况下，Cloud-Init可能配置为使用networkd渲染器。
当用户执行安装 networkmanager 操作后，NetworkManager默认会将自己设置为系统的主要网络配置服务，如果Cloud-Init尝试通过networkd写入配置，而NetworkManager正在运行并监控网络接口，就会发生配置被覆盖或写入失败的情况。 -
配置文件锁定与覆盖
NetworkManager倾向于接管/etc/network/interfaces中定义的接口，或者通过其内部配置进行管理，如果Cloud-Init在启动早期注入了配置（如IP地址、路由或DNS），随后NetworkManager服务启动，可能会刷新连接，导致Cloud-Init注入的临时配置失效，进而导致后续的密码注入脚本因网络不可达或环境变量错误而中断。 -
服务启动顺序干扰
Cloud-Init的执行阶段分为local、network、config等，如果在network阶段网络未能按预期拉起，后续的config阶段就无法从元数据服务获取用户数据，从而导致密钥或密码注入失败。
核心解决方案：统一渲染器与配置隔离
解决冲突最有效的方法是“统一战线”，即让Cloud-Init明确使用NetworkManager作为其渲染器，或者禁止NetworkManager接管特定接口，以下是经过验证的专业解决方案：
修改Cloud-Init配置，指定NetworkManager为渲染器（推荐）
这是最符合现代Linux发行版理念的解法,让Cloud-Init“投靠”NetworkManager，由Cloud-Init生成NetworkManager兼容的配置文件。
- 编辑Cloud-Init主配置文件
打开/etc/cloud/cloud.cfg文件，查找network配置段落。 - 设置渲染器参数
在配置中明确指定渲染器为NetworkManager：network: version: 2 renderer: NetworkManager
通过此设置,Cloud-Init将不再生成
networkd或interfaces文件，而是生成/etc/NetworkManager/system-connections/下的连接文件，完美避开冲突。 - 清理旧配置并重启
删除/etc/network/interfaces中可能存在的冲突配置，重启Cloud-Init服务：cloud-init clean systemctl restart cloud-init
配置NetworkManager忽略Cloud-Init管理的接口
如果必须保持Cloud-Init原有的渲染方式，则需要限制NetworkManager的权限。
- 修改NetworkManager配置
编辑/etc/NetworkManager/NetworkManager.conf，确保其不管理eth0（或主网卡名称）。 - 设置unmanaged-devices
在[keyfile]部分添加：[keyfile] unmanaged-devices=interface-name:eth0
这样NetworkManager会忽略主网卡,Cloud-Init可以继续通过
networkd或interfaces文件控制网络，保证注入通道畅通。
实施步骤与验证流程
在完成上述配置修改后,必须按照严格的流程进行验证，确保问题彻底解决。
- 环境清理
执行cloud-init clean命令，清除之前的实例数据和日志，这是测试环节最关键的一步，否则Cloud-Init会认为已经完成初始化而跳过注入步骤。 - 重启实例
执行reboot重启服务器。 - 检查注入结果
重启后，检查/var/log/cloud-init-output.log日志文件。- 查找
cc_set_passwords模块的执行日志，确认是否有“Setting passwords”或“Adding SSH keys”的成功提示。 - 验证SSH连接：使用注入的密钥尝试连接服务器。
- 验证密码登录：尝试通过控制台使用注入的密码登录。
- 查找
预防措施与最佳实践
为了避免在后续运维中再次出现此类问题,建议在制作云主机镜像或初始化系统时遵循以下原则：
- 预装配置适配
如果镜像必须预装NetworkManager，请务必在镜像打包前修改/etc/cloud/cloud.cfg，将渲染器预设为NetworkManager。 - 锁定关键配置文件
使用chattr +i命令锁定关键配置文件并非良策，反而可能导致Cloud-Init报错，正确的做法是通过软件本身的配置项（如renderer）来解决兼容性。 - 日志监控
定期检查/var/log/cloud-init.log，如果发现DataSource超时错误，通常是网络未拉起导致，应第一时间检查NetworkManager的状态。
安装NetworkManager后使用Cloud-Init注入密钥或密码失败怎么办？ 核心对策在于解决网络控制权的冲突，通过将Cloud-Init的网络渲染器显式指向NetworkManager，或者限制NetworkManager的管理范围，可以确保Cloud-Init在网络初始化阶段顺利拉起网络服务，从而获取元数据并完成用户数据的注入，这一过程不仅要求对Linux网络服务有深入理解，更需要精确的配置管理。
相关问答
为什么安装NetworkManager后，Cloud-Init修改的IP地址会失效？
这是因为NetworkManager和Cloud-Init配置IP的方式不同步，Cloud-Init可能通过networkd写入了IP配置，但NetworkManager服务启动后，检测到接口未被其管理或配置冲突，会重新发起DHCP请求或应用默认配置，覆盖了Cloud-Init的静态IP设置，建议在/etc/cloud/cloud.cfg中配置静态IP信息，并指定renderer: NetworkManager，这样Cloud-Init生成的配置文件会被NetworkManager直接识别并加载。
修改配置后，如何在不重启服务器的情况下重新注入密钥？
虽然通常建议重启以模拟实例首次启动环境,但在紧急情况下可以尝试手动触发，首先执行cloud-init clean清理状态，然后执行cloud-init init --local和cloud-init init尝试重新运行初始化模块，但需注意，网络环境的重置可能导致当前连接中断，建议在控制台（VNC）模式下操作。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/141641.html
