結論：DockerとKubernetesは「どっちが良いか」を選ぶ競合ではありません。Dockerが1個のコンテナを作って動かす道具、Kubernetesがそのコンテナを何十個も複数サーバーで運用する道具で、実務では両方を併用します。 つまり「Docker vs Kubernetes」ではなく「Dockerで作ったものをKubernetesで運用する」が正しい関係です。
なぜ「どっち？」と混乱するのか
「Docker Kubernetes 違い」「Kubernetes と Docker どっち」で検索する人の多くは、2つが同じ土俵の競合製品だと思っています。でも実際は担当する仕事の層が違うので、比べても答えは出ません。
料理でたとえると分かりやすいです。
- Docker＝食材を1食分の弁当箱に詰める道具。アプリと、それを動かすのに必要な部品（ライブラリ・設定・OSの一部）を1つの箱＝コンテナにまとめて、どこでも同じように動かせるようにします。
- Kubernetes＝何百個もの弁当を、複数のキッチンに配り、足りなくなったら追加で作り、傷んだら作り直す配膳システム。たくさんのコンテナを複数サーバーに配置し、落ちたら再起動し、混んだら増やし、無停止で更新する――これを自動でやります。
弁当箱（Docker）があっても、大量配膳の仕組み（Kubernetes）にはなりません。逆に配膳システムだけあっても、中身の弁当は詰められません。だから併用します。
Dockerが何をする道具なのかは、Dockerとは ― 「どこでも同じ」を実現する箱 を読むのが早いです。読み物のあと、イメージとコンテナ ― 設計図と実体 や はじめてのコンテナ ― hello-world を動かす はブラウザでそのままコマンドを実行できます（無料・登録不要・環境構築なし）。
役割の違いを一枚で
| Docker | Kubernetes | |
|---|---|---|
| ひとことで | コンテナを作って動かす | コンテナをまとめて運用する |
| 担当する範囲 | 1個のコンテナ | 何十〜何百のコンテナ、複数サーバー |
| 代表コマンド | docker build / docker run | kubectl apply / kubectl get |
| 落ちたとき | 自分で docker start し直す | 自動で作り直す（自己修復） |
| 混んだとき | 手で docker run を増やす | 自動または宣言でスケール |
| 単位 | イメージ・コンテナ | Pod・Deployment・Service |
Dockerの docker build でコンテナの設計図（イメージ）を焼くところは Dockerfileとは ― イメージの設計図 で、複数サービスを1枚で定義する Compose は composeファイルとは でブラウザ実行しながら学べます。
Kubernetesは「Dockerだけでは足りない」から生まれた
コンテナを1個動かすだけなら docker run で十分です。問題は本番サービスの規模になったときです。
- コンテナが1つ落ちたら、誰かが気づいて手で立て直す？
- アクセスが増えたら、夜中でも手でコンテナを増やす？
- 新バージョンに更新するとき、サービスを止めずに差し替える？
これを人手でやり続けるのは現実的に不可能です。そこで「あるべき状態を宣言すれば、現実をそこへ合わせ続けてくれる」仕組みとして Kubernetes が使われます。この動機はまさに なぜオーケストレーションが必要か ― Dockerだけでは足りない で、続く Kubernetesとは ― 宣言的・自己修復・スケール が核心の考え方です。
Kubernetesコースは前半（第1章の全体像）は読み物で、そのあとはkubectlシミュレータで実際にコマンドを打って確認できます。たとえば kubectl の基本操作（apply/get/describe/logs/exec/delete） や、運用の主役 Deployment ― 宣言的にアプリを管理する主役、安定した宛先を作る Service ― 安定した宛先とロードバランス はブラウザで手を動かせます。
よくある誤解を整理する
「Kubernetesを使うならDockerはいらない？」 いいえ。Kubernetesが動かす中身は結局コンテナです。そのコンテナ（イメージ）を作るのは Docker（や同等のツール）の仕事です。作る＝Docker、運用する＝Kubernetes、と層で分かれています。
「小さなアプリでもKubernetesを使うべき？」 多くの場合は不要です。コンテナ数が少なく1台で足りるうちは Docker だけ、あるいは Docker Compose で十分です。落ちたら自動で復活させたい・大量にスケールしたい、という運用の悩みが出てから Kubernetes を検討するのが順当です。
「DockerとVMの違いは？」 これはまた別のテーマです。Kubernetesとの比較ではなく、仮想マシンとの比較を知りたい人は DockerとVM（仮想マシン）の違い を読んでください。
まず何から手を動かす？
順序はシンプルです。先にDocker（コンテナを作る側）、次にKubernetes（運用する側）。土台であるコンテナのイメージが分かっていないと、Kubernetesのオブジェクトは腹落ちしません。
- Dockerの入門記事 → Docker入門（ブラウザで動かす） で全体像とコマンドの流れをつかむ。
- Dockerコース で
run・build・composeをブラウザ実行。 - Kubernetesの入門記事 → Kubernetes入門 で用語（Pod・Deployment・Service）を整理。
- Kubernetesコース で
kubectl applyからデプロイまでを手を動かして確認。
次に読む
- Dockerとは ― 「どこでも同じ」を実現する箱（読み物）／はじめてのコンテナ hello-world（ブラウザ実行）
- なぜオーケストレーションが必要か／Kubernetesとは ― 宣言的・自己修復・スケール
- kubectl の基本操作／Deployment／Service（いずれもブラウザで実行）
- 関連記事：Docker入門／Kubernetes入門／DockerとVMの違い