Actions Runner Controller 中Listener Pod在Scale-Set升级后失败的问题分析

问题背景

在使用Actions Runner Controller的gha-runner-scale-set组件时，用户报告了一个在版本升级过程中出现的典型问题。当从2.317.0版本升级到2.318.0版本后，Listener Pod会持续失败并重启。

问题现象

升级完成后，Listener Pod的日志显示以下关键错误信息：

2024/08/28 09:43:34 Application returned an error: handling initial message failed: could not patch ephemeral runner set , patch JSON: {"spec":{"patchID":0,"replicas":1}}, error: ephemeralrunnersets.actions.github.com "self-hosted-hide-rhtjx" not found

从日志中可以清晰地看到，Listener Pod尝试访问一个名为"self-hosted-hide-rhtjx"的EphemeralRunnerSet资源，但该资源在集群中并不存在。

根本原因分析

经过深入分析，这个问题源于Actions Runner Controller当前版本的设计限制：

1. 资源依赖关系：AutoscalingListener资源与特定的EphemeralRunnerSet资源紧密耦合，在AutoscalingListener的spec中明确引用了EphemeralRunnerSet的名称。

2. 升级机制限制：当前版本的升级过程实际上是先卸载旧版本再安装新版本，而不是真正的原地升级。这导致在升级过程中，旧的EphemeralRunnerSet资源被删除，而AutoscalingListener仍然保留着对旧资源的引用。

3. 资源重建顺序：在升级过程中，新的EphemeralRunnerSet资源会使用新的名称创建，但AutoscalingListener没有被正确更新以指向新的EphemeralRunnerSet。

解决方案

目前推荐的解决方法是按照官方文档中的升级流程操作：

1. 在升级前手动删除现有的AutoscalingListener资源
2. 执行版本升级操作
3. 系统会自动创建新的AutoscalingListener和EphemeralRunnerSet资源

这种手动干预的方式虽然不够优雅，但能确保升级后系统的正常运行。

未来改进方向

开发团队已经意识到当前升级流程的不足，并计划在未来版本中改进升级机制，目标是实现：

1. 真正的原地升级能力
2. 自动处理资源引用更新
3. 更平滑的版本过渡体验

最佳实践建议

对于正在使用Actions Runner Controller的生产环境，建议：

1. 仔细阅读并遵循官方升级指南
2. 在非高峰期执行升级操作
3. 升级前做好备份和回滚准备
4. 监控升级后的系统状态，特别是Listener Pod的运行情况

通过理解这个问题的本质和解决方案，用户可以更安全地进行版本升级操作，确保自托管Runner服务的持续可用性。