🧐
なぜKubernetesが必要なのか？Dockerだけではダメ？K8sとDockerの扱うケース比較
最近のWeb開発やマイクロサービスでは「Docker」や「Kubernetes」の名前が頻出します。
でも、こう思ったことはありませんか？
「Dockerで動いてるならそれでよくない？Kubernetesって複雑じゃない？」
「KubernetesとDockerの違いあまり良く分かってないし、、」
本記事では、Dockerだけでは解決できない運用課題と、それをKubernetes（K8s）がどのように補うのかを、初学者向けにわかるように解説します。
Dockerのすごいところ
まずはDockerの利点をおさらいします。
- 環境依存をなくせる（どこでも同じ環境で動く）
-
docker buildだけで簡単に環境構築 - 本番デプロイもイメージ1つで管理可能
簡単にWebアプリを起動出来る（例）
docker run -d -p 8000:8000 my-app
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
Dockerだけでは限界もある
しかし、実際の開発・運用現場では次のような課題に直面します。
| 課題 | Dockerだけでは… |
|---|---|
| スケーリング | 手動で複数コンテナ立ち上げが必要 |
| 障害対応 | サーバーが落ちたら自分で再起動 |
| ロードバランシング | nginxなどの構成が複雑に |
| 管理 | どのコンテナがどこで動いてるか追いづらい |
| 保守性 | スクリプトがどんどん増える |
Kubernetes（K8s）の存在
Kubernetesは、大量のDockerコンテナを自動で管理・運用するための仕組みです。
Kubernetesが解決してくれること
| Kubernetesができること | Dockerだけでは？ |
|---|---|
| 自動スケーリング | 手動で docker run するしかない |
| 自動再起動 | 障害発生時に対応が必要 |
| サービスディスカバリ | IPアドレスやポート番号の手動管理 |
| コンテナの配置管理 | どのホストで動かすか自分で決める必要あり |
| 構成のコード化 | スクリプトや手作業で対応が必要 |
実際のユースケース
ECサービス（例）
- セール時にアクセス急増
- オートスケーリングでPodを自動的に増やす
- 決済・商品表示などをマイクロサービスで分離
開発チーム
- 複数チームがそれぞれサービスを担当
- ネームスペースで環境ごとに分離
- HelmやGitOpsで効率的にデプロイ
Kubernetesの基本構成（ざっくり）
| 用語 | 説明 |
|---|---|
| Pod | コンテナの最小単位（1つまたは複数のコンテナ） |
| Deployment | Podの数や更新の制御（リリース管理） |
| Service | 外部アクセス用の窓口（ロードバランサ） |
| Namespace | チームや環境の分離（dev / prodなど） |
Docker vs Kubernetes ではない
ここで重要なのは、「DockerかKubernetesか」という対立構造ではない、ということです。両者は役割が違う、協力関係にあります。
Docker: アプリケーションを動かすための「コンテナエンジン」。いわば、荷物（アプリ）を積むための高性能なコンテナそのもの。
Kubernetes: そのコンテナを管理・運用するための「オーケストレーションツール」。たくさんのコンテナ（荷物）を、世界中の空港（サーバー）へ効率よく、安全に、自動で配備し続ける巨大な物流システム。
Kubernetesは、コンテナを動かすエンジンとしてDocker（containerdのような他のコンテナランタイム）を利用します。両者は最高のパートナーでもあります。
Dockerだけでいい？Kubernetes使うべき？ （IMOです）
| 条件 | Kubernetesが必要？ |
|---|---|
| 小規模なアプリ1つ | ❌ Dockerで十分 |
| 3つ以上のコンテナ構成 | ⚠ docker-compose or Kubernetes |
| アクセスが変動する | ✅ オートスケーリングが便利 |
| SLA（安定稼働）が求められる | ✅ 自己修復が重要 |
| チーム開発＆マイクロサービス構成 | ✅ 環境分離・サービス管理に最適 |
結論
Dockerは「アプリを簡単に動かすためのツール」
Kubernetesは「そのアプリ群を大規模・自動で管理するための仕組み」
| Dockerが得意な領域 | Kubernetesが得意な領域 |
|---|---|
| 小規模開発 | 本番運用、スケーリング、大規模運用 |
| 単体アプリ | マイクロサービス、複数環境の統合管理 |
| 手動で十分な構成 | 自動化・監視・復旧が必要な構成 |
Discussion