初級では Kubernetes を「大量のコンテナを束ねる指揮者」と捉えました。中級では、その指揮者が使う 部品の名前 と、なぜ勝手に直り続けるのか＝宣言的管理 の中身を見ます。
中級の解説は準備中のため、中級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
Kubernetes の世界は、いくつかの部品が層になってできています。
アニメーション『Kubernetesの自己修復とオーケストレーション』を開く
登場人物メモ:
- ※1 Pod — コンテナの最小単位。K8sが数える・並べる基本のかたまり
- ※2 ノード — Podを載せる1台のサーバ（物理でも仮想でもよい）
- ※3 レプリカ — 同じPodの複製。数を増減してスケールする
仕事の流れ
- Deployment に 望む状態（例 この Pod を3個）を書く
- K8s が空いているノードへ Pod を 配置 する
- 実状態を絶えず見て、望む状態との差 を計算する
- 足りなければ起こし、余れば止めて、差をゼロに寄せ続ける
利用者からのアクセスは Service が受け、生きている Pod 群へ振り分けます。個々の Pod が入れ替わっても、入口は変わりません。
宣言的管理と自己修復
Kubernetes の核心は 宣言的管理 です。「どう起動するか（手順）」ではなく「どうあってほしいか（状態）」を書きます。
- K8s は 望む状態 と 実際の状態 を常に比べる
- ズレていれば、実状態を望む状態へ 寄せる（作る／消す）
- だから Pod が落ちても、ノードが壊れても、放っておいても元に戻る
この「常に比べて、ズレを埋める」動きは 調整ループ（reconcile loop）と呼ばれ、差がゼロになるまで、そしてゼロになった後も回り続けます。
アニメーション『Kubernetesの調整ループ（観測→差分→修正）』を開く
- 望む状態（宣言） — 「Podを3個保って」など、あってほしいゴールを書いたもの。手順ではなく状態を宣言する
- コントローラ — 望む状態と実状態を絶えず突き合わせ、差を埋める指揮役
- 実状態（クラスタ） — いま実際に動いているPod群。落ちたり増えたりで刻々と変わる
0 / 5
スケール も同じ理屈です。「レプリカ（※3）を3→10に」と宣言を書き換えるだけで、K8s が差を埋めて7個増やします。手順を打つのではなく、ゴールを更新する だけ——これが自動運用の正体です。
⚠️ うまくいかないとき
- 望む状態の書き間違い — レプリカ数や資源上限を誤ると、増えすぎ・足りずが起きる
- ノード不足 — 載せる先が満杯だと、Pod が待機のまま起動できない
- 状態を持つアプリ — Pod は使い捨て前提。DBのような消えて困るデータは外部へ預ける
- 入口の設計漏れ — Service を用意しないと、入れ替わる Pod に安定してつながれない
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. Kubernetesの「宣言的管理」とは何を意味する？
問2. Podが増えたり入れ替わったりしてもアクセス先を安定させる役割はどれ？
問3. Kubernetesで「コンテナを載せる最小単位」を指すのはどれ？
問4. Deploymentの役割として正しいのはどれ？
問5. 稼働数をレプリカ3から10に増やしたいとき、中級本文が説明する正しいやり方はどれ？
問6. 載せる先のノードが満杯のとき、Podはどうなるか？
問7. 望む状態と実状態を常に比べ、ズレを埋め続けるKubernetesの中核動作を、日本語で何と呼ぶ？
問8. 同じPodの複製で、数を増減してスケールする単位を何と呼ぶ？（カタカナ）