xDev Asia

Deployment戦略: RollingUpdate vs Recreate。kubectl rolloutコマンド、 maxUnavailable/maxSurge。Revision historyとCKAD向けロールバック技術。

Rolling UpdateとRollback — maxUnavailable、maxSurge、ReplicaSet history

1. Deployment戦略

戦略	動作	ダウンタイム	使用場面
RollingUpdate	Podを段階的に入れ替え、可用性を維持	なし	デフォルト、本番環境
Recreate	すべての古いPodを削除してから新しいPodを作成	あり	開発/テスト、破壊的変更

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1   # OR "25%"  — Max pods unavailable during update
      maxSurge: 1         # OR "25%"  — Max extra pods above desired count

      ┌─────────────────────────────────────────────────┐
      │ Desired: 4 pods                                  │
      │                                                  │
      │ maxUnavailable: 1 → min 3 pods must be running  │
      │ maxSurge: 1       → max 5 pods total at once    │
      │                                                  │
      │ Step 1: Create 1 new pod (5 total = desired+surge)│
      │ Step 2: Terminate 1 old pod (4 total)           │
      │ Step 3: Repeat until all replaced               │
      └─────────────────────────────────────────────────┘

試験のポイント: maxUnavailableとmaxSurgeは同時に0にできません。ゼロダウンタイム更新には: maxUnavailable: 0とmaxSurge: 1（またはそれ以上）を設定します。

2. kubectl rolloutコマンド

# ロールアウト状態を確認
kubectl rollout status deployment/myapp

# リビジョン履歴を表示
kubectl rollout history deployment/myapp
kubectl rollout history deployment/myapp --revision=2

# 前のバージョンにロールバック
kubectl rollout undo deployment/myapp

# 特定のリビジョンにロールバック
kubectl rollout undo deployment/myapp --to-revision=2

# ロールアウトを一時停止
kubectl rollout pause deployment/myapp

# ロールアウトを再開
kubectl rollout resume deployment/myapp

コマンド	用途
`rollout status`	現在のロールアウト進捗を待機/表示
`rollout history`	リビジョン履歴を一覧表示
`rollout undo`	前の（または特定の）リビジョンにロールバック
`rollout pause/resume`	カナリアテスト用に一時停止、その後再開
`rollout restart`	全Podを強制再起動（ローリング）

試験のポイント: リビジョン履歴にCHANGE-CAUSEを記録するには、更新前にアノテーションを追加: kubectl annotate deployment/myapp kubernetes.io/change-cause="Updated image to v2"。または--recordフラグを使用（非推奨ですが試験ではまだ動作します）。

3. アップデートのトリガーと監視

# イメージを更新（rolling updateをトリガー）
kubectl set image deployment/myapp container-name=nginx:1.25

# ReplicaSet履歴を確認（各更新で新しいRSが作成される）
kubectl get rs
# NAME              DESIRED   CURRENT   READY
# myapp-7d9b8c      4         4         4     ← current
# myapp-6f5a2b      0         0         0     ← old (kept for rollback)

# Deploymentをスケール
kubectl scale deployment/myapp --replicas=6

# Deploymentを直接編集
kubectl edit deployment/myapp

4. Revision History Limit

spec:
  revisionHistoryLimit: 10  # Default: 10 old RS kept for rollback
                             # Set to 0 to disable rollback capability

5. チートシート

試験シナリオ	コマンド
イメージ更新	`kubectl set image deploy/app c=image:v2`
ロールアウト確認	`kubectl rollout status deploy/app`
クイックロールバック	`kubectl rollout undo deploy/app`
rev 3にロールバック	`kubectl rollout undo deploy/app --to-revision=3`
ゼロダウンタイム設定	`maxUnavailable: 0, maxSurge: 1`

6. 練習問題

Q1: 10レプリカのDeploymentがmaxUnavailable: 2、maxSurge: 3で設定されています。ローリングアップデート中に同時に存在できるPodの最大数はいくつですか？

A) 10
B) 12
C) 13 ✓
D) 15

解説: maxSurge=3は希望数(10)を超えて最大3つの追加Podが同時に存在できることを意味します。したがって最大 = 10 + 3 = 13 Pod。一方、maxUnavailable=2は少なくとも8つのPodが利用可能でなければならないことを意味します。

Q2: Deploymentを更新した後、新しいバージョンにバグがあることに気づきました。前の動作するバージョンに素早く戻すコマンドはどれですか？

A) kubectl delete deployment myapp && kubectl apply -f old.yaml
B) kubectl rollout undo deployment/myapp ✓
C) kubectl rollout history deployment/myapp
D) kubectl set image deployment/myapp container=old-image

解説: rollout undoは前のリビジョンに戻す最速の方法です。前のReplicaSetへの新しいローリングアップデートを作成します。選択肢Dも機能しますが、正確な旧イメージ名を知る必要があります。

Q3: DeploymentがRecreate戦略を使用しています。更新時の動作はどうなりますか？

A) Podが1つずつ置き換えられ、ダウンタイムなし
B) すべての既存Podが削除されてから新しいPodが作成され、ダウンタイムが発生する ✓
C) Podの半分が更新され、残り半分がトラフィックを処理する
D) 新しいPodが先に作成され、その後古いPodが削除される