Kubernetes のアーキテクチャを説明してください：control plane と worker node、およびそれらのコンポーネント。

Question

IT Interview Practice · Accepted Answer

Kubernetes cluster には 2 種類のマシンがあります。**control plane**（意思決定を行い状態を保存する「頭脳」）と、**worker node**（あなたの Pod が実際に動く場所）です。それぞれに、明確に定義された少数のコンポーネントがあります。

## 全体像

```text
┌──────────────── CONTROL PLANE (the brain) ────────────────┐
│                                                            │
│   kube-apiserver ── the front door; ALL comms go through it│
│        │                                                   │
│   etcd ───────── key-value store: the cluster's SOURCE OF  │
│                  TRUTH (all objects & desired state)       │
│   kube-scheduler ── decides WHICH node a new Pod runs on   │
│   controller-manager ── runs control loops (reconcilers)   │
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pods (your apps) │ │  └ Pods (your apps) │
└─────────────────────┘ └─────────────────────┘
```

## control plane のコンポーネント

```text
kube-apiserver        The single entry point. Exposes the REST API; validates &
                      persists objects to etcd. kubectl, controllers, and kubelets
                      all talk ONLY to the apiserver.
etcd                  Distributed, consistent key-value store. Holds the ENTIRE
                      cluster state (desired + current). Lose etcd = lose the cluster.
kube-scheduler        Watches for Pods with no node assigned and picks the best node
                      (based on resource requests, affinity, taints, etc.).
kube-controller-      Runs the control loops: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, etc. Each loop drives actual → desired.
cloud-controller-     (On cloud) integrates with the provider: load balancers, routes,
manager               node lifecycle.
```

## worker node のコンポーネント

```text
kubelet          The node agent. Talks to the apiserver, starts/stops containers via
                 the runtime, and reports Pod & node status. It makes the node's
                 reality match the Pods assigned to it.
kube-proxy       Programs the node's networking (iptables/IPVS) so that Service virtual
                 IPs are load-balanced to the right Pod endpoints.
container runtime The software that actually runs containers (containerd, CRI-O).
```

## 「kubectl apply」がシステムをどう流れるか

```text
1. kubectl → kube-apiserver: "I want a Deployment with 3 replicas"
2. apiserver validates & writes the object to etcd
3. controller-manager (deployment→replicaset controller) sees it, creates 3 Pod objects
4. scheduler sees 3 unassigned Pods, assigns each to a node (writes back via apiserver)
5. each node's kubelet sees its Pods, tells the runtime to pull images & start containers
6. kube-proxy wires up Service networking so traffic reaches the new Pods
Everything is a WATCH + RECONCILE loop mediated by the apiserver.
```

```bash
kubectl get nodes                 # ノードを一覧表示（control-plane + worker）
kubectl get pods -n kube-system   # control-plane / システムのコンポーネントを見る
kubectl get componentstatuses     # 中核の control-plane 部品の健全性
```

## なぜ重要なのか

control plane と worker node の分担 — そして各コンポーネントの役割 — を理解することは、Kubernetes をブラックボックスから、考察し運用できるシステムへと変えるものであり、中級以上のエンジニアにとって核心的な知識です。**control plane** は意思決定を行う頭脳です。**kube-apiserver** はあらゆるコンポーネントとユーザーが通信する唯一の玄関口であり、**etcd** は cluster 全体の状態を保持する一貫性のある key-value ストアで唯一の真実の源です（失えば cluster を失います）。**scheduler** は各新規 Pod がどのノードに着地するかを決め、**controller-manager** は実際の状態を望ましい状態へ継続的に駆動する reconciliation ループを走らせます。各 **worker node** では、**kubelet** がノードのコンテナを割り当てられた Pod に一致させるエージェントであり、**kube-proxy** は Service の仮想 IP を正しい Pod へルーティングさせるネットワーキングを構成し、**container runtime**（containerd、CRI-O）が実際にコンテナを動かします。1 つの `kubectl apply` がこのシステムをどう流れるか — apiserver から etcd へ、controller がオブジェクトを作成し、scheduler が Pod を配置し、kubelet がコンテナを起動し、kube-proxy がネットワーキングを配線する、すべてが watch-and-reconcile ループとして — を見ることで、プラットフォームの背後にある優雅で一貫した設計が見えてきます。この思考モデルこそ、Pod が Pending で詰まっている理由（scheduler）、cluster が応答しない理由（apiserver/etcd）、Service がルーティングしない理由（kube-proxy）をデバッグするために必要なものであり、実際の cluster を運用しトラブルシュートするうえで不可欠にします。

全体像

control plane のコンポーネント

worker node のコンポーネント

「kubectl apply」がシステムをどう流れるか

なぜ重要なのか

関連する質問