mozumasu 教室Kubernetes 解体新書

Kubernetes 解体新書Part 5 パブリッククラウドとの関係

Fargate はタスクをどこで動かしているのか

コンテナの実行基盤を任せる Fargate。EC2 との運用の違いと、その下で使われる軽量な VM を見ていきます。

  • L0 ブラウザだけ
  • 更新 2026年10月6日

コンテナを動かすために、サーバーを用意したり、OS を更新したりする仕事も任せたい。 AWS Fargate は、その実行基盤を AWS が管理するサービスです。 利用者はアプリの設定を渡しますが、実行先のホストへ SSH で入ることはできません。

この章では、自分で EC2 を管理する構成と比べ、Fargate で変わる運用や制約を見ます。 その下で使われる軽量な VM と、ほかのサービスや AI 向けの実行環境での活用にも触れます。

GOAL この章のゴール

  • EC2 と Fargate で、利用者に残る仕事の違いを説明できる
  • Fargate の実行環境と、使うときの制約が分かる
  • 軽量な VM が利用される場面を挙げられる

ECS で動かす場所を選ぶ

2 章目で、ECS をコントロールプレーンとして位置づけました。 タスクが実際に走るデータプレーンには 2 種類あり、ECS ではこの選び方を 起動タイプきどうタイプECS でタスクをどこで動かすかの選び方。利用者の EC2 で動かす EC2 起動タイプと、AWS 管理の VM で動かす Fargate 起動タイプがある (task definition では launch type と呼ぶ)。用語集で見る と呼びます。

ECS の 2 つの起動タイプ: EC2 と Fargate上に ECS コントロールプレーン。左下の EC2 起動タイプでは、あなたの EC2 に ecs-agent と Docker が居て複数のタスクが同居する。右下の Fargate 起動タイプでは、タスクごとに AWS 管理の VM (Firecracker の microVM) が用意され、ホストは見えない。ECS コントロールプレーン (AWS)スケジューラ / API / サービス管理task を置くtask を置く起動タイプ EC2container instance (あなたの EC2)10.0.1.10ecs-agentDockerOS / パッチtaskENI 10.0.1.23taskENI 10.0.1.24taskENI 10.0.1.25カーネルを共有。AMI と agent の更新はあなた起動タイプ FargateAWS 管理のホスト (見えない)VM (microVM)taskENI 10.0.2.31専用カーネルFargate agent+ containerdVM (microVM)taskENI 10.0.2.32専用カーネルCPU / メモリをtask 単位で指定どちらも同じコントロールプレーン、同じ task definition。違うのはデータプレーンだけ。
図 1コントロールプレーンも task definition も同じ。違うのは task を置く先が、利用者の EC2 か、AWS 管理の VM か。

EC2 起動タイプでは、タスクは利用者の EC2 で動きます。 その EC2 には ecs-agent と Docker が入っていて、ECS のスケジューラがそこに task を置きます。 スケールや自己復旧の単位も EC2 の流儀 (Auto Scaling Group、capacity provider) です。

Fargate 起動タイプでは、タスクごとに AWS が小さな VM を起動し、その中でコンテナが動きます (この VM の正体は後の節で説明します)。 利用者は task に必要な CPU とメモリを書くだけで、どのホストで動くかを意識しません。 ECS のドキュメントによると、各 task は専用の分離境界を持ち、カーネル、CPU、メモリ、ENI を他の task と共有しません。

ECS のドキュメントは、クラスタの容量として EC2、Fargate、そして AWS が利用者のアカウントの EC2 の調達、パッチ、スケールまで運用する Amazon ECS Managed Instances の 3 つを挙げ、Fargate は変動する負荷や始めたてのときに、EC2 は GPU や特殊なハードウェア、privileged 権限、カスタム AMI が要るときに向くとしています。 この章では、前の 2 つを比べます。

EC2 タイプで手元に残る仕事

EC2 起動タイプでも、「どのホストでどのコンテナを何個起動するか」は ECS が決めてくれます。 それでも、ホストそのものは利用者の手元に残ります。

EC2 起動タイプで、あなたの手元に残る仕事container instance の中のプロセス (ecs-agent、Docker、OS) それぞれについて、死んだときの復旧、バージョン更新、セキュリティパッチ、インスタンスタイプの選定とスケーリングが利用者の仕事として残ることを示す。container instance (EC2)あなたの管理EC2 インスタンスタイプ選定 / 台数 / ASGOS (Amazon Linux など)カーネル更新、セキュリティパッチDockerバージョン、死んだら task も巻き添えecs-agent更新、死んだら ECS との接続が切れるどれも Linux 上の普通のプロセスエラーで死んだら、復旧は (必要なら SSH で) 自分の手作業インスタンスタイプの選定task の cpu / memory の組み合わせに合う型を自分で探す2 段階のスケーリングtask の数 (ECS) と EC2 の台数 (ASG / capacity provider) を別々に設計ECS が引き受けるのは「どのホストに何個置くか」まで。ホストそのものは残る。
図 2ecs-agent も Docker も、ホストの上では普通の Linux プロセス。死んだら復旧は自分の手作業。

ホストが残るということは、その上のプロセスも残るということです。 ecs-agent と Docker はホスト上の普通の Linux プロセスなので、これらがエラーで死んだときの対応 (必要なら SSH で入っての手作業) は利用者が行います。 OS のカーネル更新、セキュリティパッチ、Docker のバージョン、ECS 最適化 AMI の更新も利用者の仕事です。

もう一つ残るのが、2 段階のスケーリングです。 task の数は ECS のサービスで決めますが、task を置くための EC2 の台数は別に設計します。 task の cpu / memory の組み合わせに対して無駄の少ないインスタンスタイプを選ぶのも利用者です。

Fargate が解決すること

ECS のドキュメントは Fargate を、「VM のクラスタを用意し、設定し、スケールさせる必要が無くなり、サーバーの種類を選ぶことも、いつクラスタをスケールさせるかを決めることも、クラスタへの詰め込みを最適化することも要らなくなる」技術だと説明しています。 前の節で残った仕事に対応づけると、次の 3 つが消えます。

  • インスタンスの選定：task に「必要な CPU とメモリ」を書くだけで、ホストは Fargate が選ぶ。
  • スケーリング：VM のスケーリングは AWS が全部やるので、利用者が管理するのはコンテナ (task) の数だけになる。
  • インスタンスの管理：コンテナランタイムのバージョン、Linux のバージョン、ホストのセキュリティパッチが全部管理不要になる。

パッチの届け方にも仕組みがあります。 Fargate の実行環境は、カーネルとコンテナランタイムの組み合わせをプラットフォームバージョンとして区切って配ります。 セキュリティ上の問題が見つかると、AWS はパッチ済みの新しい revision を作り、古い revision で動く task に廃止 (retirement) の予定を通知して止めます。 新しく起動する task は、常に最新の revision で動きます。

Fargate の下にある Firecracker

Fargate が task ごとに起動する VM は、microVMマイクロブイエム起動が速く、メモリの消費が小さい軽量な VM。専用のゲストカーネルを持つので、VM の隔離の強さを保てる。用語集で見る と呼ばれる種類のものです。 それを起動しているのが FirecrackerファイアクラッカーAWS が OSS として公開した、KVM を使って microVM を起動する VMM (Rust 製)。用語集で見る で、AWS は Lambda と Fargate のために開発したと説明しています。

Firecracker は、AWS が 2018 年 12 月に Apache 2.0 で公開した、Rust で書かれた VMM (Virtual Machine Monitor) です。 VMM は、VM に見せる CPU、メモリ、ネットワークカードやディスクを用意して VM を起動するプログラムで、QEMU がその例です。 Firecracker は Linux の KVM を呼び出して VM を起動する普通のプロセスで、VM 1 つにつき 1 プロセスが起動し、REST API で設定と起動を受け付けます。

Firecracker の microVM スタックと gVisor のサンドボックス左: ホストの Linux + KVM の上に Firecracker (Rust の VMM) が microVM を作り、その中にゲストカーネル、containerd、runc、コンテナが載る。右: ホスト Linux の上で runsc が Sentry (ユーザー空間のカーネル) を起動し、コンテナのシステムコールを Sentry が受け、ファイルアクセスは Gofer を通す。Firecracker (AWS Lambda / Fargate)ホストマシン (Lambda では EC2 ベアメタル)ホスト Linux + KVMFirecracker VMM (Rust、ユーザー空間)jailer + seccomp で囲うゲストカーネル (microVM 専用、デバイスは 5 種)containerd + runc (firecracker-containerd)コンテナ (task / 関数)分離の仕組み = VM ごとに専用のカーネル。起動 125 ms 未満、1 VM あたり 5 MiB 未満のオーバーヘッド。gVisor (GKE Sandbox / Cloud Run 第 1 世代)ホスト (GKE ならノードの VM。任意の Linux でも)ホスト Linux カーネルrunsc (OCI runtime)platform: systrap (既定) / KVMSentry (Go で書かれたユーザー空間カーネル)syscall を受けて自分で処理Gofer (ファイルアクセスを仲介)コンテナ分離の仕組み = Sentry が syscall を処理する。ホストに届くsyscall を大幅に減らす。VM は作らない。
図 3左: Firecracker は VM ごとに専用のカーネルを動かして隔てる。右の gVisor は、次の章で扱う別の隔て方。

Firecracker は、サーバーレスとコンテナの用途に絞って設計されていて、何でも載せられる汎用 VM を目指していません。 AWS の論文 (NSDI 2020) と設計文書によると、その方針は次の特徴に表れています。

  • VM に見せる仮想デバイスを 5 つに絞る (virtio-net、virtio-block、virtio-vsock、シリアルコンソール、VM を止めるためだけの最小限のキーボードコントローラー)。BIOS も PCI も無く、任意のカーネルは起動できない。QEMU が 40 種類以上のデバイスを持つのに対して、攻撃面が小さい。
  • 起動が速く、VM あたりのメモリのオーバーヘッドが小さい。アプリのコードが動き始めるまで 125 ms 未満、オーバーヘッドは VM あたり 5 MiB 未満、1 ホストで毎秒 150 台まで起動できる。
  • Firecracker 自身が API スレッド、VMM スレッド、vCPU スレッドに分かれ、seccomp で使える syscall を絞る。
  • jailer という付属プログラムが、VMM 自体を chroot、pid と network の namespace、cgroup、seccomp (許可する syscall は 24 個) で囲い、VM の隔離が破られたときの第 2 の防御線になる。
  • ネットワークの通信の絞り込みは Firecracker が行わないので、ホスト側で行う。

Firecracker の中では普通の Linux ゲストカーネルが動くので、その上に containerd と runc を置けば、コンテナはそのまま動きます。 firecracker-containerd は、containerd のランタイムを runc から Firecracker に差し替え、Pod や task を microVM の中で起動するための AWS のプロジェクトです。 Part 3 の分離レベルの話で出てきた Kata Containers も、VMM の選択肢として Firecracker を使えます。

AWS の外でも使われる Firecracker

Firecracker は AWS の内部だけで使える技術ではありません。 Fly.io の Machines は Firecracker の microVM としてアプリケーションを動かし、API から作成や起動を操作できます。 GMO Flatt Security も、AI エージェント Takumi がコードや攻撃の検証を実行するために、Firecracker を使う自社基盤 Sunaba を開発しています。

共通するのは、利用者ごとに分けた実行環境を必要なときに用意する用途です。 Firecracker が担当するのは VM の実行であり、API、VM の配置、ディスク、通信経路、認証、破棄までを含むサービスは各社が組み立てます。 Lambda のリクエストごとの実行と、エージェントがファイルを編集し続ける作業環境では、保存すべき状態や環境の寿命が違います。 同じ VMM を採用していても、サービスの設計まで同じになるわけではありません。

EKS on Fargate

Fargate は EKS でも使えます。

EKS on Fargate: Pod が Fargate の VM に置かれるまでPod が作られると、EKS コントロールプレーンの admission controller が Fargate profile に一致するか判定して Pod を更新し、Fargate 用の scheduler が Fargate に VM を用意する。VM の中の kubelet が Pod execution role の権限でクラスタに Node として登録し、Pod を起動する。kubectl get nodes には fargate-ip-… という Node が 1 Pod につき 1 つ現れる。kubectl applynamespace: batchEKS コントロールプレーンadmission controllerFargate profile に一致?Fargate 用 scheduler一致した Pod を引き取るVM を要求FargateデータプレーンVM (AWS 管理、Pod ごとに 1 つ)Node: fargate-ip-10-0-2-31.…kubeletVPC CNIPod10.0.2.31Node として登録Fargate profile: namespace と label の条件。一致した Pod だけが Fargate へ。他は EC2 ノードへ。制約: DaemonSet 不可、privileged 不可、hostNetwork 不可、EBS 不可 (EFS は可)、GPU 不可、LB は ip ターゲットのみ。
図 4Fargate profile に一致した Pod は、EKS コントロールプレーン側の専用スケジューラが Fargate の VM に置く。Pod ごとに Node が 1 つ生える。

仕組みは Kubernetes の拡張点を素直に使っています。 EKS のドキュメントによると、EKS のコントロールプレーンには、既定の scheduler と並んで動く Fargate 用の scheduler と、いくつかの mutating / validating admission controller が居ます。 Pod が作られると、admission controller が Fargate profile (namespace と label の条件) に一致するかを判定し、一致する Pod を更新して Fargate 用の scheduler が引き取ります。 scheduler は Fargate に VM を用意し、その中の kubelet が、profile に書いた Pod execution role の権限でクラスタに Node として登録し、Pod を起動します。 kubectl get nodes には fargate-ip-10-0-2-31.ap-northeast-1.compute.internal のような Node が、Pod 1 つにつき 1 つ現れます。

Pod ごとに専用カーネルの VM になるので、構造上できないことがそのまま制約になります。

EKS on EC2 と EKS on Fargate
EC2 ノード (managed node group)Fargate
Pod とカーネル同じノードの Pod はカーネルを共有Pod ごとに専用カーネル (VM)
DaemonSet使える使えない (ノードが Pod 専用なので意味がない。sidecar にする)
privileged / hostNetwork / hostPort使える使えない
CNIVPC CNI、または Cilium など別の CNIVPC CNI 固定
ストレージEBS / EFS / FSxEFS のみ (静的プロビジョニング)
LB のターゲットinstance / ipip のみ
GPU / Arm / Windows使える使えない
IAM for PodPod Identity / IRSAIRSA のみ
ノードへの SSHできるできない (ホスト OS が無い)
パッチAMI の更新は利用者AWS が Pod を退避して実施

このほか、Fargate の Pod は private subnet にしか置けず、EC2 のインスタンスメタデータ (IMDS) も使えません。 IAM の資格情報は IRSA で渡し、リージョンや AZ が必要なら Pod の spec に書き込みます。 Fargate profile に一致しない Pod は Pending のままになります。 Job の Pod は完了後も残り、残っているあいだは課金されるので、ttlSecondsAfterFinished で自動削除します。 AWS のドキュメントは、Pod ごとの VM をコンテナからの脱出に対する多層防御と位置づけつつ、アプリを隔てる最も安全な方法は別のクラスタで動かすことだとも書いています。

ECS と EKS の選び方

EKS と ECS はコントロールプレーンの選択肢で、Fargate はデータプレーンの選択肢です。 比べる対象が違うので、EKS か ECS かを決めた後に、Fargate にするかどうかを独立に決められます。

EKS と ECS の違いは、Kubernetes の API を使うかどうかに尽きます。 Helm chart で配布されている OSS を動かしたい、GitOps や Operator を使いたい、複数クラウドで同じ YAML を使いたい、なら Kubernetes の API が要るので EKS です。 AWS の中で閉じていて task definition で足りるなら ECS で、CloudFormation や CodeDeploy のような AWS の他サービスとの連携は ECS のほうが素直です。

ふりかえり

QFargate で DaemonSet が使えない理由として正しいものは?

Fargate では Pod 1 つにつき Node が 1 つ生えます。DaemonSet は「各ノードに 1 つ」を保証する仕組みなので、ノードが Pod 専用なら sidecar で同じことができます。構造上の帰結です。

QFirecracker が QEMU と違う設計方針は?

Firecracker は KVM を使う VMM です。QEMU のように何でも載せられることを目指さず、virtio-net / block / vsock などごく少数のデバイスに絞り、速い起動と小さなオーバーヘッドを実現しています。

QECS と Fargate の関係として正しいものは?

ECS (と EKS) はコントロールプレーンで、Fargate は task / Pod を置く先 (データプレーン) の選択肢です。EKS でも Fargate profile で使えます。

参考