コンテナ技術の利用が広がる中で、開発環境や本番環境でのコンテナのオーケストレーションが重要になっています。

その際、選択肢として挙がるのが「Docker Compose」と「Kubernetes（K8s）」です。
どちらを使うべきかは、プロジェクトの規模や目的によって大きく異なります。

本記事では、両者の特徴と違いを丁寧に比較し、具体的なユースケースやサンプルコードを交えて、適切な選択ができるよう解説します。

小規模〜中規模開発に適したDocker Compose

Docker Composeは、開発者が複数のDockerコンテナを簡単に構成・起動できるツールです。

YAMLファイルを使ってサービスやネットワーク、ボリュームなどを記述し、1コマンドで一括管理できます。

基本構成例

yamlCopy code# docker-compose.yml
version: '3.9'
services:
  app:
    image: node:18
    volumes:
      - .:/app
    working_dir: /app
    command: ["npm", "start"]
    ports:
      - "3000:3000"
  db:
    image: postgres:15
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: example
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

起動コマンド

bashCopy codeyarn docker:up
# または
docker-compose up -d

特徴と利点

特徴	内容
導入が簡単	docker-compose.yml の記述だけで利用可能
学習コストが低い	Dockerの知識があればすぐ使える
ローカル開発に最適	ホスト連携やライブリロードが容易
CI/CDパイプラインとも統合しやすい	GitHub Actionsなどと相性良好

公式ドキュメント：https://docs.docker.com/compose/

本番環境・スケーラビリティ重視ならKubernetes

Kubernetesは、複数ノード上のコンテナを自動的にスケール・復旧・展開するための本格的なオーケストレーションシステムです。

複雑な構成を前提としており、大規模なプロダクション環境に適しています。

基本構成例（Deployment + Service）

yamlCopy code# app-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: node-app
  template:
    metadata:
      labels:
        app: node-app
    spec:
      containers:
        - name: node-app
          image: node:18
          ports:
            - containerPort: 3000

yamlCopy code# app-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: node-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000
  type: LoadBalancer

適用コマンド

bashCopy codekubectl apply -f app-deployment.yaml
kubectl apply -f app-service.yaml

特徴と利点

特徴	内容
自動スケーリング対応	負荷に応じたPod数調整が可能
セルフヒーリング	落ちたPodは自動で再作成
ローリングアップデート	無停止で新バージョンに切り替え可能
高可用性が求められる場面に最適	本番サービスの運用に最適化

公式ドキュメント：https://kubernetes.io/ja/docs/home/

YAML構文の違いから見る構成の複雑性

比較項目	Docker Compose	Kubernetes (YAML)
構成ファイルの数	基本は1ファイル	リソースごとに複数ファイル
依存関係の定義	depends_onで定義可能	明示的な順序制御が難しくリトライ戦略が必要
スケール設定	docker-compose scale（非推奨）	replicasで容易に指定可能
ボリューム設定	volumesセクションで簡潔	PersistentVolume/PVCと複雑化

ローカル vs クラウド

利用環境	Docker Composeの向き	Kubernetesの向き
ローカル開発	◎	△（minikubeなどの導入が必要）
ステージング	○	◎
本番運用	△	◎（マネージドK8sとの連携）

たとえば、EKS（AWS）、GKE（GCP）、AKS（Azure）といったKubernetesのマネージドサービスを活用することで、運用の負担を軽減できます。

公式リンク：

• Amazon EKS
• Google GKE
• Azure AKS

開発から運用への移行を考えると…

開発初期はDocker Composeでシンプルに始め、
スケールや信頼性が求められるフェーズに入った段階でKubernetesへ移行するのが一般的です。

以下のようなステップを取ることでスムーズに移行できます。

bashCopy code# Komposeを使ってCompose → Kubernetesへ変換
kompose convert -f docker-compose.yml

ユースケースで見る適切な選択指針

実際のプロジェクトでは、どちらを選ぶべきかは利用シーンによって大きく異なります。

ここでは、代表的なユースケースごとに適した選択を紹介いたします。

ローカル開発：Docker Composeが優位

• 単一リポジトリでの開発
• バックエンド＋フロントエンド＋DBの組み合わせが中心
• ローカルでのホットリロードやデバッグを重視

実例：React + Node.js + PostgreSQL

yamlCopy code# docker-compose.yml
version: '3.8'
services:
  frontend:
    build: ./frontend
    ports:
      - "3000:3000"
    volumes:
      - ./frontend:/app
      - /app/node_modules
    environment:
      - CHOKIDAR_USEPOLLING=true
  backend:
    build: ./backend
    ports:
      - "4000:4000"
    depends_on:
      - db
  db:
    image: postgres:15
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: devdb
      POSTGRES_USER: devuser
      POSTGRES_PASSWORD: devpass

volumes:
  pgdata:

これだけで3つのコンテナが一斉に起動し、連携可能です。学習コストも低く、数分で開発開始できます。

本番運用：Kubernetesが圧倒的に有利

• スケールが必要
• 自動復旧・セルフヒーリングが求められる
• CI/CD・GitOpsと連携した高度な運用が必要

実例：3つのアプリをKubernetesで運用

yamlCopy code# frontend-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
        - name: frontend
          image: myregistry.com/frontend:latest
          ports:
            - containerPort: 3000

このようにアプリごとに Deployment、Service を分けて管理し、Ingress や HorizontalPodAutoscaler を追加することで大規模なアーキテクチャへ拡張可能です。

Docker ComposeからKubernetesへの移行戦略

開発段階でComposeを使っていた場合でも、後からKubernetesに移行可能です。

Komposeを使った自動変換

bashCopy codekompose convert -f docker-compose.yml

これにより、Deployment / Service / PersistentVolumeClaim などが自動生成されます。

ただし、以下のような差異には注意が必要です：

差異ポイント	解説
depends_on	Kubernetesでは使えず、ReadinessProbe等で対応
ボリュームの構成	PVCとして分離する必要あり
ポート指定	targetPortとportの明示が必要
イメージビルド	Composeは build に対応、K8sは事前ビルドが前提

Skaffoldなどによる両対応環境の構築

Googleが提供するSkaffoldを利用することで、ComposeでもK8sでもビルド・デプロイが一貫して行えます。

yamlCopy code# skaffold.yaml（抜粋）
deploy:
  kubectl:
    manifests:
      - k8s/*

CI/CD環境でもそのまま流用でき、学習→運用の橋渡しが可能になります。

Kubernetesを学ぶためのロードマップ

Kubernetesは複雑なため、段階的な学習が必要です。

ステップ別ロードマップ

ステップ	学習内容	おすすめリソース
Step1	YAML構文とPod/Serviceの概念	K8s入門ガイド
Step2	Deployment・スケーリングの理解	Deployment公式
Step3	Helmを使った構成管理	Helm公式
Step4	クラウド（GKE/EKS/AKS）での本番運用	EKS公式、GKE

最初は minikube などローカルK8sから始めると良いでしょう。

両者を組み合わせるアプローチ

実はDocker ComposeとKubernetesは併用可能です。

例：開発はCompose、本番はK8s

• docker-compose.dev.yml でローカル開発
• helm chart + GitOpsでK8sにデプロイ

CI環境では Dockerfile を共通で使い回すこともでき、構成の重複を避けられます。

まとめ

Docker ComposeとKubernetesは、競合ではなく補完関係にあります。

フェーズ	選択すべきツール
開発・検証	Docker Compose
ステージング	両方（Bridge利用）
本番・運用	Kubernetes

無理にどちらかに統一せず、段階的な導入と併用の戦略を取ることで、スムーズな運用体験が得られます。

今後は、Helm・Argo CD・Kustomizeなどと連携した拡張にも注目することで、さらに強力なオーケストレーション環境が構築できるようになります。