Docker vs Kubernetes を検索すると、どちらかを選択する必要があることが示唆されますが、その枠組みが多くの混乱を引き起こします。これは、輸送用コンテナと、それを数千個まとめて管理する港を比較するようなものです。これらは異なるレベルで動作し、並行して使用されることもよくあります。

このガイドでは、それぞれが何をするのかを説明し、両方で同じ小さなアプリを示し、実際的な決定方法で終わります。ここにあるコマンドとファイルは標準的な例ですが、この記事では実行しませんでした。そのため、インストールするバージョンと照らし合わせて確認してください。

短い答え

Docker は、アプリケーションとその依存関係をイメージにパッケージ化し、そのイメージをコンテナとして実行するためのプラットフォームです。 「このアプリをどこでも同じように実行するにはどうすればよいですか?」という質問に答えます。

Kubernetes (K8s と表記されることも多い) は、コンテナ オーケストレーターです。多くのマシンのどこでコンテナーを実行するかを決定し、障害が発生したときにコンテナーを再起動し、需要に応じてコンテナーを拡張します。これは、「数百のコンテナを確実に実行し続けるにはどうすればよいですか?」という質問に答えます。

Docker と Kubernetes を並べて表示

Docker が行うこと

コンテナーが登場する前は、サーバーごとにすべてのバージョンが異なっていたため、「自分のマシンで動作する」ということが日常的な問題でした。 Docker は、コード、ランタイム、ライブラリを 1 つの イメージ にバンドルします。そのイメージの実行中のコピーは コンテナ であり、ホストのカーネルを共有するため、完全な仮想マシンよりも起動が速く、使用するメモリが少なくなります。

ワークフローには 3 つのステップがあります。

1. ビルド: a Dockerfile では、イメージの作成方法について説明します。
2. Ship: イメージを Docker Hub などのレジストリにプッシュします。
3. 実行: 互換性のあるマシン上でそのイメージからコンテナを開始します。

実践的に学ぶには、初心者向けの Docker チュートリアルから始めて、Dockerfile のベスト プラクティスを読んでください。

Kubernetes が行うこと

1 つのサーバー上の Docker は、そのサーバーに障害が発生したり、トラフィックが増大したり、調整する必要のあるサービスが数十個存在するまでは正常に動作します。 Kubernetes は次の運用ジョブを処理します。

• スケジュール: 十分な空き容量のあるマシンにコンテナを配置します。
• 自己修復: 障害が発生したコンテナを置き換え、障害が発生したノードから作業を移動します。
• スケーリング: 手動またはメトリクスに基づいてコピーを追加または削除します。
• サービスディスカバリ: 変化するコンテナのグループに 1 つの安定した名前を与えます。
• ローリング アップデート: 簡単なロールバックで新しいバージョンを段階的にリリースします。
• 構成: 設定とシークレットを画像とは別に管理します。

中心となるアイデアは望ましい状態です。あなたは 3 つのコピーが存在するはずだと宣言すると、管理者はそれを現実と比較し、差異を修正し続けます。 初心者向け Kubernetes チュートリアルでは、ローカル クラスター上でこれについて説明します。

Docker と Kubernetes がどのように連携するか

開発者のラップトップから運用環境への一般的なパスは次のようになります。

1. 開発者は Dockerfile を書き込み、コンテナをローカルでテストします。
2. CI/CD パイプラインはイメージを構築し、テストを実行します。
3. パイプラインは、バージョン管理されたイメージをレジストリにプッシュします。
4. Kubernetes マニフェストは、そのイメージ バージョンを使用するように更新されます。
5. Kubernetes はイメージをプルし、クラスター全体にロールアウトします。

つまり、Docker の仕事は、Kubernetes が開始される前にほぼ完了しています。画像は両者間の引継ぎ地点です。

1 つのアプリで双方向に対応

ここに小さな Web サービスがあります。イメージは、どのツールが実行しても同じ方法で構築されます。

# Dockerfile
FROM python:3.13-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

Dockerで実行する

docker build -t shop-api:1.0 .
docker run -d --name shop -p 8080:8000 --restart unless-stopped shop-api:1.0

コマンドを 2 つ実行すると実行されます。これはシンプルで、多くの小規模プロジェクトに適しています。ただし、1 台のマシンに 1 つのコピーがあり、マシンが停止すると、サービスも一緒に停止します。

Kubernetes で実行する

# shop.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop
spec:
  replicas: 3
  selector:
    matchLabels:
      app: shop
  template:
    metadata:
      labels:
        app: shop
    spec:
      containers:
        - name: api
          image: registry.example.com/shop-api:1.0
          ports:
            - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
  ports:
    - port: 80
      targetPort: 8000

kubectl apply -f shop.yaml
kubectl get pods -l app=shop

書き込むべきことはまだたくさんあり、それを実行するにはクラスターが必要です。その代わりに、安定した内部アドレスと自動置換の 3 つのコピーが得られます。このトレードオフは、意思決定全体を縮図したものであり、より高い回復力と引き換えにより複雑にするというものです。

コンテナに障害が発生するとどうなりますか?

dockershim の混乱

「Kubernetes は Docker を削除した」という記事を読んだことがあるかもしれません。これは狭い意味では真実であり、多くの人を不必要に怖がらせました。 Kubernetes は、Container Runtime Interface と呼ばれる標準を通じてコン​​テナを実行します。 Docker Engine はこれを直接実装しなかったため、Kubernetes には dockershim と呼ばれるアダプターが含まれていました。このアダプターはバージョン 1.24 で削除されました。

現在、クラスターでは通常、containerd や CRI-O などのランタイムが使用されます。 Docker で構築したイメージは Open Container Initiative (OCI) イメージ標準に準拠しているため、引き続き動作します。したがって、Docker を使用して構築を続けることができ、クラスターはその結果を別のランタイムで実行します。

Docker Compose 対 Swarm 対 Kubernetes

より意味のある比較は、コンテナを調整するツール間の比較です。

Docker Compose は 1 つのファイルから複数の関連コンテナを起動し、ラップトップ上の Web アプリとデータベースに最適です。 Swarm は Docker に組み込まれており、Kubernetes よりも学習がはるかに簡単ですが、エコシステムははるかに小さいです。 Kubernetes には最大のコミュニティとツールがあり、これが大規模なデプロイメントのデフォルトとなった大きな理由です。

どれが必要ですか?

通常、次の場合には Docker だけで十分です。

• ローカルで開発しているか、1 つのサーバー上で小さなアプリを実行しています。
• チームの規模が小さく、専任の運用スタッフがいません。
• 時折の短いダウンタイムは許容されます。

Kubernetes は次のような場合に意味を持ち始めます。

• さまざまなチームが独自にデプロイする多くのサービスを実行します。
• 複数のマシンまたはゾーンにわたる高可用性が必要です。
• トラフィックは十分に変化するため、自動スケーリングによって実際のコストが節約されます。
• それを運用するためのスキルまたは予算がある。

中間点もあります。 AWS Fargate、Google Cloud Run、PaaS などのマネージドコンテナプラットフォームは、維持するクラスターなしで Docker イメージを実行します。多くの成長企業にとって、すぐに Kubernetes に移行するのではなく、それが正しい次のステップです。

キャリア上の理由から両方を学びたい場合、順序は明らかです。最初に Docker、次に Kubernetes です。最初にイメージ、ポート、コンテナーのログを理解しなければ、Pod を快適にデバッグすることはできません。

よくある間違い

• Kubernetes の導入が早すぎます。 巨大企業のアーキテクチャをコピーすると、小規模なチームが運用作業に埋もれてしまう可能性があります。
• 運用環境で latest タグを使用する。 何が実行されているかを判断したり、確実にロールバックしたりすることはできません。特定のバージョンタグを使用します。
• コンテナ内にデータを保存します。 コンテナは使い捨てであるため、ボリュームまたは管理されたデータベースを使用します。
• ヘルスチェックのスキップ。 readiness プローブと liveness プローブがなければ、Kubernetes はアプリに関して適切な決定を下すことができません。
• リソース制限を忘れる。 1 つの貪欲なコンテナがノード上の他のすべてを枯渇させる可能性があります。

まとめ

Docker がソフトウェアをパッケージ化し、Kubernetes がそれを大規模に実行します。どちらが良いかを尋ねるのではなく、今日どのような問題を抱えているかを尋ねてください。 「アプリのインストールが難しい」場合は、Docker を使用してください。 「40 個のサービスがサーバー障害に耐える必要がある」場合は、Kubernetes を検討してください。実際の問題を解決する最も単純なツールから始めて、必要性がわかったら次のツールに進みます。

よくある質問

学び続ける