安装NetworkManager后注入密钥失败怎么办？Cloud-Init密钥注入失败解决方法

安装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默认的“工作对象”可能并不一致。

1. 渲染器机制冲突
   Cloud-Init支持多种网络配置渲染器，常见的包括networkd（Systemd-networkd）和netplan，在旧版本中则直接操作/etc/network/interfaces，默认情况下，Cloud-Init可能配置为使用networkd渲染器。
   当用户执行安装networkmanager操作后，NetworkManager默认会将自己设置为系统的主要网络配置服务，如果Cloud-Init尝试通过networkd写入配置，而NetworkManager正在运行并监控网络接口，就会发生配置被覆盖或写入失败的情况。

2. 配置文件锁定与覆盖
   NetworkManager倾向于接管/etc/network/interfaces中定义的接口，或者通过其内部配置进行管理，如果Cloud-Init在启动早期注入了配置（如IP地址、路由或DNS），随后NetworkManager服务启动，可能会刷新连接，导致Cloud-Init注入的临时配置失效，进而导致后续的密码注入脚本因网络不可达或环境变量错误而中断。

3. 服务启动顺序干扰
   Cloud-Init的执行阶段分为local、network、config等，如果在network阶段网络未能按预期拉起，后续的config阶段就无法从元数据服务获取用户数据，从而导致密钥或密码注入失败。

核心解决方案：统一渲染器与配置隔离

解决冲突最有效的方法是“统一战线”，即让Cloud-Init明确使用NetworkManager作为其渲染器，或者禁止NetworkManager接管特定接口，以下是经过验证的专业解决方案：

修改Cloud-Init配置，指定NetworkManager为渲染器（推荐）

这是最符合现代Linux发行版理念的解法,让Cloud-Init“投靠”NetworkManager，由Cloud-Init生成NetworkManager兼容的配置文件。

1. 编辑Cloud-Init主配置文件
   打开/etc/cloud/cloud.cfg文件，查找network配置段落。
2. 设置渲染器参数
   在配置中明确指定渲染器为NetworkManager：
   network:version:2renderer:NetworkManager

   通过此设置,Cloud-Init将不再生成networkd或interfaces文件，而是生成/etc/NetworkManager/system-connections/下的连接文件，完美避开冲突。

3. 清理旧配置并重启
   删除/etc/network/interfaces中可能存在的冲突配置，重启Cloud-Init服务：
   cloud-initcleansystemctlrestartcloud-init

配置NetworkManager忽略Cloud-Init管理的接口

如果必须保持Cloud-Init原有的渲染方式，则需要限制NetworkManager的权限。

1. 修改NetworkManager配置
   编辑/etc/NetworkManager/NetworkManager.conf，确保其不管理eth0（或主网卡名称）。
2. 设置unmanaged-devices
   在[keyfile]部分添加：
   [keyfile]unmanaged-devices=interface-name:eth0

   这样NetworkManager会忽略主网卡,Cloud-Init可以继续通过networkd或interfaces文件控制网络，保证注入通道畅通。

实施步骤与验证流程

在完成上述配置修改后,必须按照严格的流程进行验证，确保问题彻底解决。

1. 环境清理
   执行cloud-initclean命令，清除之前的实例数据和日志，这是测试环节最关键的一步，否则Cloud-Init会认为已经完成初始化而跳过注入步骤。
2. 重启实例
   执行reboot重启服务器。
3. 检查注入结果
   重启后，检查/var/log/cloud-init-output.log日志文件。
   • 查找cc_set_passwords模块的执行日志，确认是否有“Settingpasswords”或“AddingSSHkeys”的成功提示。
   • 验证SSH连接：使用注入的密钥尝试连接服务器。
   • 验证密码登录：尝试通过控制台使用注入的密码登录。

预防措施与最佳实践

为了避免在后续运维中再次出现此类问题,建议在制作云主机镜像或初始化系统时遵循以下原则：

1. 预装配置适配
   如果镜像必须预装NetworkManager，请务必在镜像打包前修改/etc/cloud/cloud.cfg，将渲染器预设为NetworkManager。
2. 锁定关键配置文件
   使用chattr+i命令锁定关键配置文件并非良策，反而可能导致Cloud-Init报错，正确的做法是通过软件本身的配置项（如renderer）来解决兼容性。
3. 日志监控
   定期检查/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-initclean清理状态，然后执行cloud-initinit--local和cloud-initinit尝试重新运行初始化模块，但需注意，网络环境的重置可能导致当前连接中断，建议在控制台（VNC）模式下操作。