[{"data":1,"prerenderedAt":376},["ShallowReactive",2],{"blog-ja-k3s-vs-kubernetes-cicd-build-runner-latency-cost":3,"blog-related-ja-k3s-vs-kubernetes-cicd-build-runner-latency-cost":327,"blog-ja-k3s-vs-kubernetes-cicd-build-runner-latency-cost-alt":316},{"id":4,"title":5,"author":6,"body":7,"date":310,"description":311,"extension":312,"image":313,"locale":314,"meta":315,"navigation":316,"path":317,"seo":318,"stem":319,"tags":320,"__hash__":326},"blog\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cicd-build-runner-latency-cost.md","CI\u002FCDのビルドランナー基盤、K3sか標準Kubernetesか。ジョブ起動レイテンシとコストで決める選定基準","Kubo Team",{"type":8,"value":9,"toc":296},"minimark",[10,15,23,26,29,40,44,50,64,81,89,94,110,114,120,123,131,134,138,144,152,169,172,176,182,185,209,212,216,222,242,245,254,258,261,282],[11,12,14],"h2",{"id":13},"cicdのビルドランナーは常設クラスタとは別物として考える","CI\u002FCDのビルドランナーは「常設クラスタ」とは別物として考える",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cicd-build-runner-latency-cost\u002Fsection01.webp",[16,24,25],{},"K3s vs Kubernetesという選定基準は、本番常設クラスタの文脈で語られることがほとんどです。しかし、CI\u002FCDのビルドランナー基盤は評価軸がまったく違います。アプリケーションPodが数週間〜数ヶ月起動し続ける常設クラスタと違い、CI\u002FCDのジョブPodは数十秒〜数分で起動し、ビルドが終われば即座に破棄されます。",[16,27,28],{},"この「頻繁な起動・破棄」という特性を前提にすると、K3sか標準Kubernetesかという問いは、本番運用の選定基準とは別のロジックで答えが決まります。本記事では、ジョブ起動レイテンシとコスト構造という2つの軸から、CI\u002FCDランナー基盤としてのK3s vs Kubernetesを具体的に比較します。",[16,30,31,32,39],{},"GitLab CIのKubernetes executorは、ジョブごとにPodを生成し、準備(Pod生成)→前処理(クローン・キャッシュ復元)→ビルド実行→後処理(キャッシュ作成・アーティファクトアップロード)という4段階でビルドを進めます（",[33,34,38],"a",{"href":35,"rel":36},"https:\u002F\u002Fdocs.gitlab.com\u002Frunner\u002Fexecutors\u002Fkubernetes\u002F",[37],"nofollow","GitLab公式ドキュメント","）。このサイクルがジョブの数だけ繰り返されるため、Pod起動のオーバーヘッドが積み重なりやすい構造になっています。",[11,41,43],{"id":42},"リソースフットプリントの差が同時に捌けるジョブ数に直結する","リソースフットプリントの差が「同時に捌けるジョブ数」に直結する",[16,45,46],{},[19,47],{"alt":48,"src":49},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cicd-build-runner-latency-cost\u002Fsection02.webp",[16,51,52,53,57,58,63],{},"K3sとフルKubernetesの最も明確な違いはリソースフットプリントです。K3s公式ドキュメントによれば、サーバーノード（コントロールプレーン）は2コア\u002F2GB、エージェント（ワーカー）は",[54,55,56],"strong",{},"1コア\u002F512MB","が最小要件とされています（",[33,59,62],{"href":60,"rel":61},"https:\u002F\u002Fdocs.k3s.io\u002Finstallation\u002Frequirements",[37],"K3s公式ドキュメント","）。",[16,65,66,67,70,71,76,77,80],{},"一方、kubeadmでフルKubernetesクラスタを構築する場合、公式ドキュメントは各マシンに",[54,68,69],{},"2GB以上のRAM","を推奨しており、「これ以下だとアプリケーション用のリソースがほとんど残らない」と明記しています（",[33,72,75],{"href":73,"rel":74},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fsetup\u002Fproduction-environment\u002Ftools\u002Fkubeadm\u002Finstall-kubeadm\u002F",[37],"Kubernetes公式ドキュメント","）。つまりワーカーノードだけを見ても、K3sエージェントの512MBに対し標準K8sワーカーは2GB以上と、",[54,78,79],{},"4倍の開き","があります。",[16,82,83,84,63],{},"この差は、CI\u002FCDランナー基盤において「同じノードプールで何並列のジョブを同時に捌けるか」に直結します。ビルドジョブ自体が使うメモリは変わらなくても、Kubernetesの制御コンポーネントが消費する分だけ、1ノードに詰め込めるジョブPodの数が変わってくるためです。K3sはシングルバイナリで100MB未満に収まっており、インストールも1分未満で完了するため、k3d（DockerコンテナとしてのK3s）としてブランチごとに使い捨てクラスタを生成・破棄するCI用途にも使われています。同様に軽量Kubernetesディストリビューションとして並べて語られることの多いMicroK8sも、実用的なワークロードには4GB RAM程度を推奨しており、K3sのエージェント512MBという数値の軽さが相対的に際立ちます（",[33,85,88],{"href":86,"rel":87},"https:\u002F\u002Ftech-insider.org\u002Fk3s-vs-kubernetes-vs-microk8s-2026\u002F",[37],"K3s vs Kubernetes vs MicroK8sの比較データ",[90,91,93],"h3",{"id":92},"k3sの軽さが効く典型シーン","K3sの軽さが効く典型シーン",[95,96,97,104],"ul",{},[98,99,100,103],"li",{},[54,101,102],{},"Pull Request単位の統合テスト",": フィーチャーブランチごとに使い捨てクラスタを起動し、テスト後に破棄するパターン",[98,105,106,109],{},[54,107,108],{},"大量の並列ジョブを1つのノードプールで捌きたい",": 同じインスタンスサイズでより多くのジョブPodを同時実行したい場合",[11,111,113],{"id":112},"ジョブ起動レイテンシの正体-cluster-autoscalerのコールドスタート問題","ジョブ起動レイテンシの正体 — Cluster Autoscalerのコールドスタート問題",[16,115,116],{},[19,117],{"alt":118,"src":119},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cicd-build-runner-latency-cost\u002Fsection03.webp",[16,121,122],{},"CI\u002FCDのビルドランナーで最も体感しやすい問題が「ジョブがキューに積まれてから実際に動き出すまでの待ち時間」です。オートスケーリングのノードプールでジョブを実行する場合、ノードプロビジョニング自体に30秒〜2分かかり、さらに新規ノードでのコンテナイメージのフルプルや、ジョブPodでのリポジトリのフルクローンが重なると、体感の遅延はさらに伸びます。",[16,124,125,126,63],{},"この問題への実務的な対策が「pause pods（ポーズポッド）」パターンです。低優先度のダミーPodを事前にデプロイしてノードの空き容量を温めておき、実際のジョブPodが投入された瞬間にpause podをプリエンプト（追い出し）させて即座にスケジューリングする仕組みです。pause podのDeploymentが追い出された分を再生成しようとする際にCluster Autoscalerがトリガーされ、次のジョブに備えた新規ノードが追加されます。同様の目的で、スパイクを吸収するための「オーバープロビジョニングバッファ」も使われており、GitLab Runner自体のIssueトラッカーでもオートスケーリングノードプール上でのジョブ安定性が継続的に議論されています（",[33,127,130],{"href":128,"rel":129},"https:\u002F\u002Fgitlab.com\u002Fgitlab-org\u002Fgitlab-runner\u002F-\u002Fissues\u002F25463",[37],"GitLab RunnerのIssueトラッカー",[16,132,133],{},"K3sはコントロールプレーンの起動自体が軽量なため、使い捨てクラスタをCI上でそのまま起動するパターン（k3d等）ではノードプロビジョニングという概念自体が不要になり、この種のコールドスタート問題を構造的に回避できる場合があります。一方、常設のマネージドクラスタにノードプールを足し引きする運用では、K3sでも標準Kubernetesでも「ノードが増えるまでの待ち時間」自体は避けられず、pause podsのような緩和策が必要になる点は共通です。",[11,135,137],{"id":136},"github-actions-arcgitlab-runnerのコスト構造で見るk3s化の損益分岐点","GitHub Actions ARC・GitLab Runnerのコスト構造で見るK3s化の損益分岐点",[16,139,140],{},[19,141],{"alt":142,"src":143},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cicd-build-runner-latency-cost\u002Fsection04.webp",[16,145,146,147,63],{},"GitHub Actionsのセルフホストランナーを管理するActions Runner Controller（ARC）は、Kubernetes Operatorとしてランナーのスケーリングを担います。ワークフローからジョブが届くとRunner ScaleSet ListenerがKubernetes API経由でEphemeral RunnerSetをパッチし、必要数のランナーPodを生成します。ジョブが完了するとEphemeralRunner Controllerがランナーを削除する、完全にエフェメラルな設計です（",[33,148,151],{"href":149,"rel":150},"https:\u002F\u002Fdocs.github.com\u002Fen\u002Factions\u002Fconcepts\u002Frunners\u002Factions-runner-controller",[37],"GitHub公式ドキュメント",[16,153,154,155,63,160,164,165,168],{},"コスト面では、GitHub-hostedランナーは月間10万分の利用で約$600、20万分で約$1,200かかるとされる一方、スポットインスタンス＋自社Kubernetes基盤を使えば同等のワークロードを数百ドル\u002F月まで圧縮できるケースがあると報告されています（",[33,156,159],{"href":157,"rel":158},"https:\u002F\u002Fcloudrps.com\u002Fblog\u002Fgithub-actions-self-hosted-runners-arc-kubernetes\u002F",[37],"ARCのコスト分析記事",[161,162,163],"code",{},"minRunners: 0","の設定で完全スケールゼロにすれば待機コストはゼロになりますが、その分Pod起動からイメージプルまで30〜60秒のコールドスタートが発生するため、開発者の即時フィードバックを重視するなら",[161,166,167],{},"minRunners: 1","で一部を温存する運用が推奨されています。",[16,170,171],{},"ただし同記事は「開発者10名以下の小規模チームでは、運用保守の人件費がコスト削減分を上回る可能性がある」とも指摘しており、K3s化・自社ホスト化が常に正解とは限らない点には注意が必要です。この損益分岐点の見極めこそが、CI\u002FCDランナー基盤を自前のK3s\u002FKubernetesに移すかどうかの実質的な判断基準になります。",[11,173,175],{"id":174},"それでも標準kubernetesを選ぶべきケース","それでも標準Kubernetesを選ぶべきケース",[16,177,178],{},[19,179],{"alt":180,"src":181},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cicd-build-runner-latency-cost\u002Fsection05.webp",[16,183,184],{},"ここまでK3sの優位性を中心に見てきましたが、CI\u002FCDランナー基盤でも標準Kubernetesを選ぶべきケースは存在します。",[95,186,187,193,203],{},[98,188,189,192],{},[54,190,191],{},"強いマルチテナント分離が必要な場合",": 複数チーム・複数顧客のジョブを同一クラスタで厳格に分離する必要がある場合、標準Kubernetesのフル機能なRBAC・NetworkPolicy実装や、エコシステムが成熟したマルチテナンシーツールの選択肢の広さが効いてきます。",[98,194,195,198,199,202],{},[54,196,197],{},"数千ノード規模の並列度が必要な場合",": K3sは数百〜1,800エージェント程度までのスケールを想定したサイジングガイドを公開していますが（",[33,200,62],{"href":60,"rel":201},[37],"）、それを超える超大規模なビルドファーム（数千ノード単位の並列ジョブ実行）では、実績の厚い標準Kubernetesのスケーラビリティが安心材料になります。",[98,204,205,208],{},[54,206,207],{},"既存のEKS\u002FAKS資産とランナーを統合運用したい場合",": 社内に既存の標準Kubernetesクラスタ・監視基盤・IAM連携がある場合、ランナーだけ別ディストリビューションにすることでかえって運用が複雑化することがあります。",[16,210,211],{},"つまり「エフェメラルで頻繁に起動・破棄される」という特性だけを見ればK3sが有利ですが、組織のガバナンス要件や既存資産との整合性次第では標準Kubernetesが合理的な選択になる、という中立的な視点を持つことが重要です。",[11,213,215],{"id":214},"実装の指針-キャッシュとオートスケーリングで最大の効果を出す","実装の指針 — キャッシュとオートスケーリングで最大の効果を出す",[16,217,218],{},[19,219],{"alt":220,"src":221},"section06","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cicd-build-runner-latency-cost\u002Fsection06.webp",[16,223,224,225,228,229,232,233,236,237,63],{},"K3s・標準Kubernetesのどちらを選ぶ場合でも、ランナー基盤の実運用で効果が大きいのがキャッシュとオートスケーリングの最適化です。あるチケット販売プラットフォーム企業の事例では、S3\u002FECRを使った分散ビルドキャッシュ（30日の有効期限ポリシー）を導入し、マルチアーキテクチャビルドでキャッシュが交互に無効化される問題に対しては",[161,226,227],{},"docker buildx build","の呼び出しを分離してから",[161,230,231],{},"docker manifest","で統合する手法を採用した結果、",[54,234,235],{},"ビルドが最大10倍高速化","したと報告されています（",[33,238,241],{"href":239,"rel":240},"https:\u002F\u002Fchairnerd.seatgeek.com\u002Fci-runner-optimizations\u002F",[37],"SeatGeekのエンジニアリングブログ",[16,243,244],{},"オートスケーリングについても、「保留中+実行中のジョブ数 ÷ 利用可能なジョブスロット総数」という飽和度指標を使い、70%を超えたら30秒ごとに容量を倍増させ、スケールダウンは60秒ごとに最大30%までに抑える、という非対称な制御によって、ジョブキュー時間を平均16秒から2秒へ、p98では3分超から4秒未満へ短縮し、ジョブあたりコストを40%削減したとされています。これらの施策はディストリビューションに依存しないため、K3sでも標準Kubernetesでも同様に適用できる改善策です。",[16,246,247,248,253],{},"CI\u002FCD基盤をゼロから構築・運用する体力がないチームにとっては、こうしたキャッシュ・オートスケーリングの細かなチューニングそのものが負担になりがちです。",[33,249,252],{"href":250,"rel":251},"https:\u002F\u002Fkubo.hexabase.io\u002F",[37],"Kubo","はK3sベースのマネージドKubernetesとして、GitOps対応（ArgoCD\u002FFlux統合）を標準搭載しており、こうした運用の作り込みを自分たちで一から設計しなくても、ランナー基盤の構築をすぐに始められる点が強みです。",[11,255,257],{"id":256},"まとめ-cicdランナー基盤の選定フロー","まとめ — CI\u002FCDランナー基盤の選定フロー",[16,259,260],{},"CI\u002FCDのビルドランナー基盤としてK3sと標準Kubernetesのどちらを選ぶべきか、本記事の内容を1つの判断フローにまとめます。",[262,263,264,270,276],"ol",{},[98,265,266,269],{},[54,267,268],{},"ジョブが頻繁に起動・破棄される（エフェメラル）なら、まずK3sを第一候補にする",": ワーカーノードのリソースフットプリントが4倍軽く、同じノードプールでより多くのジョブを並列実行できる",[98,271,272,275],{},[54,273,274],{},"強いマルチテナント分離や数千ノード規模の並列度が必要なら、標準Kubernetesを検討する",": ガバナンス要件や既存資産との統合を優先すべき局面もある",[98,277,278,281],{},[54,279,280],{},"どちらを選んでもジョブ起動レイテンシ対策(pause pods等)とキャッシュ・オートスケーリングのチューニングは避けて通れない",": ここが運用負荷の大半を占める",[16,283,284,285,289,290,295],{},"EKS\u002FAKSでクラスタを運用しながら「ランナー基盤だけ月額¥82,700(EKS)や¥85,710(AKS)を払い続けている」という状態であれば、",[33,286,288],{"href":250,"rel":287},[37],"Kubo Cloud","のようなK3sベースのマネージドサービス（同等構成で月額¥48,000〜）に切り出すことで、コストと運用負荷の両方を圧縮できる余地があります。まずはCI\u002FCDランナー専用の小規模クラスタから試してみて、ジョブ起動レイテンシとコストの両面で体感の差を確認してみることをおすすめします。",[33,291,294],{"href":292,"rel":293},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[37],"お問い合わせ","からKuboの構成相談も可能です。",{"title":297,"searchDepth":298,"depth":298,"links":299},"",2,[300,301,305,306,307,308,309],{"id":13,"depth":298,"text":14},{"id":42,"depth":298,"text":43,"children":302},[303],{"id":92,"depth":304,"text":93},3,{"id":112,"depth":298,"text":113},{"id":136,"depth":298,"text":137},{"id":174,"depth":298,"text":175},{"id":214,"depth":298,"text":215},{"id":256,"depth":298,"text":257},"2026-10-01","CI\u002FCDのビルドランナー基盤はK3sか標準Kubernetesか。ジョブ起動レイテンシ、Cluster Autoscalerのコールドスタート、GitLab Runner\u002FGitHub Actions ARCのコスト構造を比較し、最適な選定基準を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cicd-build-runner-latency-cost\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cicd-build-runner-latency-cost",{"title":5,"description":311},"blog\u002Fja\u002Fk3s-vs-kubernetes-cicd-build-runner-latency-cost",[321,322,323,324,325],"k3s","kubernetes","ci-cd","gitlab-runner","github-actions","73OTu8VJAfyrxDFKS4bg_mHOmoTjnl_t7vuLm_YAFp8",[328,337,345,352,360,368],{"path":329,"title":330,"description":331,"date":332,"tags":333},"\u002Fblog\u002Fja\u002Fcicd-pipeline-devsecops-gate-design-four-layers","そのCI\u002FCDパイプライン、セキュリティチェックをどこに置くか決めずに継ぎ足していないか。DevSecOpsゲート設計の4層モデル","SASTもDASTもコンテナスキャンも導入した。それでも本番で事故は起きる。CI\u002FCDパイプラインのセキュリティを『4つの層』で設計し直すDevSecOpsゲート設計の考え方を、K3s\u002FKubernetes運用の観点から解説する。","2026-08-28",[321,322,323,334,335,336],"devsecops","admission-control","gitops",{"path":338,"title":339,"description":340,"date":341,"tags":342},"\u002Fblog\u002Fja\u002Fgitlab-auto-devops-k3s-admission-controller-gate","GitLab Auto DevOpsの『とりあえず動くCI』が、本番K3sクラスタへの一番近い脅威になる理由","GitLab Auto DevOpsは有効化するだけでSAST\u002FDASTが自動的に動く。しかしスキャンが『動いている』ことと、脆弱性を含んだイメージが本番K3sクラスタに届かないことはまったく別の話だ。CI\u002FCDとクラスタの間に監査ゲートを作る設計を解説する。","2026-08-17",[321,322,343,323,334,344],"gitlab","admission-controller",{"path":346,"title":347,"description":348,"date":349,"tags":350},"\u002Fblog\u002Fja\u002Fkubernetes-image-signing-sigstore-supply-chain","イメージタグは誰でも書き換えられる。Kubernetesのイメージ署名にSigstoreで『来歴』を刻むという発想","コンテナイメージ署名の仕組みを解説。イメージタグは誰でも書き換え可能で、CI\u002FCDのテストを通過した保証にはならない。SigstoreとKyvernoを組み合わせ、Kubernetes\u002FK3s上で未署名イメージの起動を拒否する防御層を構築する方法を、GitOps運用との統合も含めて紹介する。","2026-08-06",[321,322,323,336,351],"security",{"path":353,"title":354,"description":355,"date":356,"tags":357},"\u002Fblog\u002Fja\u002Fqa-to-devops-kubernetes-career-transition","QAエンジニアの『バグを壊す視点』はKubernetes運用に転用できる。テスト自動化スキルからDevOpsキャリアへの最短ルート","QAエンジニアが持つ品質ゲート思考とテスト自動化スキルは、実はKubernetes運用に直結するDevOps適性だ。半年で転身するための現実的なロードマップと、学習の最大の壁を越える方法を解説する。","2026-07-19",[322,321,358,323,359],"devops","career",{"path":361,"title":362,"description":363,"date":364,"tags":365},"\u002Fblog\u002Fja\u002Fcanary-release-kubernetes-auto-rollback-gitops","全員が同じCI\u002FCDにたどり着けない理由。カナリアリリース×自動ロールバックで作る『壊れても安全』なKubernetesデプロイ設計","本番障害の多くは「一気にデプロイする」ことが原因で起きる。カナリアリリース・自動ロールバック・監視をKubernetes上でどう設計するか、Argo RolloutsとGitOpsを軸に、中小チームでも運用し続けられる実践手順を具体的に解説する。","2026-07-15",[322,321,323,366,336,367],"canary-release","argo-rollouts",{"path":369,"title":370,"description":371,"date":372,"tags":373},"\u002Fblog\u002Fja\u002Fmlops-kubernetes-devops-ai-skills-2026","「DevOpsエンジニアは不要になる」は嘘だった。AI時代のKubernetes運用者が今すぐ身につけるべきMLOpsスキル5選","AIがインフラ構築を自動化する時代、DevOpsエンジニアは本当に不要なのか？実態は逆で、MLOps Kubernetesを扱える人材の需要が急増。2026年に求められる5つのスキルと具体的な習得法を解説。","2026-07-11",[322,374,358,321,323,375],"mlops","ai-infrastructure",1792592612830]