本記事は、非エンジニアである筆者がKubernetesを学習する中でのアウトプット（備忘録）です。
なお、記事の執筆にあたり生成AIも活用し調査のうえ記載していますが、万が一誤りがあればご指摘いただけると幸いです。

前回は、Podという「住所不定の屋台」に対して、常に同じ入口を提供する「Service（固定の窓口）」について学びました。
※前回の記事:「【備忘】非エンジニアによるKubernetes学習アウトプット③（Serviceについて）」

Serviceのおかげで、お客さんは迷わず屋台にたどり着けるようになりました。
しかし、まだ大きな問題が残っています。

「もし屋台（Pod）が火事で全焼したら、誰が新しい屋台を用意するの？」
「お客さんが急増した時、誰が屋台を増やしてくれるの？」

人間が24時間張り付いて監視するのは不可能です。
そこで登場するのが、ReplicaSet（レプリカセット） と Deployment（デプロイメント） という2人の強力な「管理人」です。

1. 管理人がいないとどうなる？（Pod単体の限界）

これまで学んだ「Pod」は、実はとても弱い存在です。
「作れ」と言われれば作られますが、エラーで停止したり、削除されたりしても、自力で復活することはありません。

障害時: サーバーがダウンしたら、その上のPodも消えて終わり。
更新時: アプリのバージョンアップをするには、手動で古いPodを消して新しいPodを作る必要がある。

これでは本番運用はできません。そこで、「指定した状態を維持し続ける」 仕組みが必要になります。

2. ReplicaSet：【現場監督】（数を維持するスペシャリスト）

まず登場するのが ReplicaSet（レプリカセット） です。
この機能の役割はシンプルかつ強力です。
「指定された数のPod（レプリカ）を絶対に維持する」ことです。

ReplicaSetの仕事：

数の維持: 「屋台を常に3つ出せ」と言われたら、何があっても3つを維持します。
自動復旧（セルフヒーリング）: もし1つのPodが故障して消えたら、ReplicaSetは即座にそれを検知し、自動で新しいPodを作成して補充します。

これがKubernetesの最大のメリットの一つ、「自動復旧（Self-Healing）」の正体です。

3. Deployment：【総司令官】（進化と戦略を担う）

ReplicaSetは「数を守る」ことには長けていますが、「アプリのバージョンアップ（たい焼きを、あんこ味からクリーム味に変える）」のような変化への対応は苦手です。

そこで、私たちが普段扱うメインの管理人が Deployment（デプロイメント） です。
DeploymentはReplicaSetの上司にあたり、より高度な管理を行います。

Deploymentの役割：

ReplicaSetの管理: Deploymentは直接Podを作らず、部下であるReplicaSetに指示を出します。
ローリングアップデート（無停止更新）:
- 「バージョン1」のPodを少しずつ減らしながら、「バージョン2」のPodを少しずつ増やしていく更新方法です。
- これにより、サービスを止めることなくアプリを更新できます。
ロールバック（切り戻し）:
- 更新後に不具合が見つかった場合、コマンド一つで「前のバージョンに戻せ！」と指示し、即座に復旧できます。

関係性のイメージ

Deployment（司令官）: 「新しいクリーム味の屋台へ、徐々に切り替えろ！」と指示。
ReplicaSet（現場監督）: 「了解！古い屋台を1つ減らして、新しい屋台を1つ増やします！」と実行。
Pod（作業員）: 実際に動く。

※DeploymentとReplicaSetの関係図（by Gemini)

4. 実際の動きを見てみる（実践）

言葉だけでは難しいので、実際にどう動くのか、定義ファイル（マニフェスト）の例で見てみます。

Deploymentを作る

私たちが書くのは、以下のような「Deployment」の指示書だけです。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
spec:
  replicas: 3        # 「常に3つ起動しておけ！」という指示
  selector:
    matchLabels:
      app: nginx
  template:          # ここから下がPodの設計図
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2 # Nginxのバージョン1.14を使う

これをKubernetesに渡すと…

Deploymentが作られる。
DeploymentがReplicaSetを作る。
ReplicaSetがPodを3つ作る。

という連鎖が自動で起きます。

もしバージョンアップしたくなったら？

上記の image: nginx:1.14.2 を 1.15 に書き換えて適用するだけです。
するとDeploymentは、**「新しいバージョンのための新しいReplicaSet」**を作成し、古いReplicaSetから新しいReplicaSetへと、Podを徐々に移動させてくれます。

まとめ

Podは一人では生きていけない（すぐ死ぬし、蘇らない）
ReplicaSetは**「現場監督」**。Podの数を監視し、減ったら即座に補充する（自動復旧）
Deploymentは**「総司令官」**。ReplicaSetを操り、アプリの更新（アップデート）や切り戻し（ロールバック）を無停止で行う
私たちは通常、ReplicaSetを直接触らず、Deploymentを通じて指示を出す

次回は、「Storage」についてまとめたいと思います。

⇒次回ブログ
【備忘】非エンジニアによるKubernetes学習アウトプット⑤（Storageについて）