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

概要 — まず全体をつかむ

コンテナは「アプリを箱ごと運んでどこでも同じに動かす」便利な道具でした。でも箱が数十・数百に増えると、どこに置くか・落ちていないか・混んでいないかを人の手で見張るのは無理があります。それを肩代わりするのが Kubernetes(K8s) です。

詳細 — 1段階ずつ追う

これは何をする係?

Kubernetes は、大量のコンテナを 自動で束ねて面倒を見る 仕組みです。オーケストラでたとえるなら、たくさんの演奏者(※1 コンテナ)を指揮する 指揮者 にあたります。

指揮者がやってくれるのは、ざっくり4つ。

  • 配置 — どのサーバにどの箱を載せるかを決める
  • 監視 — 箱がちゃんと動いているか見張る
  • 復旧 — 落ちたら勝手に立て直す
  • 増減 — 混んできたら増やし、暇なら減らす

人は「こうあってほしい」と伝えるだけ。あとの調整は指揮者に任せます。

登場人物メモ:

  • ※1 コンテナ — アプリと環境を1つに詰めた箱。K8sが並べて動かす対象
  • ※2 クラスタ — コンテナを載せるサーバ群を1つにまとめた集まり
この部分をもっと深く(中級

Kubernetes の世界は、いくつかの部品が層になってできています。

  • Pod(※1)— コンテナを載せる 最小単位。中に1つ以上のコンテナが入る
  • ノード(※2)— Pod を実際に載せる 1台のサーバ
  • クラスタ — ノードを束ねた サーバ群 全体
  • Deployment — 「この Pod を◯個保って」という あるべき状態の宣言
  • Service — 変わり続ける Pod 群に対する 安定した入口負荷分散つき)
アニメーション『Kubernetesの自己修復とオーケストレーション』を開く
コントロールプレーン(指揮者)望む状態と実状態の差を絶えず埋める=自己修復・スケールノードAPodを載せる1台のサーバノードBPodを載せる1台のサーバPodコンテナアプリの最小単位新しいPodコンテナ自己修復で起動Podコンテナアプリの最小単位Podコンテナアプリの最小単位別ノードに立て直す障害で停止Service安定した入口/負荷分散Podが入れ替わっても入口は変わらない指揮者が「望む状態」に実状態を寄せ続ける(落ちたら立て直し、混んだら増やす)

登場人物メモ:

  • ※1 Pod — コンテナの最小単位。K8sが数える・並べる基本のかたまり
  • ※2 ノード — Podを載せる1台のサーバ(物理でも仮想でもよい)
  • ※3 レプリカ — 同じPodの複製。数を増減してスケールする

仕事の流れ

  1. 「この箱を3個動かしておいて」と あるべき状態を伝える
  2. K8s が空いているサーバへ 箱を配置 する
  3. 動き出したら ずっと見張る(落ちていないか・数は足りているか)
  4. 落ちたら 別の場所で立て直す、混んだら 数を増やす

ポイントは、命令を1回ずつ手で打つのではなく、ゴールを預けておく こと。指揮者がそのゴールに合わせ続けてくれます。

この部分をもっと深く(中級
  1. Deployment に 望む状態(例 この Pod を3個)を書く
  2. K8s が空いているノードへ Pod を 配置 する
  3. 実状態を絶えず見て、望む状態との差 を計算する
  4. 足りなければ起こし、余れば止めて、差をゼロに寄せ続ける

利用者からのアクセスは Service が受け、生きている Pod 群へ振り分けます。個々の Pod が入れ替わっても、入口は変わりません。

指揮者がいてうれしい理由

  • 夜中でも自動復旧 — 人が気づく前に立て直すので、止まっている時間が短い
  • 混雑に自動対応 — アクセスが増えたら箱を増やし、減ったら戻す
  • サーバの空きを有効活用 — どこに載せるかを自動で最適化する

「数が少ないうち」は手作業でも回りますが、規模が大きくなるほど 指揮者の価値が効いてきます。

この部分をもっと深く(中級

Kubernetes の核心は 宣言的管理 です。「どう起動するか(手順)」ではなく「どうあってほしいか(状態)」を書きます。

  • K8s は 望む状態実際の状態 を常に比べる
  • ズレていれば、実状態を望む状態へ 寄せる(作る/消す)
  • だから Pod が落ちても、ノードが壊れても、放っておいても元に戻る

この「常に比べて、ズレを埋める」動きは 調整ループ(reconcile loop)と呼ばれ、差がゼロになるまで、そしてゼロになった後も回り続けます。

アニメーション『Kubernetesの調整ループ(観測→差分→修正)』を開く
望む状態(宣言)コントローラ実状態(クラスタ)
  • 望む状態(宣言)「Podを3個保って」など、あってほしいゴールを書いたもの。手順ではなく状態を宣言する
  • コントローラ望む状態と実状態を絶えず突き合わせ、差を埋める指揮役
  • 実状態(クラスタ)いま実際に動いているPod群。落ちたり増えたりで刻々と変わる
このループはずっと回り続けます。Podが落ちても、宣言を書き換えても、コントローラが差を見つけて実状態を望む状態へ寄せ直します。「▶ 再生」か「次へ」でどうぞ。
0 / 5

スケール も同じ理屈です。「レプリカ(※3)を3→10に」と宣言を書き換えるだけで、K8s が差を埋めて7個増やします。手順を打つのではなく、ゴールを更新する だけ——これが自動運用の正体です。

⚠️ うまくいかないとき

  • むしろ大げさ — 箱が数個なら K8s は仕組みが重すぎることもある
  • 設定ミスで増えすぎ — 「増やして」の指示を誤ると資源を食いつぶす
  • 中身は自分で用意 — 指揮者は並べてくれるが、箱(コンテナ)自体は自分で正しく作る必要がある
この部分をもっと深く(中級
  • 望む状態の書き間違い — レプリカ数や資源上限を誤ると、増えすぎ・足りずが起きる
  • ノード不足 — 載せる先が満杯だと、Pod が待機のまま起動できない
  • 状態を持つアプリ — Pod は使い捨て前提。DBのような消えて困るデータは外部へ預ける
  • 入口の設計漏れ — Service を用意しないと、入れ替わる Pod に安定してつながれない

理解度チェック

そのまま解けます(成績は保存されません)。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。

1. Kubernetes(K8s)を一言でいうと?

2. 動いていたコンテナが1つ落ちたとき、Kubernetesはどうする?

3. 指揮者(Kubernetes)がやってくれる4つの仕事に、含まれないのはどれ?

4. 利用者がKubernetesにする、基本の頼み方はどれ?

5. Kubernetesの「増減」の説明として正しいのはどれ?

6. コンテナが数個しかない場合について、本文が注意しているのはどれ?

7. コンテナを載せるサーバ群を1つにまとめた集まりを何と呼ぶ?(カタカナ)

8. Kubernetes の通称を、K・数字・s を組み合わせた略称で答えてください。