Actions Runner Controller中minRunners参数失效问题分析与解决方案

问题背景

在使用GitHub Actions Runner Controller（ARC）管理自托管运行器时，用户遇到了minRunners参数不被遵守的问题。具体表现为：虽然配置了minRunners: 6，但系统运行一段时间后，空闲运行器数量会无故减少到2个，与预期的最小6个运行器不符。

技术分析

配置参数解析

ARC提供了两个关键参数控制运行器数量：

• minRunners：定义空闲状态时应保持的最小运行器数量
• maxRunners：定义可扩展到的最大运行器数量

在标准情况下，ARC会根据当前作业负载自动调整运行器数量，但应始终保证至少有minRunners个运行器处于就绪状态。

问题根源

通过日志分析和技术讨论，发现该问题可能由以下几个原因导致：

1. Kubernetes资源残留：当使用SPOT实例（如AWS的Ocean）时，可能因节点回收导致运行器作业卡在CRD（Custom Resource Definition）中未被正确清理

2. 运行器失败累积：当单个运行器Pod失败超过5次时，ARC会清理该Pod但保留EphemeralRunner资源用于故障诊断，这可能导致控制器统计的运行器数量与实际Pod数量不一致

3. 最终器（Finalizer）问题：资源删除时可能因最终器阻塞导致资源未被完全清理

解决方案

彻底清理残留资源

1. 首先卸载所有ARC相关Helm chart
2. 手动检查并清理所有残留的EphemeralRunner资源
3. 使用--merge参数更新CRD的finalizer设置
4. 确认所有相关资源已被完全删除

配置优化建议

1. 对于生产环境，建议使用On-Demand节点而非SPOT实例，以提高稳定性
2. 定期检查EphemeralRunner资源状态，确保没有失败累积
3. 监控ARC控制器日志，关注运行器数量计算决策过程

实施效果

经过上述清理和配置调整后，系统已稳定运行一周以上，minRunners参数能够被正确遵守，运行器数量始终保持在配置的最小值以上。

经验总结

ARC作为GitHub Actions自托管运行器的管理工具，在复杂Kubernetes环境中可能会遇到资源管理问题。特别是在使用弹性节点池时，需要特别注意：

1. 资源清理机制可能因节点回收而中断
2. 控制器统计逻辑与实际资源状态可能存在差异
3. 定期维护和监控是保证系统稳定运行的关键

通过这次问题排查，我们认识到在云原生环境下，资源生命周期管理的重要性，以及理解控制器内部工作机制对于问题诊断的价值。