Harvester项目中RKE2 Manifests与VM启动策略的兼容性问题分析

背景与问题现象

在Harvester项目v1.5版本中，用户通过os.write_files配置部署RKE2 Manifests时，如果其中包含设置runStrategy为RerunOnFailure的VirtualMachine资源，会导致整个Harvester集群部署过程卡住无法完成。该问题主要出现在集群初始化阶段，当VM资源尝试在存储网络准备就绪前启动时，会触发系统级阻塞。

技术原理分析

Harvester底层基于RKE2实现，支持通过自动部署清单功能（Auto-Deploying Manifests）在集群初始化时创建资源。问题核心在于：

1. 启动顺序依赖：VirtualMachine资源若设置RerunOnFailure策略，会立即尝试启动，而此时Harvester的核心组件（如存储网络）可能尚未完全初始化。

2. 设置校验机制：Harvester POD启动时会创建settings.harvesterhci CR对象，其中storage-network设置会检查运行中的VMI实例。当空值设置被创建时，若检测到有VM正在运行，会阻止POD继续启动。

3. 资源竞争条件：在测试环境中，由于VM镜像下载耗时可能掩盖了该问题，导致问题表现不稳定。但在生产环境中，当VM资源无外部依赖（如直接使用现有PVC）时，问题会稳定复现。

解决方案实现

项目团队通过以下方式修复该问题：

1. 启动顺序优化：修改settings控制器逻辑，在创建空值设置时跳过VM运行状态检查，允许Harvester核心组件优先完成初始化。

2. 版本兼容性：该修复已包含在v1.5.1-rc2及后续版本中，同时被反向移植到v1.5稳定分支。

典型应用场景

该问题特别影响以下使用场景：

• 需要通过RKE2 Manifests在集群初始化时自动部署关键业务VM
• 使用cloud-init配置自动化部署生产环境
• 需要VM随集群启动自动恢复的高可用场景

用户建议

对于仍在使用受影响版本的用户，可采用以下临时解决方案：

1. 将VM的runStrategy改为Manual，待集群完全启动后手动启动VM
2. 在VM配置中添加适当的affinity规则，确保依赖服务就绪后再启动
3. 对关键业务VM添加initContainer检查依赖服务可用性

技术启示

该案例揭示了Kubernetes生态系统中以下重要设计原则：

1. 控制器启动顺序对系统稳定性的关键影响
2. 声明式API中状态检查的边界条件处理
3. 基础设施层与应用层的启动依赖管理

项目团队通过该修复增强了Harvester在复杂部署场景下的鲁棒性，为自动化部署提供了更可靠的底层支持。