KubernetesとDockerの違いを徹底比較！非推奨化の真相と関係性

「KubernetesでDockerが非推奨になった」というニュースは、Dockerそのものが使えなくなるという意味ではありません。実際には、KubernetesとDockerは競合するツールではなく、ローカル開発と大規模運用のそれぞれで異なる役割を持つ補完的な関係にあります。

本記事では、KubernetesとDockerの違いや非推奨化の真相、そして両者を組み合わせた最適なシステム運用の手順を具体的に解説します。開発フェーズから本番運用まで、安定したコンテナ基盤を構築するための実践的な知見が得られます。

KubernetesとDockerの決定的な違いと役割分担

システム開発においてコンテナ技術の導入を検討する際、KubernetesとDockerの違いを正確に理解しておくことは非常に重要です。両者は競合するツールではなく、役割が明確に異なる補完的な関係にあります。

Dockerは、アプリケーションとその実行環境をパッケージ化し、単一のホスト（サーバーやPC）上でコンテナを作成・実行するためのプラットフォームです。一方のKubernetesは、複数ホストにまたがる膨大な数のコンテナを統合的に管理・自動化する「オーケストレーションツール」として機能します。

具体的なユースケースの比較

両者の違いは、実際のユースケースに当てはめると分かりやすくなります。

• Dockerのユースケース（開発・テスト）： 手元のPC（WindowsやMac）で「Docker Desktop」を立ち上げ、Webアプリケーションの開発環境を構築する場合に活躍します。「Dockerfile」に環境を記述すれば、チーム全員が同じ環境を1コマンドで再現できるため、ローカル開発や小規模な検証環境の立ち上げに最適です。
• Kubernetesのユースケース（大規模・本番運用）： 数百万アクセスを処理する大規模なSaaSやECサイトのインフラ運用に威力を発揮します。キャンペーンやテレビ放映などで急激なアクセス増があった際に自動でサーバー（コンテナ）を増やす「オートスケール」や、サーバーに障害が起きた際に別ノードで自動的にコンテナを再起動する「セルフヒーリング機能」など、安定した本番稼働に必要な機能が揃っています。

DockerとKubernetesの機能比較表

両者の機能や特徴を以下の表に整理します。自社の開発規模や要件に合わせて、どちらを導入すべきかの判断材料として活用してください。

比較項目	Docker	Kubernetes
主な役割	コンテナの作成・単一ホストでの実行	複数ホストにまたがるコンテナの統合管理
スケーリング	手動または簡易的な拡張（例：Docker Composeによるスケール）	トラフィックに応じた自動スケーリング（例：HPAによるPod数の増減）
障害復旧	自動復旧機能は限定的	コンテナ障害時の自動再起動および別ノードへの再配置
ネットワーク	単一ホスト内のネットワーク管理が中心	複数ノード間の高度なルーティングと負荷分散（例：IngressやServiceの活用）
主なユースケース	ローカル開発環境の構築（例：Docker Desktopでの検証）、小規模なデプロイ	大規模な本番環境（例：AWS EKSやGoogle GKEでの運用）、AIワークロードの基盤

ローカルでの手軽な開発にはDockerが適していますが、本番環境での安定稼働や高度な自動化を求める場合は、Kubernetesの導入が不可欠です。

KubernetesでDockerが非推奨化された真相と影響

近年、IT業界で「Kubernetes環境においてDockerが非推奨になった」という話題が大きな注目を集めました。しかし、これはDockerそのものが使えなくなるという意味ではありません。

dockershimの非推奨化と完全削除の経緯

Kubernetes公式は、バージョン1.20（2020年12月リリース）でコンテナランタイムとしてのDockerを直接サポートするためのブリッジ機能「dockershim」を 非推奨（deprecated） としました（出典：Don't Panic: Kubernetes and Docker）。

その後、Kubernetes 1.24（2022年5月リリース）でdockershimは完全に削除（removed） されました。これが「Docker非推奨化」として広く報道された変更の正体です。

この変更はあくまで「Kubernetesがdockershimを通じてDockerを直接ランタイムとして操作する仕組みの廃止」であり、Dockerエンジン自体の廃止ではありません。Dockerによって生成されたコンテナイメージはOCI（Open Container Initiative）標準に準拠しているため、containerdなど他のCRI準拠ランタイム環境でもこれまで通り使用可能です。

重要なポイントを整理すると:

• 廃止されたもの: Kubernetes内蔵のdockershim（Dockerを直接呼び出すブリッジ機能）
• 廃止されていないもの: Docker Engine、Dockerイメージ、Dockerfile
• 引き続き使えるもの: Docker Desktopでのローカル開発、Dockerで作成したコンテナイメージの本番デプロイ（containerd経由）

Docker Desktopへの影響はなし

ローカル開発環境における影響も心配無用です。Docker Desktopでは、Kubernetes 1.24以降のバージョンですでに「dockershim」から「cri-dockerd」への切り替えが完了しています。

そのため、開発者は既存のワークフローやイメージを一切変更することなく、以前と同じように機能を利用し続けることができます（出典：Dockershim は必要ありません: Docker Desktop with Kubernetes 1.24+）。

CRI（Container Runtime Interface）による標準化とは

かつてKubernetesは、コンテナを実行する基盤としてDockerに強く依存していました。しかし現在では、KubernetesのCRI（Container Runtime Interface）と呼ばれる仕組みによって、特定の技術への依存から脱却しています。

複数のランタイムをサポートする仕組み

CRIは、Kubernetesのノードエージェントであるkubeletと、さまざまなコンテナランタイムとの間の標準化されたインターフェース（API）です。これにより、Kubernetesは特定のコンテナランタイムに縛られることなく、複数のランタイムをサポートできます。

コンテナランタイムとしての役割の違い

Docker非推奨化の背景には、「コンテナランタイムとして求められる役割の違い」があります。

• Docker Engineの役割（人間向け）： Dockerは本来、人間がコマンドラインで直接操作してイメージをビルドしたり、ネットワークやボリュームを設定したりするためのリッチな機能を持っています。そのため、単にコンテナを動かすだけのエンジンとしては多機能で「重い」という側面がありました。
• CRI準拠ランタイムの役割（プログラム向け）： Kubernetesのノード上で求められるのは、「人間が操作するための機能」ではなく、「Kubernetesからの命令に従って高速かつ安全にコンテナを起動・停止する機能」です。現在代表的なランタイムである containerd や CRI-O は、この「実行」に特化しており、余分な機能を持たないため軽量でセキュリティが高いという特徴があります。

このように、ランタイムの役割を整理し、実行に特化した軽量なソフトウェアに置き換えるためのインターフェースがCRIなのです（出典：コンテナランタイム | Kubernetes）。

主要クラウドベンダーの動向と本番環境のベストプラクティス

KubernetesとDockerの違いを理解し、自社のシステムに適切に導入する上で、主要クラウドベンダーの動向は非常に重要な判断材料となります。

マネージドサービスにおけるランタイムの移行

主要なクラウドプロバイダーは、CRIに準拠したより軽量なランタイムへの移行を進めています。

• AWS EKS: Kubernetes 1.22以降でDockerが非推奨となり、デフォルトでcontainerdが使用されます。
• Azure AKS: バージョン1.19でDockerが廃止され、デフォルトでcontainerdへと移行しました。
• Oracle OKE: バージョン1.20でDockerが非推奨となり、デフォルトでCRI-Oが採用されています。

本番環境におけるKubernetesの普及率

大規模なシステムにおいて、Kubernetesは事実上の標準基盤として確固たる地位を築いています。Cloud Native Computing Foundation®（CNCF®）の2025年年次調査によると、コンテナユーザーの82%が本番環境でKubernetesを実行していることが明らかになりました。

この結果は、Kubernetesがクラウドネイティブな規模や安定性の共通基盤となるだけでなく、企業がAIワークロードを本番環境に投入する上で不可欠な役割を担っていることを示しています（出典：Kubernetes Established as the De Facto 'Operating System' for AI as Production Use Hits 82% in 2025 CNCF Annual Cloud Native Survey）。

開発と運用の役割分担

これらの動向を踏まえると、開発環境では引き続きDockerを使用して直感的にコンテナイメージを作成する一方で、本番のKubernetes環境ではcontainerdなどの軽量でパフォーマンスに優れたランタイムが稼働するという役割分担がより明確になりました。

こうしたモダンな開発手法を用いてスピーディーなプロダクト立ち上げを目指す場合は、MVP開発とは？新規事業の失敗リスクを下げるアジャイルな進め方と検証ポイント の記事も併せてご確認ください。また、プロジェクトのフェーズに合わせた最適なインフラ戦略を検討する際は、新規事業の立ち上げで失敗しない7つのプロセス｜実践フレームワークと成功手法 も参考になります。

Kubernetes環境のデプロイ自動化をさらに進めたい場合は、GitHub ActionsでCI/CDを自動化！開発を加速するワークフローと導入手順 も合わせてご覧ください。

まとめ

KubernetesとDockerは、コンテナ技術においてそれぞれ異なる役割を担う補完的なツールです。Dockerはコンテナイメージの作成とローカルでの実行に優れ、開発効率を高めます。一方、Kubernetesは多数のコンテナを大規模に管理・オーケストレーションするためのプラットフォームであり、本番環境での安定運用に不可欠です。

「Docker非推奨化」のニュースの真相は、Kubernetes 1.20でdockershimが非推奨化され、1.24で完全削除されたという内部ランタイム連携機能の廃止です。Dockerそのものが使えなくなったわけではなく、CRIの標準化により、Dockerで作成したイメージはOCI準拠であれば、Kubernetes上のcontainerdなどCRI準拠ランタイムで問題なく動作します。

このようにKubernetesとDockerの違いを正しく理解し、開発と運用で適材適所の使い分けを行うことが、現代のシステム開発におけるベストプラクティスと言えるでしょう。