GitHub 发布 Actions Runner Controller 0.15.0，优化 Kubernetes 环境下 CI 运行器的可靠性与吞吐量

一句话结论

GitHub 发布 Actions Runner Controller 0.15.0，通过优化 API 交互和生命周期管理，显著提升大规模 Kubernetes 集群中自托管运行器的可靠性。

关键要点

• GitHub 于 2025 年 10 月 1 日发布 Actions Runner Controller (ARC) 0.15.0，专门针对在 Kubernetes 上运行自托管 GitHub Actions 运行器的场景进行优化，重点提升可靠性、可扩展性及可观测性。
• 该版本将控制器更新机制从完整的更新请求（full update requests）转变为 Kubernetes 补丁请求（patch requests），并迁移运行器状态聚合至 EphemeralRunnerSet 和 AutoscalingRunnerSet 指标，有效减少 Kubernetes API 的有效载荷大小及状态更新数量。
• 新增可配置的监听器 API 客户端速率限制（每秒查询次数和突发设置）以及 max-concurrent-reconciles 标志，允许团队全局或针对单个控制器配置调和并发数，以平衡吞吐量与 API 压力。
• 改进生命周期管理，支持补丁版本升级时原地更新资源，保持自动扩展运行器集与临时运行器集的一对一映射，并允许通过 terminationGracePeriodSeconds 配置控制器的优雅关机超时，使重启或升级过程中的退出行为更具可预测性。

背景与事实

GitHub 在 2025 年 10 月 1 日正式发布了 Actions Runner Controller (ARC) 的 0.15.0 版本。ARC 是一个 Kubernetes 操作符（Operator），其核心功能是根据工作流需求自动扩展自托管的 GitHub Actions 运行器。对于需要严格控制构建环境、网络访问、计算资源或工作负载隔离，但又不希望维护永久预配置运行器池的企业而言，ARC 允许它们在任务到达时动态创建运行器实例，并在任务完成后删除这些实例。

在 0.15.0 版本中，GitHub 团队重点解决了控制器在高负载场景下的效率问题。此前，控制器为了保持运行器资源同步，会发送大量的完整更新请求，这在高吞吐场景下会消耗大量 Kubernetes API 带宽。新版本引入了 Kubernetes 补丁请求机制，仅更新变更部分，显著减小了 API 有效载荷。同时，运行器状态的聚合逻辑被转移至 EphemeralRunnerSet 和 AutoscalingRunnerSet 的监控指标中，这意味着不需要频繁地向 Kubernetes API 发送状态更新，从而减轻了 API 服务器的压力。此外，控制器现在能够过滤传入的事件，避免触发不必要的对账操作（reconciliation），并支持通过配置每秒查询次数（QPS）和突发值来限制监听器 API 客户端的速率。

生命周期管理的改进也是本次更新的重点。在过去，执行补丁版本升级可能会导致运行器集的重建，造成服务中断。0.15.0 版本支持就地更新资源，确保了自动扩展运行器集（AutoscalingRunnerSet）与临时运行器集（EphemeralRunnerSet）之间的一对一映射关系在升级过程中得以保持。同时，控制器的关机行为得到了增强，terminationGracePeriodSeconds 变为可配置项，并与控制器管理器的优雅关机超时保持一致，这赋予了运维人员在重启或升级期间更精细的控制权。此外，ARC 还增加了一项自我修复机制：当对应的运行器规模集在 GitHub Actions 服务中消失但本地 Kubernetes 状态仍存在时，ARC 能够重新注册该运行器集，从而解决状态不一致的问题。最后，当临时运行器 Pod 成功退出时，ARC 会跳过服务器端在移除运行器时执行的额外检查，进一步加快了临时运行器的删除速度。

影响分析

对于使用 GitHub Actions 和 Kubernetes 作为标准 CI/CD 平台的团队而言，这一更新意味着基础设施运维的复杂度和稳定性将得到改善。分析认为，随着 CI 基础设施服务于越来越多的代码库和团队，控制器本身的效率成为了交付过程中的关键瓶颈。通过减少 API 调用和优化对账逻辑，平台团队可以在不增加硬件资源的情况下支撑更大的运行器集群。特别是对于将 ARC 作为共享 CI 基础设施运行的组织，将状态聚合纳入指标体系有助于更准确地监控集群行为，而非依赖于高频的 API 查询。然而，运维人员需要谨慎配置新增的并发和速率限制参数，因为提高并发数虽然能增加吞吐量，但也会增加控制器与 Kubernetes 及 GitHub 服务的交互频率，可能导致 API 压力骤增。因此，团队必须根据自身的负载模式和集群容量进行验证，而非盲目追求高并发。

适用边界

本结论主要适用于基于 Kubernetes 部署的 GitHub Actions 自托管运行器环境。对于不依赖于 Kubernetes 的传统虚拟机运行器，或者使用其他 CI 系统（如 CircleCI、Jenkins）的团队，ARC 的改进并不直接适用。此外，这些性能优化主要面向“大规模”场景，即管理大量运行器扩展集的环境；对于小型团队或低并发的运行器部署，API 请求减少带来的收益可能不够显著，甚至因配置复杂度的增加而显得得不偿失。

孤本观察

ARC 0.15.0 的更新揭示了动态 CI 基础设施在成熟过程中的一个典型特征：从单纯的“资源供给”转向“控制平面效率”。编辑器判断，随着 CircleCI 等竞争对手推出针对异构资源（如 GPU、ARM）的编排器，GitHub 通过优化 Kubernetes 控制器的内部机制来维持其在大规模临时资源管理上的优势，反映出行业竞争焦点已从单纯的算力弹性扩展到了运维可靠性与 API 成本控制。

来源：InfoQ 中文 AI