Kubernetes の仕組みを図で整理する

公開日 2026.9.15

カテゴリ：Kubernetes
タグ：Kubernetes,学習メモ

Kubernetes の仕組みを、図で見返せるようにまとめたページ。

クラスタのアーキテクチャ

クラスタのアーキテクチャ

Kubernetes のクラスタは、クラスタ全体を管理する Control Plane と、Pod を実際に動かす Node でできている。ここでは、コンポーネント同士の関係と、代表的な処理の流れを図にする。

コンポーネントの関係

クラスタを構成するコンポーネントと、それぞれが何とつながっているかの図。

凡例:

点線の矢印: watch（変化を購読して読み取る）
実線の矢印: 書き込み・依頼

図を描画しています…

図から読み取れること:

Control Plane の中も、Node と Control Plane の間も、線はすべて kube-apiserver につながる形。公式ドキュメントでの呼び名は「hub-and-spoke」（ハブ・アンド・スポーク）の API パターン
etcd を読み書きするのは kube-apiserver だけ。etcd へのアクセスはクラスタの root 権限に等しいため、理想的には API サーバーだけに限定するものとされている
登場人物は2種類
- 自分から watch しに行く側: kube-scheduler、各コントローラー、kubelet、kube-proxy
- 頼まれて動く側: container runtime（kubelet から CRI で依頼される）、CNI プラグイン（container runtime から呼ばれる）

参考（公式ドキュメント）:

各コンポーネントの担当

登場人物ごとに、何を見て、どう判断し、どこに何をするのかをまとめた表。

登場人物	いる場所	何を見ているか	どう判断するか	どこに何をするか
人間（kubectl）	クラスタの外	—	あるべき状態を決める	kube-apiserver にリソースの定義（YAML）を送る
kube-apiserver	Control Plane	届いたリクエスト	認証・認可・Admission 制御を通過するか	etcd に保存し、watch しているクライアントに変更を届ける
etcd	Control Plane	—	過半数（クォーラム）が合意したら更新を確定	クラスタの全データを保存する
kube-scheduler	Control Plane	Node が割り当てられていない Pod	フィルタリング → スコアリング	選んだ Node を Pod に割り当てる（binding）
Deployment コントローラー	Control Plane（kube-controller-manager）	Deployment	Pod テンプレートに合う ReplicaSet があるか	ReplicaSet を作り、数を段階的に調整する
ReplicaSet コントローラー	Control Plane（kube-controller-manager）	ReplicaSet と Pod	Pod の数が `replicas` と一致しているか	Pod のオブジェクトを作る・消す
Node コントローラー	Control Plane（kube-controller-manager）	Node の状態（kubelet のハートビート）	既定 50 秒以上、報告が途絶えていないか	Node の `Ready` を `Unknown` にし、taint を付ける
taint-eviction コントローラー	Control Plane（kube-controller-manager）	Node の taint	Pod がその taint を許容する時間（既定 5 分）を過ぎたか	その Node の Pod を退避（削除）する
EndpointSlice コントローラー	Control Plane（kube-controller-manager）	Service と Pod	Service の selector に合う Pod はどれか	EndpointSlice（Pod の IP と状態の一覧）を更新する
kubelet	各 Node	自分の Node に割り当てられた Pod	Pod のコンテナが動いていて正常か	container runtime にコンテナの起動・停止を依頼し、状態を報告する
container runtime	各 Node	—（kubelet から CRI で依頼される）	—	イメージを取得してコンテナを動かす。CNI プラグインを呼ぶ
CNI プラグイン	各 Node	—（container runtime から呼ばれる）	—	Pod に IP を割り当て、Pod 同士が通信できるようにする
kube-proxy	各 Node	Service と EndpointSlice	Service 宛ての通信をどの Pod に届けるか	Node に転送ルール（iptables / nftables など）を書く

参考（公式ドキュメント）:

kubectl apply から Pod が動くまで

replicas: 3 の Deployment を kubectl apply したときの流れ。図には Pod 3つのうち1つ分だけを描いている。残りの2つも同じ流れで、それぞれが割り当てられた Node の kubelet によって起動される。

図を描画しています…

図から読み取れること:

ReplicaSet コントローラーが作るのは Pod の「オブジェクト」（etcd に保存される定義）で、この時点ではコンテナは動いていない。コンテナを起動するのは、割り当て先の Node の kubelet
どのコンポーネントも相手に直接命令せず、kube-apiserver を通じて変化を受け取り、自分の担当を進める形

参考（公式ドキュメント）:

Node が落ちたとき

Node 1 が落ちてから、そこにいた Pod の代わりが Node 2 で動き出すまでの流れ。時間はいずれも既定値。

図を描画しています…

図から読み取れること:

Pod が Node 1 から Node 2 へ移動するのではなく、古い Pod が削除され、UID の異なる新しい Pod が作られる流れ。公式ドキュメントにも、同じ Pod が別の Node に「再スケジュール」されることはないと書かれている
50 秒は kube-controller-manager の node-monitor-grace-period、5 分は Pod に自動で付く tolerationSeconds=300 の既定値。5 分のほうは Pod ごとに変更可能
通信が途絶えただけで Node 1 自体が動いている場合、削除の決定が kubelet に届くまで、古い Pod が Node 1 で動き続けることもある
taint による Pod の退避は、v1.29 で Node コントローラーから taint-eviction コントローラーに分離された処理

参考（公式ドキュメント）:

リソース同士の関係

コンポーネントではなく、コンポーネントが読み書きしている「リソース」同士の関係を表したクラス図。

図を描画しています…

図から読み取れること:

Deployment は Pod テンプレートが更新されるたびに新しい ReplicaSet を作り、新旧の ReplicaSet の数を少しずつ入れ替える（ローリングアップデート）
Pod がスケジュールされるのは一生に一度だけ。割り当てられた Node は後から変わらない
EndpointSlice は、Service と Pod を結びつけるためのオブジェクト

参考（公式ドキュメント）:

Kubernetes の仕組みを図で整理する

contents

クラスタのアーキテクチャ

コンポーネントの関係

各コンポーネントの担当

kubectl apply から Pod が動くまで

Node が落ちたとき

リソース同士の関係

Author