Docker ComposeとKubernetesの違いは？本番運用と選び方を図解

ひよこ

DockerとKubernetesは同じ種類のツールなの？

ペンギン先生

役割が違うよ。Docker Engineはコンテナを起動・管理するエンジン。Composeは複数サービスの設定をまとめて扱う道具で、Kubernetesはクラスタ全体で望ましい状態を維持する仕組みなんだ。まずこの3つを分けよう。

ひよこ

Composeはどう使うの？

ペンギン先生

compose.yamlにWebアプリ、DB、ネットワーク、ボリュームなどを定義し、docker compose upでまとめて起動するよ。通常のCompose運用は1台のDockerホストが基本。開発だけでなく、停止時間を許容できる単一ホストの本番構成にも使えるんだ。

ひよこ

コンテナが落ちたら、Composeでは直せない？

ペンギン先生

Composeにもrestartポリシーがあるよ。ただしホスト自体が故障したとき、別ホストへ配置し直す仕組みとは違う。healthcheckで異常を検出することと、異常時にどう復旧するかも分けて設計する必要があるんだ。

ひよこ

Kubernetesなら別のサーバーで動かせる？

ペンギン先生

Deploymentなどのコントローラーが必要なPod数を維持しようとするよ。ただし別ノードの空き容量、ストレージ、ネットワークなどの条件が必要。再配置できることと、データを失わず無停止で復旧できることは同じではないんだ。

ひよこ

アクセスが増えたら勝手に増やしてくれる？

ペンギン先生

Horizontal Pod Autoscalerなどを設定し、利用するメトリクスも用意する必要があるよ。Podを増やしてもDBが詰まっていたら解決しない。アプリの複製数、ノード容量、DBの処理能力を別々に確認しよう。

ひよこ

小さなサービスにもKubernetesが必要？

ペンギン先生

規模だけで決めなくていいよ。1台停止したときの許容時間、更新頻度、運用できる人数が判断材料。ComposeとマネージドDBで足りる場合もあるし、チームが既にクラスタを運用していれば小さなアプリを載せる選択もあるんだ。

ひよこ

Composeの設定を変換すれば移行完了かな？

ペンギン先生

変換は出発点だよ。ホストのフォルダを使う設定、秘密情報、公開ポート、起動順への依存を見直そう。特にDBのデータ保持、バックアップと復元、アプリ側の再接続は、YAMLを変換するだけでは確認できないんだ。

ひよこ

最後は何を確かめればいい？

ペンギン先生

検証環境でコンテナ停止、ホスト停止、更新失敗を試して、復旧時間とデータの状態を確認しよう。Kubernetesは運用を支える機能を提供するけれど、アプリの監視やバックアップまで自動的に完成するわけではないよ。

先に答え：違いは「何台か」だけでなく「障害時に誰が復旧するか」

「Composeは開発専用」「Kubernetesなら高可用性が保証される」は、どちらも正確ではありません。 たとえばWebアプリとDBが同じ1台にあるなら、コンテナの再起動ではサーバー故障を救えません。Kubernetesでも、DBの保存先が故障したノードにしかなければ同じ問題が残ります。

移行前に確認する3つの質問

1. 何分止められるか。 再起動・手動復旧でよいのか、別ノードでの復旧が必要かを決めます。
2. どこにデータがあるか。 コンテナを作り直した後に残る保存先と、バックアップからの復元を確認します。
3. 誰が保守するか。 マネージドKubernetesでも、アプリ設定・権限・更新・監視の責任は残ります。

Docker自体の役割はDockerの仕組み、別のエンジンとの比較はPodmanとDockerも参照してください。

起動順・健康状態・復旧は別の機能

Composeのdepends_onは、短い書き方だけではDBが接続を受け付けられるまで待つ保証にはなりません。healthcheckとcondition: service_healthyを組み合わせると、起動時に依存サービスの健康状態を待つ構成にできます。起動後の切断に備えるアプリの再接続処理も必要です。

また、Composeのhealthcheckが不健康を報告しただけでは、通常のrestartポリシーによる再起動は起きません。プロセスが終了した場合の再起動とは区別します。Kubernetesではliveness probeの失敗でコンテナを再起動する設定ができ、readiness probeは通信を受け付ける準備を示すための別の検査です。

更新に失敗したら自動で前の版に戻る？

KubernetesのDeploymentは更新の進み具合を報告しますが、進行期限を超えたという理由だけで自動ロールバックはしません。前の版へ戻す判断や、kubectl rollout undoなどの手順を運用に組み込みます。DB変更や外部サービスへの副作用まで元に戻せるとは限らないため、アプリの更新とデータの復元も分けて考えましょう。

選び方のまとめ

1台の停止を許容でき、運用をシンプルにしたいならComposeが候補です。複数ノードへの配置や継続的な状態維持が必要で、保守体制も用意できるならKubernetesを検討します。導入前に、止めてよい時間とデータの保存先を具体化するのが先です。

参考資料

確認日：2026年10月4日。製品の仕様・料金・対応環境は導入時にも確認してください。

• Docker: Use Compose in production：単一ホストの本番運用とrestart設定。

• Compose services reference：restart・healthcheckの個別設定。

• Kubernetes Overview：自己修復・スケーリングと提供しない機能。

• Docker — Control startup and shutdown order：起動順とservice_healthyの違い。

• Kubernetes — Deployments：進行期限とロールバック。

• Kubernetes — Liveness, Readiness, and Startup Probes：再起動と準備状態の区別。