Pod・Deployment・ReplicaSet｜クラウドインフラ

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：Kubernetesの全体像（宣言的・調整ループ）　|　関連：Service・Ingress・スケーリングと自己修復

要点（BLUF）

Pod＝K8s の最小実行単位。1つ以上のコンテナを「同じネットワーク・同じノード」でまとめた箱。普通は 1Pod＝1アプリ。
ReplicaSet＝「Podを常にN個保つ」調整ループ。落ちれば作り直し、増えれば減らす。
Deployment＝ReplicaSet を世話する上位。ローリング更新（無停止でバージョン入替）とロールバックを宣言で行う。普段触るのは Deployment。

概念 ── Pod・ReplicaSet・Deploymentの入れ子

3つは入れ子の関係です。Deployment が ReplicaSet を作り、ReplicaSet が Pod を保つ。

flowchart TB
    deploy["Deployment（更新・ロールバックを管理）"] --> rs["ReplicaSet（Podを常にN個に保つ）"]
    rs --> p1["Pod（コンテナ＋IP）"]
    rs --> p2["Pod"]
    rs --> p3["Pod"]

Pod は使い捨て。IP を持つが、消えて作り直されるとIPは変わる（だから安定した宛先＝Service が要る：Service・Ingress）。
ReplicaSet は「N個」を死守する調整ループ（Kubernetesの全体像（宣言的・調整ループ））の実体。
Deployment は ReplicaSet を複数世代管理し、新旧を入れ替える。

仕組み ── ローリング更新

新バージョンを出すとき、Deployment は新しいReplicaSetを少しずつ増やし、古いReplicaSetを少しずつ減らす。常に最低限の数が動いているので無停止で入れ替わります。

flowchart LR
    subgraph before["更新前"]
      old3["旧Pod x3"]
    end
    subgraph during["更新中（ローリング）"]
      old2["旧Pod x2"]
      new1["新Pod x1"]
    end
    subgraph after["更新後"]
      new3["新Pod x3"]
    end
    before --> during --> after

問題があればロールバックで前の世代の ReplicaSet に戻すだけ。デプロイ戦略の全体像（カナリア等）はデプロイ戦略（ローリング・ブルーグリーン・カナリア）で扱います。

動く例 ── Deployment manifest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3                 # 望ましいPod数（ReplicaSetがこれを死守）
  selector:
    matchLabels:
      app: web
  template:                   # ここが Pod の雛形
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27   # タグ固定（latest を避ける）
          ports:
            - containerPort: 80
          resources:          # cgroups 相当の要求/上限（コンテナとは（名前空間・cgroups））
            requests: { cpu: "100m", memory: "128Mi" }
            limits:   { cpu: "500m", memory: "256Mi" }

kubectl apply -f deployment.yaml
kubectl get pods -l app=web        # 3つ動く
kubectl delete pod <名前>           # 1つ消す → ReplicaSet が即作り直す
kubectl set image deployment/web web=nginx:1.27.1   # ローリング更新
kubectl rollout status deployment/web               # 進捗
kubectl rollout undo deployment/web                 # ロールバック

requests（最低保証）と limits（上限）は、Scheduler の配置判断と cgroups の制限に効く重要設定。limits を超えるメモリ使用は Pod が止められます（OOMKill）。

なぜ Deployment を使うのか

無停止更新のため：ローリング更新で、ユーザーに切れ目を見せずバージョンを入れ替えられる。失敗時はロールバックで即復旧。
自己修復のため：ReplicaSet が「N個」を死守するので、ノード障害・誤削除でも自動で戻る（スケーリングと自己修復）。
宣言で履歴が残るため：更新も apply で宣言。世代管理されるので、いつでも前へ戻せる。

⚠️ よくある誤解・落とし穴

「Pod を直接作る（kind: Pod）」→ 落ちても誰も作り直さない。ReplicaSet/Deployment 経由で作るのが原則。
「1Podに何でも詰める」→ 原則1Pod1アプリ。補助プロセス（ログ転送等）だけサイドカーで同居させる。
「requests/limits を書かない」→ Scheduler が配置を誤り、1Podがノードを食い尽くす。最低限の要求と上限は必ず設定。
「latest イメージで運用」→ ローリング更新で新旧が混在し、何が動いているか不明に。必ずタグ固定（Dockerイメージとレイヤ）。
「更新が固まったのに放置」→ 新Podが起動失敗で詰まることがある。rollout status を確認し、ダメなら undo。

対応ラボ

cloud-infra-study/labs/04-02_deployment.yaml（3レプリカのDeployment。apply → Pod削除で自動復活 → set image でローリング更新 → undo でロールバックを観察。kind/minikube で）。