Actions Runner Controller中EphemeralRunners失败导致Pod调度阻塞问题分析

问题背景

在Kubernetes集群中使用Actions Runner Controller管理GitHub Actions自托管运行器时，用户报告了一个关键性问题：当EphemeralRunners进入"Failed"状态后，这些失败的运行器会持续占用资源配额，导致系统无法启动新的Pod来满足运行需求。这种情况在集群资源紧张或调度出现问题时尤为明显。

问题现象

当EphemeralRunners因调度失败(FailedScheduling)等原因进入"Failed"状态后，控制器会记录这些失败实例。典型的状态显示如下：

status:
  currentRunners: 17
  failedEphemeralRunners: 16
  pendingEphemeralRunners: 0
  runningEphemeralRunners: 1

从状态数据可以看出，大量运行器处于失败状态，而实际运行的运行器数量严重不足，导致工作负载无法得到及时处理。

技术原理分析

Actions Runner Controller通过EphemeralRunnerSet资源来管理临时运行器。当运行器Pod因各种原因无法正常调度或启动时，控制器会将其标记为"Failed"状态。根据当前设计，这些失败的运行器不会被自动清理，主要出于以下考虑：

1. 问题诊断保留：保留失败的运行器有助于管理员诊断集群潜在问题
2. 资源保护机制：防止因自动清理导致问题被掩盖
3. 稳定性考虑：避免因频繁重试导致集群负载波动

然而，这种设计在实际使用中带来了明显的副作用：失败的运行器会持续占用min-runner配额，导致系统无法按需扩展，最终影响CI/CD管道的执行效率。

影响范围

该问题在以下场景中影响尤为严重：

1. 集群资源接近饱和时
2. 节点选择器或污点配置不当导致调度失败
3. 资源配额限制严格的环境
4. 长期运行的CI/CD系统

多个用户报告在0.8.3至0.10.1版本中都遇到了相同问题，表明这是一个长期存在的设计缺陷。

解决方案与改进

项目维护团队已经意识到这个问题的严重性，并计划在近期版本中改进这一行为。主要改进方向包括：

1. 引入自动清理机制：在保留足够诊断信息的前提下，自动清理长期处于失败状态的运行器
2. 优化重试逻辑：对可恢复的失败类型实施智能重试
3. 改进状态报告：提供更清晰的失败原因分析

根据项目维护者的说明，相关改进已经合并到代码库中，预计将在接下来的版本发布中包含这些变更。

临时应对措施

在等待官方修复的同时，用户可以采取以下临时措施缓解问题：

1. 手动清理失败的EphemeralRunner资源
2. 适当增加min-runner配置以补偿被占用的配额
3. 监控并优化集群资源分配，减少调度失败的可能性
4. 定期检查并修复可能导致Pod调度失败的集群配置问题

总结

Actions Runner Controller中EphemeralRunners失败处理机制的设计初衷是好的，但在实际生产环境中暴露出明显的局限性。项目团队已经积极响应社区反馈，即将发布的改进将显著提升系统在异常情况下的自恢复能力。对于依赖该组件的重要CI/CD系统，建议关注即将发布的版本更新，并及时评估升级计划。