Actions Runner Controller升级过程中遇到的"Reconciler error"问题分析

在Kubernetes环境中使用Actions Runner Controller（ARC）管理自托管GitHub Actions运行器时，版本升级是一个需要谨慎处理的操作。本文将深入分析从0.9.0升级到0.9.1版本时出现的"Reconciler error"问题，探讨其根本原因和解决方案。

问题现象

当用户尝试将ARC从0.9.0版本升级到0.9.1版本时，控制器日志中会出现以下关键错误信息：

ERROR AutoscalingRunnerSet Failed to update autoscaling runner set with finalizer added
ERROR Reconciler error autoscalingrunnersets.actions.github.com not found

这些错误表明控制器在尝试为AutoscalingRunnerSet资源添加finalizer时遇到了问题，系统无法找到对应的AutoscalingRunnerSet资源。更严重的是，这会导致监听器（listener）和运行器（runner）Pod无法正常创建，即使minRunners设置为1也无法启动任何运行器。

根本原因分析

经过深入调查，发现这个问题主要由以下几个因素导致：

1. 资源清理顺序问题：在升级过程中，如果未按照正确的顺序清理资源，旧的AutoscalingRunnerSet资源可能仍然存在于系统中，导致新版本控制器无法正确处理。

2. finalizer处理机制：控制器在删除资源时需要处理finalizer，但在某些情况下，这个处理过程可能被阻塞或延迟，造成资源处于"悬挂"状态。

3. 控制器响应延迟：在0.9.3版本之前，控制器对资源删除事件的响应存在延迟，特别是在containerMode=kubernetes配置下表现更为明显。

解决方案

针对这个问题，推荐以下解决方案：

1. 正确的升级步骤：

   • 首先卸载所有scale set
   • 等待所有相关资源完全清理完成
   • 卸载控制器
   • 最后安装目标版本的控制器和scale set

2. 资源清理确认：

   • 在升级前，确保所有AutoscalingRunnerSet资源已被完全删除
   • 检查自定义资源定义(CRD)是否与目标版本兼容
   • 必要时可以手动清理finalizer

3. 版本选择：

   • 建议使用0.9.3或更高版本，这些版本已经包含了修复控制器响应延迟问题的补丁

多集群环境下的注意事项

对于在多Kubernetes集群中部署ARC的高可用(HA)配置，升级时需要注意：

• 在一个集群中升级时，另一个集群中的运行器将继续正常工作
• 正在升级的集群会首先移除监听器
• 忙碌的运行器会继续完成当前任务，不会被强制终止
• 空闲的运行器会被系统终止

最佳实践建议

为了避免类似问题，建议采取以下最佳实践：

1. 分离管理：将控制器和scale set作为独立的组件进行管理，不要将它们混合部署在同一个配置中。

2. 监控资源清理：在执行升级操作后，密切监控资源清理过程，确保所有相关资源已被完全删除。

3. 测试环境验证：在生产环境升级前，先在测试环境中验证升级过程。

4. 版本兼容性检查：在升级前，仔细检查版本变更说明，了解可能的破坏性变更。

通过遵循这些建议和解决方案，用户可以更顺利地完成Actions Runner Controller的版本升级，避免遇到"Reconciler error"等问题，确保GitHub Actions运行器服务的持续稳定运行。