Deployment、ReplicaSet

1.Deployment

• 例)Deployment.yaml

• selectorとtemplateの関係性 selectorとtemplateは紐付けられる構造になっており、selectorがtemplateを（ラベルを介して）選択する仕組みになっている。

Ahahah I will not do it

• Deploymentの中にはPodのコードが含まれていて、metadataやspecの部分はPodの定義とほぼ同じになっている。
• ここから分かるのは、Deploymentが「Podを複数作るための枠組み」だということ。つまり、Podの構造をそのまま持ってきて、それをテンプレートとして使い回している。もう少し具体的に言うと、Deploymentはtemplateを使って複数のPodを作れるし、replicasの数を変えるだけで、Podを増やしたり減らしたり自由にコントロールできる仕組みになっている。

✅検証

セレクターのラベルとテンプレートのラベルが一致しない場合、デプロイメントは作成されない。

---

2.ReplicaSet

• 例)replicaset.yaml

• ReplicaSet.yamlファイルの構造は、Deploymentと同一である。

💡Deploymentとkind部分だけが異なるのに、なぜあえてReplicaSetを使う必要があるのか？どちらか一方だけを使用すればよいのではないか？

💡なぜアプリのデプロイ時にReplicaSetではなくDeploymentを使用するのか？

　　→核心は「状態制御」と「履歴管理」にある。

2-1. 階層構造 (Hierarchy)

• Deployment（戦略司令部）: どのイメージを使用し、どのような方式でデプロイするかを決定する。
• ReplicaSet（現場監督）: 常に規定数のPodが稼働しているかを監視・維持する。
• Pod（実務担当者）: 実際にコンテナが実行される最小単位。

2-2. アップデートのプロセス (Rolling Update)

イメージのバージョンを v1 から v2 に変更する場合のプロセスは以下の通りである。

1. 新規RSの生成: Deploymentが v2 用のReplicaSetを新規作成する（既存の v1 用RSは保持される）。
2. 入れ替え作業:
   • v2 用RSのPod数を段階的に増加させる。
   • v1 用RSのPod数を段階的に削減する。
   • このプロセスを繰り返すことで、トラフィックを徐々に新バージョンへと移行させる。
3. 結果: デプロイ完了後、v1 用RSはレプリカ数が「0」の状態で残る。これはロールバック（Rollback）を迅速に行うためであり、v2 に問題が発生した際、Deploymentが v1 用RSのレプリカ数を再設定するだけで旧バージョンへの復元が可能となる。

2-3. Deploymentを採用する理由

ReplicaSetのみを利用する場合、以下の作業を手動で行う必要がある。

• 新規ReplicaSetの作成。
• 既存ReplicaSetのスケールダウン。
• デプロイ障害時の手動によるリソース調整。

Deploymentは、これらの煩雑かつリスクを伴うプロセスを自動化する抽象化エンジンとして機能するため、モダンなインフラ運用において不可欠なコンポーネントである。

💡それでは、ReplicaSetを実行してみたらどうだろうか。

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  labels:
    app: rs-nginx
  name: rs-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: po-nginx
  template:
    metadata:
      labels:
        app: po-nginx
    spec:
      containers:
      - image: nginx
        name: nginx

それでは、ReplicaSetを実行してみたらどうだろうか。

• Pod状態

Podレベルでは差異がないことが確認できる。しかし、ここでの核心は「オブジェクトの目的」にある。ReplicaSetのみを単独で使用した場合、現在の状態を維持するというReplicaSetの限界が存在する。 Pod、ReplicaSet、Deploymentの有機的な関係を理解することで、Deploymentを十分に理解することができる。