ローリングアップデートとロールバック

導入

新しいバージョンへの入れ替えは、サービスを止めずに行いたいものです。Deployment は、新旧の Pod を少しずつ入れ替えることで無停止の更新（ローリングアップデート）を実現します。失敗したときに前へ戻すロールバックも一発です。

説明

Deployment のマニフェストで image のタグ（バージョン）を新しくして apply し直すと、Kubernetes は新しい ReplicaSet を作り、新しい Pod を少しずつ増やしながら、古い Pod を少しずつ減らしていきます。これが ローリングアップデート（rolling update） です。常に一定数の Pod が動いたままなので、利用者からはサービスが止まって見えません。

sequenceDiagram
    participant Old as 旧ReplicaSet（v1）
    participant New as 新ReplicaSet（v2）
    Note over Old,New: 開始: 旧3個 / 新0個
    New->>New: 新Podを1個起動（準備OK待ち）
    Old->>Old: 旧Podを1個停止
    Note over Old,New: 旧2個 / 新1個
    New->>New: 新Podをもう1個起動
    Old->>Old: 旧Podをもう1個停止
    Note over Old,New: 旧1個 / 新2個
    New->>New: 新Podを最後の1個起動
    Old->>Old: 旧Podを最後の1個停止
    Note over Old,New: 完了: 旧0個 / 新3個

更新まわりのコマンドはこうです。

# イメージのタグを変えて更新を始める（apply で書き換えても同じ）
kubectl set image deployment/web-deploy nginx=nginx:1.28

# 更新の進み具合を見る
kubectl rollout status deployment/web-deploy
# deployment "web-deploy" successfully rolled out

# これまでの更新履歴を見る
kubectl rollout history deployment/web-deploy

# 直前のバージョンに戻す（ロールバック）
kubectl rollout undo deployment/web-deploy

入れ替えの「少しずつ」の度合いは、次の2つで調整します。

• maxSurge … あるべき数を一時的に何個超えて増やしてよいか（更新を速くする余力）。
• maxUnavailable … 更新中に同時に何個まで欠けてよいか（可用性の下限）。

このおかげで、新バージョンに不具合があってもサービス全体が一気に落ちることはなく、rollout undo ですぐ前の状態へ戻せます。第1章で挙げた「無停止デプロイ」は、この Deployment の機能そのものです。