Skip to main content

Docker Compose から Kubernetes への移行ガイド

2026年5月27日by Kubo Team #Docker Compose #Kubernetes #移行 #Kompose #Helm #Kustomize #コンテナオーケストレーション

Docker Compose は開発環境やシンプルなデプロイに優れていますが、本番環境でのスケーラビリティ・可用性・運用自動化には Kubernetes が必要です。しかし、Docker Compose から Kubernetes への移行は「YAML を書き換えるだけ」では済みません。ネットワーキング、ストレージ、シークレット管理など、根本的なアーキテクチャの違いを理解した計画的な移行が成功の鍵です。

Kubo は、本番グレードの Kubernetes 基盤を提供し、Docker Compose からの移行をスムーズにサポートします。本記事では、移行の全フェーズを実践的に解説します。

Docker Compose と Kubernetes の根本的な違い

移行を始める前に、両者のアーキテクチャの違いを理解しておくことが重要です。

項目Docker ComposeKubernetes
スコープ単一ホストマルチノードクラスタ
スケーリング手動（scale オプション）自動（HPA / VPA）
ヘルスチェックhealthcheck ディレクティブliveness / readiness / startup Probes
ネットワークブリッジネットワークService / Ingress / NetworkPolicy
ストレージバインドマウント / ボリュームPersistentVolume / PersistentVolumeClaim
シークレット.env ファイル / secretsSecret / External Secrets Operator
サービスディスカバリコンテナ名 / サービス名DNS ベースの Service
ローリングアップデートなしDeployment 戦略で制御

Kubernetes 公式ドキュメントでは、Kompose を使った変換手順が紹介されていますが、これはあくまで出発点です。

Captain.AI を活用すれば、Docker Compose ファイルの分析から Kubernetes マニフェストの最適化まで、AI が移行プロセスを支援します。

フェーズ1: 現状分析とアーキテクチャ監査

移行の第一歩は、現在の Docker Compose 構成を徹底的に分析することです。

チェックリスト

  • サービス依存関係: depends_on で定義された起動順序の把握
  • ボリュームマッピング: 開発用バインドマウント（./src:/app）と永続データの区別
  • ネットワーク構成: カスタムネットワークとサービス間通信の把握
  • 環境変数: .env ファイル、environment ディレクティブ、シークレットの整理
  • ビルドコンテキスト: build ディレクティブの有無（K8S ではビルド済みイメージが必要）
  • リソース制約: mem_limit, cpus などの設定
yaml
# 典型的な Docker Compose 構成
services:
  web:
    build: ./web
    ports:
      - "8080:8080"
    environment:
      - database_url=postgres:--db:5432-myapp
    depends_on:
      - db
    volumes:
      - .-web:-app  # 開発用バインドマウント
  
  db:
    image: postgres:16
    volumes:
      - db-data:-var-lib-postgresql-data
    environment:
      - POSTGRES_PASSWORD=secret

volumes:
  db-data:

重要: 開発用バインドマウント（./web:/app）は Kubernetes に移行できません。アプリケーションコードはイメージに含める必要があります。SFEIR の移行ガイドでも、このポイントが強調されています。

フェーズ2: Kompose による自動変換

Kompose は、Docker Compose ファイルを Kubernetes マニフェストに自動変換するツールです。

インストール

bash
# macOS
brew install kompose

# Linux
curl -L https://github.com/kubernetes/kompose/releases/download/v1.34.0/kompose-linux-amd64 -o kompose
chmod +x kompose && sudo mv ./kompose /usr/local/bin/kompose

基本的な変換

bash
# docker-compose.yml を Kubernetes マニフェストに変換
kompose convert

# 出力例:
# INFO Kubernetes file "web-service.yaml" created
# INFO Kubernetes file "db-service.yaml" created
# INFO Kubernetes file "web-deployment.yaml" created
# INFO Kubernetes file "db-deployment.yaml" created
# INFO Kubernetes file "db-data-persistentvolumeclaim.yaml" created

Kompose は各 Docker Compose サービスから Deployment と Service の 2 つの Kubernetes リソースを生成します。ボリュームは PersistentVolumeClaim に変換されます。

Kompose ラベルによるカスタマイズ

yaml
services:
  web:
    image: myapp:latest
    ports:
      - "8080:8080"
    labels:
      kompose.service.type: LoadBalancer
      kompose.service.expose: "myapp.example.com"
      kompose.image-pull-policy: Always

ただし、Support Tools の移行ガイドが指摘するように、Kompose は「機能的なベースを作成するが、本番に最適とは限らない」ため、次のフェーズでの精緻化が必要です。

フェーズ3: Helm / Kustomize による本番化

Kompose で生成したマニフェストを本番品質に引き上げるには、Helm または Kustomize を活用します。

Helm チャートへの移行

bash
# Helm チャートのスキャフォールド
helm create myapp

# ディレクトリ構造
myapp/
  Chart.yaml
  values.yaml
  templates/
    deployment.yaml
    service.yaml
    ingress.yaml
    hpa.yaml

values.yaml で環境ごとの設定値を外部化します:

yaml
# values.yaml
replicaCount: 3
image:
  repository: harbor.example.com/myproject/web
  tag: "1.0.0"
  pullPolicy: IfNotPresent
resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi
ingress:
  enabled: true
  hosts:
    - host: myapp.example.com
      paths:
        - path: /
          pathType: Prefix

必須の追加設定

Kompose が自動生成しない、本番環境で必須の設定を追加します:

yaml
# ヘルスチェック（Probes）
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

# リソース制限
resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi

# Pod Disruption Budget
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: web

Kubo の Kubernetes 環境では、Helm チャートによるデプロイが標準的なワークフローとなっています。

フェーズ4: ストレージとネットワークの移行

ストレージ移行

Docker Compose のボリュームは Kubernetes の PersistentVolumeClaim（PVC）にマッピングします。

yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  resources:
    requests:
      storage: 10Gi

データベースの永続化には StatefulSet の使用を検討してください。StatefulSet は安定したネットワーク ID と永続ストレージを提供し、データベースワークロードに適しています。

シークレット管理

.env ファイルのシークレットは Kubernetes Secret に移行します:

bash
# Secret の作成
kubectl create secret generic db-credentials \
  --from-literal=POSTGRES_PASSWORD=secure-password

# または External Secrets Operator で外部シークレットストアと連携

HashiCorp Vault や AWS Secrets Manager との連携には、External Secrets Operator が推奨されます。

ネットワーキング

Docker Compose のサービス名ベースの通信は、Kubernetes の Service を通じた DNS ベースのサービスディスカバリに移行します:

yaml
# Docker Compose: DATABASE_URL=postgres://db:5432/myapp
# Kubernetes:     DATABASE_URL=postgres://db-service.default.svc.cluster.local:5432/myapp

フェーズ5: テストと段階的ロールアウト

移行の最終フェーズでは、段階的なロールアウトとバリデーションを実施します。

移行テスト戦略

  1. ステージング環境での検証: 本番移行前にステージング環境で全機能テスト
  2. 負荷テスト: k6 や Locust で本番相当の負荷をかけて検証
  3. カナリアデプロイ: トラフィックの一部を新環境に振り向けて段階的に移行
  4. ロールバック計画: 問題発生時に即座に旧環境に切り戻せる手順を準備
yaml
# カナリアデプロイの例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-canary
spec:
  replicas: 1  # トラフィックの一部のみ
  selector:
    matchLabels:
      app: web
      track: canary

中規模アプリケーションの場合、移行全体で 2〜4 週間を計画するのが妥当です。dasroot の移行ガイドでも同様のタイムラインが推奨されています。

まとめ: 計画的な移行で本番 Kubernetes へ

Docker Compose から Kubernetes への移行は、以下の 5 フェーズで計画的に進めましょう:

  1. 現状分析: Docker Compose 構成の棚卸しと依存関係の整理
  2. 自動変換: Kompose による初期マニフェスト生成
  3. 本番化: Helm/Kustomize での Probes、リソース制限、Ingress 追加
  4. ストレージ・ネットワーク移行: PVC、Secret、Service の設定
  5. 段階的ロールアウト: ステージング検証、カナリアデプロイ、負荷テスト

Kubo は、Docker Compose からの移行先として最適な Kubernetes 基盤を提供しています。Captain.AI による AI 支援で、Kubernetes マニフェストの生成から運用の自動化まで、移行プロセス全体をサポートします。

Kubernetes への移行をご検討の方は、ぜひお問い合わせください。

← Back to all posts