【比較】クラスタ・ノード・ポッド（Kubernetes）の違い¶
概要¶
Kubernetes 入門でまず混乱するのが「クラスタ」「ノード」「ポッド（Pod）」の関係です。これらは対等な選択肢ではなく、入れ子の包含関係にあります。Kubernetes 公式ドキュメントの定義に沿うと、クラスタ ⊃ ノード ⊃ ポッド ⊃ コンテナ という階層です。
クラスタは Kubernetes システム全体（コントロールプレーン＋ワーカーノード群）を指します。ノードはコンテナ化アプリを実行する「マシン」（仮想／物理）で、すべてのクラスタは少なくとも 1 つのワーカーノードを持ちます。ポッドは Kubernetes で作成・管理できる最小のデプロイ単位で、1 つ以上のコンテナをネットワーク・ストレージごとまとめた論理ホストです。「何を、どの粒度で操作するのか」を取り違えると、kubectl の操作対象や障害の切り分けで迷うため、この 3 階層を最初に押さえます。
例えるなら：データセンター・サーバー・アプリのプロセス群¶
- クラスタ … 1 つの「データセンター」全体。受付・配車を司る管理棟（コントロールプレーン）と作業棟（ノード群）を含む。
- ノード … その中の 1 台の「サーバーマシン」。実際に仕事を実行する箱。
- ポッド … サーバー上で一緒に動く「アプリの最小ユニット」。同じ住所（IP）を共有する 1〜複数のプロセス（コンテナ）の組。
詳細比較¶
| 比較軸 | クラスタ (Cluster) | ノード (Node) | ポッド (Pod) |
|---|---|---|---|
| 何か | Kubernetes システム全体 | ワークロードを実行するマシン（仮想/物理） | 作成・管理できる最小のデプロイ単位 |
| 包含関係 | ノード群を含む（最上位） | ポッド群をホストする（中間） | 1 つ以上のコンテナを含む（最小） |
| 構成要素 | コントロールプレーン＋ワーカーノード | kubelet / kube-proxy / コンテナランタイム | 共有ネットワーク・ストレージ＋コンテナ群 |
| 主な役割 | クラスタ全体の状態を統括 | コントロールプレーンに管理され Pod を実行 | コンテナを「論理ホスト」としてまとめて実行 |
| ライフサイクル | 長命（基盤として継続） | 比較的長命（追加・故障で増減） | エフェメラル（使い捨て・再生成前提） |
| 最小数 | 1（コントロールプレーン必須） | 少なくとも 1 つのワーカーノード | 0 個以上（ワークロードに応じ動的に増減） |
| 通常の作成方法 | kubeadm / マネージド K8s（EKS/GKE/AKS 等） | ノード追加（自己登録が推奨） | 直接ではなく Deployment 等のワークロード経由が通常 |
| 同一ポッド内の共有 | （該当せず） | （該当せず） | IP・ポート空間・IPC を共有、localhost で相互通信可 |
補足：コントロールプレーンとワーカーの区別は論理的な役割分担であり、開発用の単一ノード構成などではコントロールプレーンも同じノード上で動く。
よくある誤解¶
- 誤解1：「ポッド＝コンテナで、同じもの」 — 違います。ポッドはコンテナの上位概念で、1 つ以上のコンテナを「共有ストレージ・共有ネットワークを持つ論理ホスト」としてまとめた単位です。公式定義でも「ポッドは作成・管理できる最小のデプロイ単位」であり、Kubernetes が直接管理するのはコンテナではなくポッドです。1 ポッド 1 コンテナが最多ですが、サイドカー等で複数コンテナを束ねることもあります。
- 誤解2：「ノードとポッドは同レベルの選択肢」 — 階層が違います。ノードは「マシン」、ポッドは「その上で動く最小デプロイ単位」で、ノードがポッドをホストします（公式：「ワーカーノードが Pod をホストし、コントロールプレーンがノードと Pod を管理する」）。「ノードかポッドか」で迷う場面は通常ありません。
- 誤解3：「クラスタ＝ノードと同義」 — クラスタはノードを含む全体です。コントロールプレーン（kube-apiserver / etcd / kube-scheduler / kube-controller-manager）とワーカーノード群を合わせたものがクラスタであり、ノード 1 台ではありません。
- 誤解4：「ポッドは安定して存在し続ける」 — ポッドはエフェメラル（使い捨て）です。削除・実行完了・退避・ノード障害で消え、再生成されると別の IP・別のポッドになります。だからこそ直接作らず Deployment / StatefulSet / Job / DaemonSet 経由で複製・自己修復させ、Service で安定したアクセス先を与えます。
実務での選び分け¶
「どれを使うか」ではなく「何を操作・確認するか」で層を選びます。
- アプリを動かす／止める／スケールする → ポッド層（実体は Deployment 等のワークロード）。
kubectl get pods、レプリカ数の調整。 - マシンのリソース不足・障害・メンテ → ノード層。
kubectl get nodes、ノードの容量・NotReady・drain/cordon。 - クラスタ全体の構成・権限・コンポーネント障害 → クラスタ層。コントロールプレーン（API サーバ／etcd／スケジューラ）、RBAC、Namespace。
- 障害切り分けの軸：「特定アプリだけ落ちる＝ポッド/ワークロード」「あるマシン上の全 Pod が不調＝ノード」「全体がおかしい・API が応答しない＝コントロールプレーン（クラスタ）」と層で分ける。
- 設計の軸：1 ポッドに詰め込まず「密結合でライフサイクルを共有するものだけ同一ポッド（サイドカー等）」「独立スケールしたいものは別ポッド・別 Deployment」。
ひとことまとめ¶
クラスタ ⊃ ノード ⊃ ポッド ⊃ コンテナ の入れ子。クラスタは Kubernetes 全体、ノードは実行マシン、ポッドは最小デプロイ単位（共有ネットワークを持つコンテナの組でエフェメラル）。並列の選択肢ではなく階層として捉えるのが理解の起点です。
出典・参考¶
- Kubernetes 公式ドキュメント「Kubernetes Components」（クラスタはコントロールプレーンとワーカーノードで構成。すべてのクラスタは少なくとも 1 つのワーカーノードを持ち、ワーカーノードが Pod をホストし、コントロールプレーンがノードと Pod を管理する）: https://kubernetes.io/docs/concepts/overview/components/
- Kubernetes 公式ドキュメント「Nodes」（Kubernetes はコンテナを Pod に入れて Node 上で動かす。Node は仮想／物理マシンで、各 Node はコントロールプレーンに管理され Pod を動かすサービスを持つ）: https://kubernetes.io/docs/concepts/architecture/nodes/
- Kubernetes 公式ドキュメント「Pods」（Pod は作成・管理できる最小のデプロイ単位。共有ストレージ・ネットワークを持つ 1 つ以上のコンテナの組。エフェメラルで、通常は Deployment 等のワークロード経由で作成）: https://kubernetes.io/docs/concepts/workloads/pods/