<style>
.arc26-hero{padding:clamp(25px,5vw,46px);border-radius:23px;color:#fff;background:linear-gradient(125deg,#17233d,#315979 57%,#317a79)}.arc26-hero h2{color:#fff;margin:.25em 0}.arc26-kicker{color:#b8eff0;font-size:.8rem;font-weight:800;letter-spacing:.12em}.arc26-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px;margin:22px 0}.arc26-card{padding:18px;border:1px solid #c9dce3;border-radius:15px;background:#f1f8fa}.arc26-card strong{display:block;color:#216d7f;font-size:1.12rem;margin-bottom:7px}.arc26-flow{display:grid;grid-template-columns:repeat(4,minmax(0,1fr));gap:9px;margin:20px 0}.arc26-step{padding:15px;border:1px solid #bfd6db;border-radius:13px;background:#eaf5f6}.arc26-step b{display:block;color:#1c697a}.arc26-table{overflow-x:auto;margin:20px 0}.arc26-table table{width:100%;min-width:650px;border-collapse:collapse}.arc26-table th,.arc26-table td{padding:11px;border:1px solid #c6d9de;text-align:left;vertical-align:top}.arc26-table th{background:#e6f2f4}.arc26-note{padding:17px 20px;border-left:5px solid #d59645;border-radius:10px;background:#fff7e9;margin:20px 0}@media(max-width:760px){.arc26-grid,.arc26-flow{grid-template-columns:1fr 1fr}}@media(max-width:520px){.arc26-grid,.arc26-flow{grid-template-columns:1fr}}
</style>
GITHUB ACTIONS / KUBERNETES
ランナー群が大きいほど、更新の設計が効く
Actions Runner Controller 0.15.0は、Kubernetes上で動く自前ランナーの安定性と監視性を改善。ただし「内部リソースの更新」と「ARC本体のアップグレード」は分けて考える必要があります。
3行で要約
- GitHubは2026年10月1日、Actions Runner Controller（ARC）0.15.0の改善点を発表した。リリースも同日で、ランナー群の運用負荷が主題だ。[1][2]
- パッチ版での内部リソースのインプレース更新、Kubernetes APIへの書き込み削減、終了処理と監視指標の改善が含まれる。性能改善の具体的な数値は公表されていない。[1]
- ARC自体をHelmだけでそのまま更新できるわけではない。公式手順はスケールセットの削除・クリーンアップ、ARCの削除、必要に応じたCRDの削除と再導入を求める。[3]
背景：ARCは何を動かしているのか
ARCはGitHub Actionsのセルフホスト型ランナーをKubernetes上で管理する仕組みだ。ジョブの需要に合わせてランナーを増減させる「ランナースケールセット」を扱う。ランナーはジョブを実行するワーカーで、コントローラーはその作成・削除を調整する。[3][4]
規模が大きくなると、単にランナーを増やすだけでなく、Kubernetes APIの更新量、コントローラーの終了時間、状態の観測、古いランナーの後片付けが運用品質を左右する。今回のリリースはその部分を重点的に改善している。[1]
更新の安定性パッチ版で関連リソースをインプレース更新し、スケールセット間の混乱を抑える。
APIの負荷全体更新からパッチ要求へ移し、状態更新の一部をメトリクスへ移す。
運用の調整終了猶予、リスナーのQPS・burst、調整処理の同時実行数を設定可能にする。
何が新しいのか：変更点を運用課題で読む
公式発表を運用観点で整理| 変更 | 公式に示された内容 | 現場で確認したいこと |
|---|
| 内部リソースの更新 | パッチ版の更新でAutoscalingRunnerSetとEphemeralRunnerSetの対応を保ちながら、リソースをその場で更新する。 | 更新前後で待機ジョブ、実行中ジョブ、ランナーPod数がどう変わるか。 |
| Kubernetes API | 全体更新ではなくパッチ要求を利用。両セットのランナー状態の集約はメトリクスに移る。 | APIサーバーへの書き込み、監視ダッシュボードの参照先に変更が必要か。 |
| 復旧と終了 | GitHub Actions側から消えたスケールセットを再登録。終了猶予とgraceful shutdownの整合を改善。 | 通信断後の再登録、コントローラー再起動時のジョブへの影響。 |
| 大規模運用 | リスナーのKubernetesクライアントQPS・burst、コントローラーの同時調整数を設定可能にする。 | 設定を上げる前にAPI制限やエラー率を計測できるか。 |
ここでいう「インプレース」はARCが管理するリソースの更新方法を指す。ARC本体のバージョンアップ方法を変更した、という意味ではない。停止時間が必ずゼロになるとの保証でもない。[1][3]
技術的なポイント：状態の持ち方が変わる
GitHubはEphemeralRunnerSetとAutoscalingRunnerSetのランナー状態の集約を、オブジェクトのstatus欄からメトリクスへ移したと説明する。これはstatusへのパッチ要求を減らす方向の変更だ。旧status欄に依存する独自ダッシュボードやスクリプトがある場合は、アップデート前に参照箇所を棚卸ししたい。[1][2]
また、コントローラーはKubernetesオブジェクト全体のUpdateよりPatchを使うようになり、イベントのフィルタリングで不要な再調整を減らす。いずれもGitHubによる設計上の改善説明であり、自社クラスタで何％速くなるかを示すベンチマークではない。[1][2]
開発者・企業への影響
小規模なランナー群では体感差が小さいかもしれない。一方、多数のスケールセットを持ち、更新時のキュー滞留やAPIサーバー負荷に悩むチームには検証する価値がある。これは公式の変更内容からの編集上の推論であり、効果はクラスタ構成とジョブ量に依存する。
もう一つの影響は監視だ。旧status欄だけを見ていた運用は、新しいメトリクスやコントローラー・リスナー・ランナーのログ収集と合わせて見直す必要がある。GitHubもこれらのログを収集・保持する仕組みを推奨している。[3]
実践例：本番更新前の4段階
1 現状を記録Chart版、CRD、セット数、ジョブ待ち時間、ログと監視を控える。
2 検証環境で試す本番に近い負荷でジョブ実行・Pod終了・復旧を確認する。
3 公式手順で更新セット削除とクリーンアップを待ち、ARCを再導入する。
4 比較して戻す待ち時間、失敗率、API負荷を比較。問題時の復旧手順を実行する。
具体的には、まずhelm list -AでARC関連のリリースを、kubectl get autoscalingrunnersets,ephemeralrunnersets -Aで対象リソースを確認する。コマンドは調査例であり、実際のリソース名・権限・環境に合わせて確認すること。更新作業では、公式ガイドの順序に従い、全gha-runner-scale-setのアンインストール、リソースのクリーンアップ待ち、ARCのアンインストールを行う。旧版と新版でCRDが変わる場合のみ、actions.github.com APIグループのCRD削除を検討し、その後再導入する。[3]
運用上の注意：CRDはKubernetesの独自リソース定義で、削除は関連リソースに影響し得る。手順を一般化した一括削除コマンドは使わず、対象、差分、バックアップ、切り戻し方法を先に確認する。GitHubは高可用性構成による停止時間の抑制と、本番相当の検証環境でのテストを案内している。[3]
リスクと限界
- ダウンタイムの可能性：内部更新の改善があっても、ARC本体の公式アップグレード手順には削除と再導入が含まれる。メンテナンス時間と代替ランナーを計画する。[3]
- 監視の互換性：status欄を直接読む独自ツールは、新しいメトリクスとの整合を確認する。メトリクスの提供設定やラベルも現行チャートで検証する。[1][2]
- セキュリティ：GitHub Actionsのワークフローは任意コードを実行できる。GitHubは本番ワークロードとの分離、コントローラーとランナーの別namespace、認証情報をSecretで扱うことを推奨する。[3]
- 数値の限界：公式発表に速度・API呼び出し削減率・障害率の比較値はない。改善幅を一律の数字で示すことはできない。[1]
今後注目すべき点
大規模クラスタでの実測値、監視設定の移行事例、CRDを含むアップグレードの簡素化が注目点だ。まずは自社のジョブ待ち時間とAPI負荷を基準値として記録し、0.15.0導入後に同条件で比較するのが現実的だ。
最終確認日：2026年10月6日（日本時間）。GitHub Changelogの掲載日とGitHub Releasesの公開日は、ともに2026年10月1日。[1][2]
参照元
- GitHub Changelog：Actions Runner Controller release 0.15.0
- GitHub Releases：gha-runner-scale-set-0.15.0
- GitHub Docs：Deploying runner scale sets with Actions Runner Controller（Upgrading ARCを含む）
- GitHub Docs：Get started with Actions Runner Controller