初級では Kubernetes を「大量のコンテナを束ねる指揮者」と捉えました。中級では、その指揮者が使う 部品の名前 と、なぜ勝手に直り続けるのか＝宣言的管理 の中身を見ます。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
Kubernetes の世界は、いくつかの部品が層になってできています。
アニメーション『Kubernetesの自己修復とオーケストレーション』を開く
登場人物メモ:
- ※1 Pod — コンテナの最小単位。K8sが数える・並べる基本のかたまり
- ※2 ノード — Podを載せる1台のサーバ（物理でも仮想でもよい）
- ※3 レプリカ — 同じPodの複製。数を増減してスケールする
この部分をもっと深く（上級）
中級では Pod・Node・Service など「並べられる側」を見ました。上級では「並べる側」＝ コントロールプレーン の分業を見ます。
- API Server — すべての入口。宣言はここに届き、認証・検証を経て etcd に書かれる。各部品は直接会話せず、必ずAPI Server越しに状態をやり取りする
- etcd（※2） — 唯一の真実。望む状態も実状態もここに集約される。ここが壊れるとクラスタの記憶が失われるため、複数台で冗長化する
- スケジューラ — 行き先未定のPodを見つけ、どのノードに載せるか を決める
- コントローラマネージャ — Deploymentやレプリカ数などの調整ループを回す番人たちの集まり
- kubelet（※3） — 各ノード側の実行部隊。自分に割り当てられたPodを、コンテナランタイム（Docker／コンテナ 等）に指示して起動・監視する
つまり 頭脳（コントロールプレーン）が望む状態を決め、手足（kubelet）が各ノードで実現する。両者はAPI Serverとetcdを介してしか会話しない——この一本道が、状態の一貫性を守ります。
やさしく言うと（初級）
Kubernetes は、大量のコンテナを 自動で束ねて面倒を見る 仕組みです。オーケストラでたとえるなら、たくさんの演奏者（※1 コンテナ）を指揮する 指揮者 にあたります。
指揮者がやってくれるのは、ざっくり4つ。
- 配置 — どのサーバにどの箱を載せるかを決める
- 監視 — 箱がちゃんと動いているか見張る
- 復旧 — 落ちたら勝手に立て直す
- 増減 — 混んできたら増やし、暇なら減らす
人は「こうあってほしい」と伝えるだけ。あとの調整は指揮者に任せます。
登場人物メモ:
- ※1 コンテナ — アプリと環境を1つに詰めた箱。K8sが並べて動かす対象
- ※2 クラスタ — コンテナを載せるサーバ群を1つにまとめた集まり
仕事の流れ
- Deployment に 望む状態（例 この Pod を3個）を書く
- K8s が空いているノードへ Pod を 配置 する
- 実状態を絶えず見て、望む状態との差 を計算する
- 足りなければ起こし、余れば止めて、差をゼロに寄せ続ける
利用者からのアクセスは Service が受け、生きている Pod 群へ振り分けます。個々の Pod が入れ替わっても、入口は変わりません。
やさしく言うと（初級）
- 「この箱を3個動かしておいて」と あるべき状態を伝える
- K8s が空いているサーバへ 箱を配置 する
- 動き出したら ずっと見張る（落ちていないか・数は足りているか）
- 落ちたら 別の場所で立て直す、混んだら 数を増やす
ポイントは、命令を1回ずつ手で打つのではなく、ゴールを預けておく こと。指揮者がそのゴールに合わせ続けてくれます。
宣言的管理と自己修復
Kubernetes の核心は 宣言的管理 です。「どう起動するか（手順）」ではなく「どうあってほしいか（状態）」を書きます。
- K8s は 望む状態 と 実際の状態 を常に比べる
- ズレていれば、実状態を望む状態へ 寄せる（作る／消す）
- だから Pod が落ちても、ノードが壊れても、放っておいても元に戻る
この「常に比べて、ズレを埋める」動きは 調整ループ（reconcile loop）と呼ばれ、差がゼロになるまで、そしてゼロになった後も回り続けます。
アニメーション『Kubernetesの調整ループ（観測→差分→修正）』を開く
- 望む状態（宣言） — 「Podを3個保って」など、あってほしいゴールを書いたもの。手順ではなく状態を宣言する
- コントローラ — 望む状態と実状態を絶えず突き合わせ、差を埋める指揮役
- 実状態（クラスタ） — いま実際に動いているPod群。落ちたり増えたりで刻々と変わる
0 / 5
スケール も同じ理屈です。「レプリカ（※3）を3→10に」と宣言を書き換えるだけで、K8s が差を埋めて7個増やします。手順を打つのではなく、ゴールを更新する だけ——これが自動運用の正体です。
この部分をもっと深く（上級）
中級で「望む状態と実状態の差を埋める」と言いました。上級の核心は、それが 一度きりの操作ではなくループ だという点です。Kubernetesの各コントローラ（※1）は、こう回り続けます。
- 観測 — いま実際にどうなっているか（実状態）を読む
- 差分 — 望む状態（宣言）と実状態のズレを計算する
- 修正 — ズレを埋める操作を1歩だけ実行する
- 1へ戻る
アニメーション『Kubernetesの自己修復とオーケストレーション』を開く
この「観測→差分→修正」を絶え間なく回すことを reconciliation（調整） と呼びます。ポイントは 命令ではなく状態 を預ける点。「Podを3個作れ」ではなく「Podが3個ある状態を保て」と宣言するので、1個落ちれば次のループで差分が1になり、修正で1個作られて差が0に戻る。自己修復とは、この調整ループが淡々と差を埋め続けている姿 に他なりません。だから「特別な復旧処理」は存在せず、平常運転と復旧が同じ仕組みで行われます。
登場人物メモ:
- ※1 コントローラ — ある種類の望む状態を担当し、調整ループを回す番人
- ※2 etcd — クラスタの全状態を保存する一貫性のあるキー値ストア（唯一の真実）
- ※3 kubelet — 各ノードに常駐し、割り当てられたPodを実際に起動・監視する係
やさしく言うと（初級）
- 夜中でも自動復旧 — 人が気づく前に立て直すので、止まっている時間が短い
- 混雑に自動対応 — アクセスが増えたら箱を増やし、減ったら戻す
- サーバの空きを有効活用 — どこに載せるかを自動で最適化する
「数が少ないうち」は手作業でも回りますが、規模が大きくなるほど 指揮者の価値が効いてきます。
⚠️ うまくいかないとき
- 望む状態の書き間違い — レプリカ数や資源上限を誤ると、増えすぎ・足りずが起きる
- ノード不足 — 載せる先が満杯だと、Pod が待機のまま起動できない
- 状態を持つアプリ — Pod は使い捨て前提。DBのような消えて困るデータは外部へ預ける
- 入口の設計漏れ — Service を用意しないと、入れ替わる Pod に安定してつながれない
この部分をもっと深く（上級）
- etcd が単一障害点になる — 冗長化やバックアップを怠ると、クラスタの記憶ごと失う。真実の保管庫は最優先で守る
- readiness を設定しない更新 — 準備確認なしでローリングすると、起動途中のPodへ通信が流れ込み、更新中にエラーが噴く
- リソース要求（requests）の未設定 — スケジューラは空きを requests で判断するため、未設定だと過密配置になりノードごと共倒れしやすい
- 状態を持つアプリの安易な載せ替え — Podは使い捨て前提。DBのような消えて困るデータは外部ストレージへ預け、調整ループに作り直されても失わない設計にする
やさしく言うと（初級）
- むしろ大げさ — 箱が数個なら K8s は仕組みが重すぎることもある
- 設定ミスで増えすぎ — 「増やして」の指示を誤ると資源を食いつぶす
- 中身は自分で用意 — 指揮者は並べてくれるが、箱（コンテナ）自体は自分で正しく作る必要がある
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. Kubernetesの「宣言的管理」とは何を意味する？
問2. Podが増えたり入れ替わったりしてもアクセス先を安定させる役割はどれ？
問3. Kubernetesで「コンテナを載せる最小単位」を指すのはどれ？
問4. Deploymentの役割として正しいのはどれ？
問5. 稼働数をレプリカ3から10に増やしたいとき、中級本文が説明する正しいやり方はどれ？
問6. 載せる先のノードが満杯のとき、Podはどうなるか？
問7. 望む状態と実状態を常に比べ、ズレを埋め続けるKubernetesの中核動作を、日本語で何と呼ぶ？
問8. 同じPodの複製で、数を増減してスケールする単位を何と呼ぶ？（カタカナ）