本記事は、非エンジニアである筆者が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」についてまとめたいと思います。