Actions Runner Controller多ScaleSet部署问题分析与解决方案

背景介绍

在GitHub Actions自托管运行器的管理方案中，Actions Runner Controller是一个重要的Kubernetes控制器，它允许用户在Kubernetes集群中动态地管理和扩展自托管运行器。其中，Runner ScaleSet功能支持创建多个运行器组，每个组可以独立配置和管理。

问题现象

用户在使用Actions Runner Controller时，尝试通过单个控制器部署三个Runner ScaleSet。其中：

• 一个ScaleSet工作正常，可以成功运行工作流
• 另外两个ScaleSet虽然监听器已注册且日志显示无错误，但在GitHub仓库的Actions Runner界面中不可见

技术分析

从日志信息可以看出，控制器能够成功获取GitHub的runner注册令牌和JWT，并能正确计算目标runner数量。但某些ScaleSet的运行器未能正确注册到GitHub，可能的原因包括：

1. GitHub配置问题：虽然控制器能获取令牌，但runner注册过程可能失败
2. 权限问题：不同ScaleSet可能需要的权限配置不同
3. 命名冲突：多个ScaleSet使用相同配置可能导致冲突
4. 网络连接问题：与GitHub服务器的连接可能不稳定

解决方案

经过排查，最终通过以下步骤解决了问题：

1. 重新创建所有ScaleSet：彻底清理并重新部署所有ScaleSet配置
2. 企业级重新连接：在GitHub企业版层面重新建立连接关系

最佳实践建议

对于需要在单个控制器下管理多个Runner ScaleSet的用户，建议：

1. 明确命名规范：为每个ScaleSet使用独特的名称和runner组
2. 独立配置检查：确保每个ScaleSet的配置（如资源请求、安全上下文等）都是独立的
3. 分阶段部署：先部署一个ScaleSet验证基本功能，再逐步添加其他ScaleSet
4. 监控日志：密切关注控制器和runner pod的日志，及时发现注册问题

总结

Actions Runner Controller支持通过单个控制器管理多个Runner ScaleSet，但在实际部署时需要注意配置的独立性和完整性。遇到runner不可见的问题时，建议从GitHub连接和配置重新验证入手，通常能有效解决问题。