Kubernetes — 大量のコンテナを自動で束ねる指揮者

中級で「望む状態と実状態の差を埋める」と言いました。上級の核心は、それが 一度きりの操作ではなくループ だという点です。Kubernetesの各コントローラ（※1）は、こう回り続けます。

1. 観測 — いま実際にどうなっているか（実状態）を読む
2. 差分 — 望む状態（宣言）と実状態のズレを計算する
3. 修正 — ズレを埋める操作を1歩だけ実行する
4. 1へ戻る

この「観測→差分→修正」を絶え間なく回すことを reconciliation（調整） と呼びます。ポイントは 命令ではなく状態 を預ける点。「Podを3個作れ」ではなく「Podが3個ある状態を保て」と宣言するので、1個落ちれば次のループで差分が1になり、修正で1個作られて差が0に戻る。自己修復とは、この調整ループが淡々と差を埋め続けている姿 に他なりません。だから「特別な復旧処理」は存在せず、平常運転と復旧が同じ仕組みで行われます。

登場人物メモ:

• ※1 コントローラ — ある種類の望む状態を担当し、調整ループを回す番人
• ※2 etcd — クラスタの全状態を保存する一貫性のあるキー値ストア（唯一の真実）
• ※3 kubelet — 各ノードに常駐し、割り当てられたPodを実際に起動・監視する係

中級では Pod・Node・Service など「並べられる側」を見ました。上級では「並べる側」＝ コントロールプレーン の分業を見ます。

• API Server — すべての入口。宣言はここに届き、認証・検証を経て etcd に書かれる。各部品は直接会話せず、必ずAPI Server越しに状態をやり取りする
• etcd（※2） — 唯一の真実。望む状態も実状態もここに集約される。ここが壊れるとクラスタの記憶が失われるため、複数台で冗長化する
• スケジューラ — 行き先未定のPodを見つけ、どのノードに載せるか を決める
• コントローラマネージャ — Deploymentやレプリカ数などの調整ループを回す番人たちの集まり
• kubelet（※3） — 各ノード側の実行部隊。自分に割り当てられたPodを、コンテナランタイム（Docker／コンテナ 等）に指示して起動・監視する

つまり 頭脳（コントロールプレーン）が望む状態を決め、手足（kubelet）が各ノードで実現する。両者はAPI Serverとetcdを介してしか会話しない——この一本道が、状態の一貫性を守ります。

Podは作られた瞬間は「どのノードに載るか未定」です。スケジューラはこれを2段階で決めます。

• フィルタリング（絞り込み） — 載せられないノードを外す。CPU・メモリの空きが足りない、要求するラベルに合わない、汚れ（taint）を許容していない、などを弾く
• スコアリング（点数づけ） — 残ったノードに得点をつけ、いちばん高いノードを選ぶ。空きの多さや、Podの分散（1ノードに偏らせない）などを加味する

決まると、スケジューラはPodに「このノード」と書き込むだけ。実際に起動するのは、そのノードのkubelet です。ここでも「決める人」と「動かす人」が分かれているのがKubernetes流。だから同じ調整ループの発想で、スケジューリング済みでまだ起動していないPodも、次のループで自然に拾われます。

Podは使い捨てで、起動のたびにIPが変わります。では入れ替わる相手にどうやって安定して届くのか。ここは3層で成り立ちます。

• CNI — Podに実際のネットワーク（IP・経路）を配るプラグイン。ノードをまたいでも PodからPodへ直接届く フラットな網を作る
• Service — 変わり続けるPod群に 仮想の固定IP／名前 を1つ与える論理的な入口。中身のPodは入れ替わってよい
• kube-proxy — 各ノードで、Service宛ての通信を 生きているPodのどれかへ振り分ける 転送ルールを維持する

利用側はServiceの名前を呼ぶだけで、その裏で kube-proxy が 負荷分散 的に実Podへ配ります。Podが落ちて別IPで立ち直っても、Serviceという看板は不動——「安定した入口」の正体は、調整ループが常に最新のPod一覧を転送ルールへ反映し続けていること です。

新バージョンへの入れ替えも、宣言と調整ループで行われます。Deploymentはバージョンごとに ReplicaSet（レプリカ数を保つ番人）を持ち、更新は2つのReplicaSet間の綱引きとして進みます。

• ローリング更新 — 新ReplicaSetのPodを少しずつ増やし、旧ReplicaSetのPodを少しずつ減らす。常に必要数が生き続けるので 無停止で入れ替わる
• ヘルスの確認 — 新Podが「準備OK」（readiness）になってから次へ進む。準備できなければ更新は止まり、壊れたまま全台入れ替わる事故を防ぐ
• ロールバック — 旧ReplicaSetの定義は残っているので、宣言を前の版へ戻すだけで、同じ調整ループが逆向きに走り旧版へ復帰する

ここでも新しい命令を打つのではなく、望む状態（どの版を何個）を書き換えるだけ。段階的な入れ替えも切り戻しも、すべて差を埋める同じ原理の応用です。

• etcd が単一障害点になる — 冗長化やバックアップを怠ると、クラスタの記憶ごと失う。真実の保管庫は最優先で守る
• readiness を設定しない更新 — 準備確認なしでローリングすると、起動途中のPodへ通信が流れ込み、更新中にエラーが噴く
• リソース要求（requests）の未設定 — スケジューラは空きを requests で判断するため、未設定だと過密配置になりノードごと共倒れしやすい
• 状態を持つアプリの安易な載せ替え — Podは使い捨て前提。DBのような消えて困るデータは外部ストレージへ預け、調整ループに作り直されても失わない設計にする