Deployment と ReplicaSet とは何で、rolling update と rollback はどう動きますか？

Question

IT Interview Practice · Accepted Answer

**Deployment** は、stateless なアプリを動かすための標準的な controller です。**ReplicaSet** を管理し、ReplicaSet は指定された数の同一の Pod を稼働させ続けます。あなたは Deployment を編集するだけで、Deployment が **rolling update** と **rollback** をあなたの代わりにオーケストレーションします。

## 階層構造

```text
Deployment  → declares desired state + update strategy (the thing YOU manage)
   └── ReplicaSet  → ensures N identical Pods exist (one per app version)
          └── Pod  → Pod → Pod ...  (the actual running copies)

On each new version, the Deployment creates a NEW ReplicaSet and shifts Pods over.
```

## Deployment の manifest

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # 更新中に停止する Pod は最大 1 つ
      maxSurge: 1            # 望ましい数を超える追加 Pod は最大 1 つ
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update：ゼロダウンタイムのバージョン変更

```bash
kubectl set image deployment/web web=myapp:2.0   # rolling update を起動する
kubectl rollout status deployment/web            # 進捗を監視する
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (start: 4 old Pods)
      █████       spin up 1 new (v2), now 5 total (surge)
      ███ █       old down to 3, new is Ready
      ...gradually shift...
  v2: ████        (end: 4 new Pods, old ReplicaSet scaled to 0)
Traffic only goes to Pods that pass their readiness probe → no downtime.
```

## リリースが不良になったときの rollback

```bash
kubectl rollout history deployment/web       # revision を一覧表示する
kubectl rollout undo deployment/web          # 直前の revision へ戻す
kubectl rollout undo deployment/web --to-revision=3
```

古い ReplicaSet が（0 にスケールされて）保持されているため、rollback は高速です。Kubernetes は直前の ReplicaSet を再びスケールアップし、新しい方をスケールダウンするだけです。

## スケーリング

```bash
kubectl scale deployment/web --replicas=10   # 望ましい数を変更する
```

## なぜ重要なのか

Deployment は Kubernetes 上で stateless なアプリケーションを動かすための主力であり、それと ReplicaSet との関係を理解することは必須の日常的な知識です。重要な洞察は階層構造にあります。あなたは **Deployment** を管理し、それが（バージョンごとに 1 つの）**ReplicaSet** を所有し、各 ReplicaSet は指定された数の同一の Pod が稼働していることを保証します — これらは連なる reconciliation ループであり、合わさって self-healing と安定した replica 数をもたらします。真の強みは、Deployment が変更をどう扱うかにあります。**rolling update** は新しい ReplicaSet を作り、`maxSurge` と `maxUnavailable` に統制されながら Pod を古い方から新しい方へ徐々に移すため、キャパシティが保たれ、しかも（どの Pod がトラフィックを受けるかを制御する readiness probe と組み合わさって）リリースは**ゼロダウンタイム**で行われます。直前の ReplicaSet は（削除ではなく 0 にスケールされて）保持されるため、**rollback** は高速かつ安全です。`kubectl rollout undo` は古いバージョンを再びスケールアップし、不良の方をスケールダウンするだけで、これはまさにリリースが不調のときに手を伸ばすものです。これらの仕組み — さらにスケール方法（`kubectl scale`）と進捗の確認方法（`kubectl rollout status/history`）— を理解することは、Kubernetes 上で安全にソフトウェアを出荷するための基礎であり、プラットフォームが production でどう動くかを定義する宣言的で controller 主導のモデルを反映しています。

階層構造

Deployment の manifest

Rolling update：ゼロダウンタイムのバージョン変更

リリースが不良になったときの rollback

スケーリング

なぜ重要なのか

関連する質問