Actions Runner Controller 中动态节点供应问题的分析与解决方案

问题背景

在 Kubernetes 集群中使用 Actions Runner Controller (ARC) 管理 GitHub Actions 自托管运行器时，当结合 Karpenter 等动态节点供应工具时，用户可能会遇到运行器 Pod 被过早终止的问题。这一问题在 ARC 0.9.1 版本中尤为明显。

问题现象

当工作负载触发 GitHub Actions 作业时，ARC 控制器会创建相应的 EphemeralRunner 资源。在 Karpenter 环境下，新节点需要约 2 分钟时间完成供应和准备。然而，ARC 控制器在约 1 分钟后就会尝试缩减 EphemeralRunnerSet，而此时 Pod 仍处于 Pending 状态，导致作业被卡住无法执行。

根本原因分析

在 ARC 0.9.1 版本中，控制器实现了一个假设：如果检测到空批次，系统会自动校正运行器数量。设计者原本认为 50 秒足够集群完成准备工作，但在动态节点供应场景下，这一假设不成立。

具体来说，控制器的工作流程存在以下问题：

1. 当作业到达时，控制器创建 EphemeralRunnerSet 并设置副本数为 1
2. 由于节点尚未就绪，Pod 保持 Pending 状态
3. 约 1 分钟后，控制器错误地认为没有活跃作业，将副本数缩减为 0
4. 当节点最终就绪时，运行器 Pod 已被删除

影响范围

这一问题主要影响以下环境配置：

• 使用 Karpenter 或其他动态节点供应工具
• 节点供应时间超过 1 分钟
• 使用 ARC 0.9.1 版本

解决方案

临时解决方案

对于遇到此问题的用户，建议回退到 ARC 0.9.0 版本。该版本虽然可能在极少数情况下增加作业启动延迟，但不会过早终止运行器 Pod。对于要求绝对可靠性的环境，可考虑回退到 0.8.3 版本。

永久修复

开发团队已通过 PR #3453 修复了此问题。修复后的版本（0.9.2 及以上）能够正确处理长时间处于 Pending 状态的 Pod，确保动态供应的节点有足够时间完成准备。

修复的关键改进包括：

1. 移除了对空批次的错误假设
2. 改进了对 Pod 状态的监控逻辑
3. 增加了对动态供应环境的适应性

最佳实践建议

对于使用动态节点供应的用户，建议：

1. 确保使用 ARC 0.9.2 或更高版本
2. 为运行器 Pod 配置适当的资源请求和限制
3. 考虑为 Karpenter 配置合理的节点预热策略
4. 监控节点供应时间和运行器启动延迟指标

技术实现细节

修复后的控制器实现了更智能的缩放逻辑：

• 持续监控 Pod 状态，区分"暂时不可用"和"真正不需要"的情况
• 对 Pending 状态的 Pod 给予更长的等待时间
• 改进与 Kubernetes API 的交互，减少不必要的缩放操作

总结

ARC 与动态节点供应工具的集成是一个复杂但强大的组合。0.9.1 版本中的这一问题提醒我们，在分布式系统中，对资源准备时间的假设需要谨慎处理。通过理解问题本质并应用正确的版本，用户可以构建出既弹性又可靠的 CI/CD 基础设施。