背景
GitHub 已於 2026 年 10 月 1 日釋出 Actions Runner Controller（ARC）0.15.0，InfoQ 於 10 月 20 日由 Craig Risi 對此版本做了報導。ARC 是一個 Kubernetes operator（運維控制器），用途是依 GitHub Actions 工作流程的實際需求，自動建立與回收自託管（self-hosted）runner。所謂自託管 runner，是指企業不在 GitHub 提供的共享機器上執行工作，而是在自己的基礎設施中執行建置、測試與部署任務。這樣做的價值在於，組織可以完全掌控建置環境、網路存取權限、算力資源配置與工作負載隔離，卻又不必常備一整池閒置的 runner 待命。0.15.0 的改動集中在三個方向：降低控制器為了同步 runner 資源而產生的 Kubernetes API 請求、提升控制器在高負載下的吞吐量，以及讓升級與關閉過程更可預期，特別是針對管理大量 runner scale set（一組可依需求伸縮的 runner 實例集合）的環境。
核心內容
這個版本最主要的一項調整，是縮減控制器維持資源同步時的運作量。控制器的更新改用 Kubernetes patch 請求（局部更新）取代完整的 update 請求（整份覆寫），直接縮小每次 API 交換的資料量。與此同時，runner 狀態彙整被移到 metrics（指標）層面，涵蓋 EphemeralRunnerSet 與 AutoscalingRunnerSet 兩種資源，也就是說，單一 runner 的狀態變化不再逐一寫回 Kubernetes API，而是累積成指標供查詢。控制器也會過濾接收到的事件，避免觸發不必要的 reconciliation（對帳程序，即控制器反覆比對實際狀態與期望狀態並加以修正的循環）。此外，listener API 用戶端的速率上限可以透過 queries-per-second 與 burst 參數設定，而 reconciliation 的並行度可用 max-concurrent-reconciles 旗標做全域或逐控制器的配置，讓平台團隊自行決定控制器在負載下的行為。
生命週期管理同樣是本版重點。次版本（patch version）升級改為就地更新資源，維持 autoscaling runner set 與 ephemeral runner set（短暫存在、任務結束即銷毀的 runner 實例集合）之間的一對一對應，降低升級造成的干擾。控制器關閉行為也做了調整：terminationGracePeriodSeconds（終止前的寬限秒數，決定控制器收到停止訊號後還有多久可以收尾）現在可配置，並與 controller manager 的優雅關閉逾時時間對齊，操作者因此能更精確掌握重啟或升級時控制器如何退出。ARC 也具備重新註冊能力，當某個 runner scale set 在本地紀錄中的對應版本已不存在於 GitHub Actions 服務端時，控制器可以重新建立這組 scale set，藉此修復本地 Kubernetes 狀態與 GitHub 端 scale-set 狀態不一致的問題。最後，當 runner pod 正常結束時，ARC 會略過一道額外的伺服器端移除檢查，讓 ephemeral runner 被更快刪除。這些改動單獨來看都不大，但在 runner 環境持續被建立與銷毀的場景中，正是逐漸累積的營運細節。
技術脈絡與影響
把 runner 狀態彙整改成 metrics，對把 ARC 當成共享 CI 基礎設施來運作的團隊特別有意義。大型 runner 機群會不斷產生生命周期事件：工作進入佇列、runner 被配置、工作負載執行、短暫環境被移除，若每次都寫入 status patch，Kubernetes API 伺服器的壓力會持續累積；改用指標後，API 負擔減輕，同時也提供了更適合觀察控制器與 runner 整體行為的基礎。可配置的 reconciliation 並行度與 listener 速率上限，則讓運維者能在吞吐量與 API 壓力之間做微調。
不過這些設定並不是單純的效能開關。提高並行度會同步提高控制器與 Kubernetes、GitHub 服務互動的頻率，團隊應依自身的工作負載模式與叢集容量逐一驗證，而不是假設越高越好。ARC 也處於 CI 執行動態化管理的大趨勢之中：CircleCI 的 Machine Runner Orchestrator 同樣聚焦於機器型 runner 的伸縮，並支援 CPU、GPU、ARM 等不同資源類別；ARC 則是直接與 Kubernetes 整合來管理 GitHub Actions 的 runner scale set，通常搭配 ephemeral runner 環境。兩者面對的是同一個問題——讓執行能力與 CI 需求匹配——但平台整合方式與 runner 執行模型不同。對已經把 GitHub Actions 與 Kubernetes 標準化的組織，ARC 提供了原生途徑，讓 runner 容量與其他叢集資源一起管理；代價是平台團隊必須自行運維控制器、管理 Kubernetes 容量，並理解 runner 伸縮如何與叢集排程、API 限制及工作流程需求互相作用。
總體而言，0.15.0 是一個增量式版本，但它所強調的方向反映了一個重要的工程議題：當 CI 基礎設施開始服務眾多倉庫與團隊時，控制器效率與生命週期可靠性本身就成為交付品質的一環。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。