CI/CDのビルドランナーは「常設クラスタ」とは別物として考える
K3s vs Kubernetesという選定基準は、本番常設クラスタの文脈で語られることがほとんどです。しかし、CI/CDのビルドランナー基盤は評価軸がまったく違います。アプリケーションPodが数週間〜数ヶ月起動し続ける常設クラスタと違い、CI/CDのジョブPodは数十秒〜数分で起動し、ビルドが終われば即座に破棄されます。
この「頻繁な起動・破棄」という特性を前提にすると、K3sか標準Kubernetesかという問いは、本番運用の選定基準とは別のロジックで答えが決まります。本記事では、ジョブ起動レイテンシとコスト構造という2つの軸から、CI/CDランナー基盤としてのK3s vs Kubernetesを具体的に比較します。
GitLab CIのKubernetes executorは、ジョブごとにPodを生成し、準備(Pod生成)→前処理(クローン・キャッシュ復元)→ビルド実行→後処理(キャッシュ作成・アーティファクトアップロード)という4段階でビルドを進めます（GitLab公式ドキュメント）。このサイクルがジョブの数だけ繰り返されるため、Pod起動のオーバーヘッドが積み重なりやすい構造になっています。
リソースフットプリントの差が「同時に捌けるジョブ数」に直結する
K3sとフルKubernetesの最も明確な違いはリソースフットプリントです。K3s公式ドキュメントによれば、サーバーノード（コントロールプレーン）は2コア/2GB、エージェント（ワーカー）は1コア/512MBが最小要件とされています（K3s公式ドキュメント）。
一方、kubeadmでフルKubernetesクラスタを構築する場合、公式ドキュメントは各マシンに2GB以上のRAMを推奨しており、「これ以下だとアプリケーション用のリソースがほとんど残らない」と明記しています（Kubernetes公式ドキュメント）。つまりワーカーノードだけを見ても、K3sエージェントの512MBに対し標準K8sワーカーは2GB以上と、4倍の開きがあります。
この差は、CI/CDランナー基盤において「同じノードプールで何並列のジョブを同時に捌けるか」に直結します。ビルドジョブ自体が使うメモリは変わらなくても、Kubernetesの制御コンポーネントが消費する分だけ、1ノードに詰め込めるジョブPodの数が変わってくるためです。K3sはシングルバイナリで100MB未満に収まっており、インストールも1分未満で完了するため、k3d（DockerコンテナとしてのK3s）としてブランチごとに使い捨てクラスタを生成・破棄するCI用途にも使われています。同様に軽量Kubernetesディストリビューションとして並べて語られることの多いMicroK8sも、実用的なワークロードには4GB RAM程度を推奨しており、K3sのエージェント512MBという数値の軽さが相対的に際立ちます（K3s vs Kubernetes vs MicroK8sの比較データ）。
K3sの軽さが効く典型シーン
- Pull Request単位の統合テスト: フィーチャーブランチごとに使い捨てクラスタを起動し、テスト後に破棄するパターン
- 大量の並列ジョブを1つのノードプールで捌きたい: 同じインスタンスサイズでより多くのジョブPodを同時実行したい場合
ジョブ起動レイテンシの正体 — Cluster Autoscalerのコールドスタート問題
CI/CDのビルドランナーで最も体感しやすい問題が「ジョブがキューに積まれてから実際に動き出すまでの待ち時間」です。オートスケーリングのノードプールでジョブを実行する場合、ノードプロビジョニング自体に30秒〜2分かかり、さらに新規ノードでのコンテナイメージのフルプルや、ジョブPodでのリポジトリのフルクローンが重なると、体感の遅延はさらに伸びます。
この問題への実務的な対策が「pause pods（ポーズポッド）」パターンです。低優先度のダミーPodを事前にデプロイしてノードの空き容量を温めておき、実際のジョブPodが投入された瞬間にpause podをプリエンプト（追い出し）させて即座にスケジューリングする仕組みです。pause podのDeploymentが追い出された分を再生成しようとする際にCluster Autoscalerがトリガーされ、次のジョブに備えた新規ノードが追加されます。同様の目的で、スパイクを吸収するための「オーバープロビジョニングバッファ」も使われており、GitLab Runner自体のIssueトラッカーでもオートスケーリングノードプール上でのジョブ安定性が継続的に議論されています（GitLab RunnerのIssueトラッカー）。
K3sはコントロールプレーンの起動自体が軽量なため、使い捨てクラスタをCI上でそのまま起動するパターン（k3d等）ではノードプロビジョニングという概念自体が不要になり、この種のコールドスタート問題を構造的に回避できる場合があります。一方、常設のマネージドクラスタにノードプールを足し引きする運用では、K3sでも標準Kubernetesでも「ノードが増えるまでの待ち時間」自体は避けられず、pause podsのような緩和策が必要になる点は共通です。
GitHub Actions ARC・GitLab Runnerのコスト構造で見るK3s化の損益分岐点
GitHub Actionsのセルフホストランナーを管理するActions Runner Controller（ARC）は、Kubernetes Operatorとしてランナーのスケーリングを担います。ワークフローからジョブが届くとRunner ScaleSet ListenerがKubernetes API経由でEphemeral RunnerSetをパッチし、必要数のランナーPodを生成します。ジョブが完了するとEphemeralRunner Controllerがランナーを削除する、完全にエフェメラルな設計です（GitHub公式ドキュメント）。
コスト面では、GitHub-hostedランナーは月間10万分の利用で約$600、20万分で約$1,200かかるとされる一方、スポットインスタンス＋自社Kubernetes基盤を使えば同等のワークロードを数百ドル/月まで圧縮できるケースがあると報告されています（ARCのコスト分析記事）。minRunners: 0の設定で完全スケールゼロにすれば待機コストはゼロになりますが、その分Pod起動からイメージプルまで30〜60秒のコールドスタートが発生するため、開発者の即時フィードバックを重視するならminRunners: 1で一部を温存する運用が推奨されています。
ただし同記事は「開発者10名以下の小規模チームでは、運用保守の人件費がコスト削減分を上回る可能性がある」とも指摘しており、K3s化・自社ホスト化が常に正解とは限らない点には注意が必要です。この損益分岐点の見極めこそが、CI/CDランナー基盤を自前のK3s/Kubernetesに移すかどうかの実質的な判断基準になります。
それでも標準Kubernetesを選ぶべきケース
ここまでK3sの優位性を中心に見てきましたが、CI/CDランナー基盤でも標準Kubernetesを選ぶべきケースは存在します。
- 強いマルチテナント分離が必要な場合: 複数チーム・複数顧客のジョブを同一クラスタで厳格に分離する必要がある場合、標準Kubernetesのフル機能なRBAC・NetworkPolicy実装や、エコシステムが成熟したマルチテナンシーツールの選択肢の広さが効いてきます。
- 数千ノード規模の並列度が必要な場合: K3sは数百〜1,800エージェント程度までのスケールを想定したサイジングガイドを公開していますが（K3s公式ドキュメント）、それを超える超大規模なビルドファーム（数千ノード単位の並列ジョブ実行）では、実績の厚い標準Kubernetesのスケーラビリティが安心材料になります。
- 既存のEKS/AKS資産とランナーを統合運用したい場合: 社内に既存の標準Kubernetesクラスタ・監視基盤・IAM連携がある場合、ランナーだけ別ディストリビューションにすることでかえって運用が複雑化することがあります。
つまり「エフェメラルで頻繁に起動・破棄される」という特性だけを見ればK3sが有利ですが、組織のガバナンス要件や既存資産との整合性次第では標準Kubernetesが合理的な選択になる、という中立的な視点を持つことが重要です。
実装の指針 — キャッシュとオートスケーリングで最大の効果を出す
K3s・標準Kubernetesのどちらを選ぶ場合でも、ランナー基盤の実運用で効果が大きいのがキャッシュとオートスケーリングの最適化です。あるチケット販売プラットフォーム企業の事例では、S3/ECRを使った分散ビルドキャッシュ（30日の有効期限ポリシー）を導入し、マルチアーキテクチャビルドでキャッシュが交互に無効化される問題に対してはdocker buildx buildの呼び出しを分離してからdocker manifestで統合する手法を採用した結果、ビルドが最大10倍高速化したと報告されています（SeatGeekのエンジニアリングブログ）。
オートスケーリングについても、「保留中+実行中のジョブ数 ÷ 利用可能なジョブスロット総数」という飽和度指標を使い、70%を超えたら30秒ごとに容量を倍増させ、スケールダウンは60秒ごとに最大30%までに抑える、という非対称な制御によって、ジョブキュー時間を平均16秒から2秒へ、p98では3分超から4秒未満へ短縮し、ジョブあたりコストを40%削減したとされています。これらの施策はディストリビューションに依存しないため、K3sでも標準Kubernetesでも同様に適用できる改善策です。
CI/CD基盤をゼロから構築・運用する体力がないチームにとっては、こうしたキャッシュ・オートスケーリングの細かなチューニングそのものが負担になりがちです。KuboはK3sベースのマネージドKubernetesとして、GitOps対応（ArgoCD/Flux統合）を標準搭載しており、こうした運用の作り込みを自分たちで一から設計しなくても、ランナー基盤の構築をすぐに始められる点が強みです。
まとめ — CI/CDランナー基盤の選定フロー
CI/CDのビルドランナー基盤としてK3sと標準Kubernetesのどちらを選ぶべきか、本記事の内容を1つの判断フローにまとめます。
- ジョブが頻繁に起動・破棄される（エフェメラル）なら、まずK3sを第一候補にする: ワーカーノードのリソースフットプリントが4倍軽く、同じノードプールでより多くのジョブを並列実行できる
- 強いマルチテナント分離や数千ノード規模の並列度が必要なら、標準Kubernetesを検討する: ガバナンス要件や既存資産との統合を優先すべき局面もある
- どちらを選んでもジョブ起動レイテンシ対策(pause pods等)とキャッシュ・オートスケーリングのチューニングは避けて通れない: ここが運用負荷の大半を占める
EKS/AKSでクラスタを運用しながら「ランナー基盤だけ月額¥82,700(EKS)や¥85,710(AKS)を払い続けている」という状態であれば、Kubo CloudのようなK3sベースのマネージドサービス（同等構成で月額¥48,000〜）に切り出すことで、コストと運用負荷の両方を圧縮できる余地があります。まずはCI/CDランナー専用の小規模クラスタから試してみて、ジョブ起動レイテンシとコストの両面で体感の差を確認してみることをおすすめします。お問い合わせからKuboの構成相談も可能です。