コンテナ vs VM - container vs VM

VM は物理ハードウェア上にハイパーバイザ（KVM, Hyper-V, VMware ESXi 等）を置き、その上にゲスト OS を丸ごと動かします。

各 VM は自分専用のカーネル・ドライバ・init プロセスを持ちます。

コンテナはホスト OS のカーネルをそのまま共有し、ユーザースペースだけを namespace と cgroups で分割します。

アプリから見ると独立した OS に見えますが、カーネルは 1 つです。

VM:        [App] [Libs] [Guest OS + Kernel] ──┐
           [App] [Libs] [Guest OS + Kernel] ──┼── [Hypervisor] ── [Host OS] ── [HW]
           [App] [Libs] [Guest OS + Kernel] ──┘

Container: [App] [Libs] ──┐
           [App] [Libs] ──┼── [Container Runtime] ── [Host OS + Kernel] ── [HW]
           [App] [Libs] ──┘

ゲスト OS を起動する VM は、BIOS 相当の初期化・カーネル起動・init・サービス群の起動と段階を踏むため、数十秒〜数分かかります。

イメージもカーネルとルートファイルシステムを含むため数 GB 〜です。

コンテナはカーネルを共有するので、実体は「新しいプロセスを namespace 付きで fork する」だけです。

ミリ秒〜数秒で起動し、CPU とメモリのオーバーヘッドはほぼアプリ本体のみ。

結果として 1 台の物理ホストに載る同時数は、VM が数十なのに対しコンテナは数百〜数千規模になります。

VM はハイパーバイザがハードウェア境界でゲストを分離するため、ゲスト OS のカーネル脆弱性だけではホスト侵害には至りにくい構造です。

マルチテナントの強い隔離が必要な場面（異なる顧客のワークロード、信頼できないコード実行など）では VM の方が安全とされます。

コンテナはカーネルを共有しているため、カーネル脆弱性が 1 つでもあるとコンテナ脱出（container escape）の危険があります。

これを緩和するため、rootless 実行、seccomp、AppArmor / SELinux、ユーザー namespace を組み合わせて運用します。

信頼できないコードを動かす場合は、コンテナ単体ではなく軽量 VM（Firecracker / Kata Containers）や gVisor と組み合わせるのが定石です。

観点	VM を選ぶ	コンテナを選ぶ
カーネル	Windows と Linux を同居させたい・異なるカーネルが必要	ホストと同じカーネルでよい
隔離強度	マルチテナントで信頼できないワークロードを動かす	同一組織・同一信頼レベルの多数サービス
密度・起動速度	数十台規模で十分	数百〜数千のサービスを俊敏に増減したい
ライフサイクル	長期稼働	頻繁に作り直す（Immutable Infrastructure）
運用対象	OS ごと運用する既存システム	アプリを単位に運用する新規サービス

実務ではどちらか一方ではなく、「IaaS の VM の上でコンテナを動かす」「EC2 の上で Kubernetes を動かす」のように階層化して両方を使うのが一般的です。