GitHub ARC 0.15.0优化大规模运行器可靠性

GitHub Actions Runner Controller（ARC）0.15.0于10月1日发布，面向在Kubernetes上运行自托管GitHub Actions运行器的组织，重点改进可靠性、扩展效率和可观测性。该版本通过降低不必要的Kubernetes API交互，并让升级、重启和关机过程更加可预测，尤其适合管理大量运行器扩展集的场景。

ARC是一个Kubernetes操作符，可根据工作流需求动态创建和删除自托管运行器。企业无需长期维护预配置的运行器池，即可控制构建环境、网络访问、计算资源和任务隔离。0.15.0将资源同步从完整更新请求改为patch请求，缩小API负载；同时把运行器状态聚合转移到EphemeralRunnerSet和AutoscalingRunnerSet的指标中，减少状态更新次数。

控制器还会过滤传入事件，以避免无意义的调和操作。监听器API客户端支持通过每秒查询次数和突发值配置速率限制，并可使用max-concurrent-reconciles标志设置全局或单个控制器的调和并发数。运维团队因此能够在吞吐量与Kubernetes、GitHub API压力之间进行更细致的平衡，但提高并发并不一定带来更好结果，仍需结合工作负载和集群容量验证。

生命周期管理同样得到调整。补丁版本升级可以直接就地更新资源，自动扩展运行器集与临时运行器集保持一对一映射，从而降低升级中断风险。terminationGracePeriodSeconds现已支持配置，并与控制器管理器的优雅关机超时保持一致，便于控制重启或升级期间的退出行为。

当GitHub Actions服务端不再保留对应的运行器规模集时，ARC能够重新注册该规模集，帮助修复本地Kubernetes状态与GitHub扩展集状态不一致的问题。临时运行器Pod成功退出后，控制器还会跳过服务端移除运行器时的额外检查，加快临时运行器清理速度。

对于共享CI基础设施的团队，将状态聚合纳入指标体系尤其重要。大型集群会在任务排队、运行器配置、工作负载执行和临时环境清理期间持续产生生命周期事件，减少状态更新可缓解Kubernetes API压力，而指标则更适合监控控制器及运行器的整体行为。

动态管理CI执行资源已成为趋势。CircleCI的Machine Runner Orchestrator主要扩展基于机器的运行器，并覆盖CPU、GPU和ARM等资源；ARC则直接整合Kubernetes，通常管理临时GitHub Actions运行器。对已采用GitHub Actions和Kubernetes的组织而言，ARC提供了原生容量管理方式，但平台团队仍需负责控制器、集群资源以及调度、API限制和工作流需求之间的协同。0.15.0虽是增量版本，却说明当CI服务于大量代码库和团队时，控制器效率与生命周期可靠性会直接影响交付流程。