Skip to content
Latchkey

Actions Runner Controller (ARC) vs Managed Runners

ARC は自社の Kubernetes クラスタ上でセルフホストランナーを実行します。強力ですが、クラスタ、スケーリング、アップグレードはすべて自分で運用します。

Actions Runner Controller (ARC) は、オートスケーリング付きで Kubernetes 上に Pod としてセルフホストランナーを実行する、GitHub 提供のツールです。すでに K8s を運用しているなら最適ですが、それでもセルフホスティングです。マネージドランナーとの比較を見ていきます。

ARC (K8s 上のセルフホスト)Managed (Latchkey)
コンピュートコストクラスタの実コスト低い (hosted 比 約70%減)
Kubernetes が必要はい (自分で運用)いいえ
スケーリングオートスケーリングを自分で設定ウォームプール (標準搭載)
パッチ / アップグレードcontroller + node を自分で管理自動対応
不安定な失敗からの回復なし自己修復による自動リトライ
セットアップの手間高い (Helm, controller, スケーリング)label の入れ替え

ARC が適する場面

すでに Kubernetes を運用しており、クラスタと同じ場所にランナーを配置したく、controller、node プール、オートスケーリングを運用できるプラットフォームチームがあるなら、ARC は有力な選択肢です。

運用の現実

ARC はやはりセルフホスティングです。controller のアップグレード、ランナーイメージの保守、スケーリングのチューニング、基盤 node の信頼性は自分で担います。これは実際に発生し続けるプラットフォーム作業です。

マネージドという選択肢

Latchkey のようなマネージドランナーは、運用すべき Kubernetes なしに同等のコンピュート削減 (GitHub-hosted 比 約70%減) を実現し、即時ピックアップのためのウォームプールと、一時的な失敗を自動リトライする自己修復を備えます。

結論

Kubernetes のプラットフォームチームがあり、自社クラスタ内にランナーを置きたいなら ARC を使いましょう。K8s を運用せずにコスト削減を得たいなら、マネージドランナーの方が手間が少なく自己修復もあります。無料で始められます。

関連ガイド