Kubernetes — 宣言した数に、勝手に戻し続ける

Kubernetesを一言でいえば「現場監督」です。あなたがやるのは「このアプリを3つ動かしておいて」と宣言することだけ。どのサーバーに置くか、落ちたらどうするかは監督が勝手に面倒をみます。

大事なのは、Kubernetesに渡すのが手順ではなく「あるべき状態」だということ。監督は宣言された数と現実の数を見比べ、違っていれば埋めにいくことをひたすら繰り返します。図1でPodを壊したりノードを落としたりして、勝手に元へ戻る様子を見てください。

Pod — 置いたり消したりする最小のかたまり

Kubernetesが動かす単位はPodです。中に1つ(たまに複数)のコンテナが入った、1つの箱だと思ってください。図1の四角ひとつがPodです。

Podは直せません。調子が悪ければ捨てて新しく作るのがKubernetesのやり方です。だからPodには毎回ちがうIPが振られ、名前も変わります。「同じPodが復活した」のではなく、いつも別のPodが新しく生まれています。

スケジューラ — どこに置くかを決める係

新しいPodができたとき、どのノードに載せるかを決めるのがスケジューラです。空きメモリやCPU、置いてはいけない条件などを見て選びます。図1でPodを増やすと、1台に固めず散らして置かれるのが分かります。

どこにも置けなければ、PodはPending(保留)のまま止まります。図1でノードを全部止めたり、宣言を7個に増やしたりすると、置き場所を探しているPodが下の欄に溜まります。これはエラーではなく「空きが出るのを待っている」状態です。

セルフヒーリング — 直すのではなく、数を合わせ続ける

Kubernetesの心臓部は「宣言された状態と現実を見比べて、差を埋める」という一本のループです。これを調整ループ(reconciliation loop)と呼び、止まることなく回り続けています。

図1でPodを1つ壊すと、すぐには何も起きません。少し遅れて新しいPodが生まれます。監督は「壊れた」というイベントに反応しているのではなく、次に数え直したときに足りないことに気づいて埋めているからです。ノードごと落としたときに残った2台へ載せ直されるのも、まったく同じ理屈です。

この考え方の強さは、失敗の種類を問わないことにあります。落ちた理由がクラッシュでもノード故障でも誰かの削除でも、監督がやることは「足りないから作る」の一つだけです。

まとめ

Kubernetesは「あるべき数を宣言すると、現実をそこへ寄せ続ける」仕組みです。Podは使い捨て、置き場所はスケジューラ任せ、そして復旧は見比べて埋めるだけ。図1でどれだけ壊しても数が戻るのは、監督が手順ではなく状態を見ているからです。