Kubernetes ローリングアップデート

Kubernetes ローリングアップデートとは

ローリングアップデートは、Deployment の既定のデプロイ戦略 (.spec.strategy.type の既定値が RollingUpdate) で、旧バージョンの ReplicaSet を縮小しながら新バージョンの ReplicaSet を拡大する形で Pod を置き換える。一度に何台動かせるかは maxSurge と maxUnavailable が決め、どちらも既定は望ましいレプリカ数の 25 % である (2026 年 8 月時点)。全 Pod を同時に停止しないため更新中もリクエストを受け続けられるが、無停止は戦略を選ぶだけでは手に入らない。後述の Readiness プローブと終了処理が揃って初めて成立する。

ロールアウトが始まるのは Pod テンプレート (.spec.template) が変わったときだけである。replicas の変更のような他の更新では始まらないため、ConfigMap の中身だけを変えても Pod は入れ替わらない。反映させたいならテンプレート側 (注釈やイメージタグ) を動かす必要がある。

設定

代表的な設定は次の形になる。新しい Pod が Ready になるまで旧 Pod を 1 台も落とさない、可用性側に振った指定である。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 望ましい数を超えて作れる Pod 数
      maxUnavailable: 0   # 更新中に利用不能にできる Pod 数 (0 = 常に 3 台が Ready)
  template:
    spec:
      containers:
        - name: app
          image: myapp:2.0
          readinessProbe:
            httpGet:
              path: /ready
              port: 3000

更新の流れ

上の設定 (replicas 3・maxSurge 1・maxUnavailable 0) では、置き換えは次の順で進む。

初期状態:  [v1] [v1] [v1]           ← 3 Pod 稼働中
Step 1:    [v1] [v1] [v1] [v2]      ← 新 Pod 追加 (maxSurge: 1)
Step 2:    [v1] [v1] [v2↑] [v2]     ← v2 が Ready になったら v1 を 1 つ削除
Step 3:    [v1] [v2] [v2] [v2]
Step 4:    [v2] [v2] [v2]           ← 完了

maxUnavailable: 0 にすると、新 Pod が Ready になるまで旧 Pod を削除しない。利用可能な Pod が望ましい数を一瞬も下回らない指定である。

その代わり、更新中は replicas + maxSurge 台分のリソースを確保できることが前提になる。ノードに空きが無かったり ResourceQuota の上限に当たると、新 Pod が Pending のまま置き換えが進まない。なお maxSurge と maxUnavailable を両方 0 にする指定は受け付けられない。片方が 0 のときもう一方を 0 にできない決まりで、両方 0 では Pod を入れ替える余地が無くなるためである。

maxSurge と maxUnavailable の組み合わせ

この 2 つの値は、更新の速さと更新中の容量のどちらを取るかを決める調整つまみになる。

設定	動作	特徴
maxSurge: 1, maxUnavailable: 0	1 つずつ追加→削除	最も安全、時間がかかる
maxSurge: 0, maxUnavailable: 1	1 つ削除→追加	リソース節約、一時的に容量低下
maxSurge: 25%, maxUnavailable: 25%	まとまった数を並行して入れ替える	既定値 (指定しない場合はこれ)

パーセント指定には端数の扱いに非対称がある。maxSurge は切り上げ、maxUnavailable は切り下げで絶対数へ換算される。replicas が 3 なら既定の 25 % は maxSurge 1・maxUnavailable 0 となり、動きは表の 1 行目と同じになる。既定値のままでもレプリカ数が小さいうちは並行度が上がらない、と読んでおくとよい。

Readiness プローブとの連携

ローリングアップデートの成否は Readiness プローブにかかっている。

1. 新 Pod が起動する
2. Readiness プローブが成功するまで、Service のエンドポイントに追加されない
3. Readiness が成功し minReadySeconds (既定 0 秒) を満たすと利用可能に数えられ、旧 Pod が削除される
4. Readiness が失敗し続けると新 Pod が利用可能にならず、置き換えがそこで止まる

Readiness プローブがないと、起動中の Pod にトラフィックが流れてエラーが発生する。

止まった状態は自動では戻らない。.spec.progressDeadlineSeconds (既定 600 秒) を超えると Deployment の状態に Progressing=False と ProgressDeadlineExceeded が付くが、Kubernetes 自身はこの条件を報告するだけで、ロールバックも停止もしない (2026 年 8 月時点)。戻す判断は上位の仕組みか運用者の側にあるので、この条件を監視対象に入れておく。逆に maxUnavailable を大きく取っていると、壊れた新 Pod で置き換えが止まる前に旧 Pod が減るため、気付く前に容量を失う。

ロールバック

直前の状態へ戻す操作は、保持されているリビジョンを指定して行う。

# 直前のバージョンにロールバック
kubectl rollout undo deployment/api-server

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

# 更新状況の確認
kubectl rollout status deployment/api-server

戻せるのは古い ReplicaSet が残っている範囲に限られる。保持数は .spec.revisionHistoryLimit で決まり既定は 10 で、超えた分は背後で回収される。0 を指定すると履歴が残らずロールバックできなくなる。回収が始まるのは Deployment が完了状態に達した後なので、失敗したロールアウトを繰り返している間は上限を超えて ReplicaSet が溜まることもある。

Blue/Green デプロイとの比較

同じ無停止更新でも、リソースの持ち方と切り替えの粒度が違う。

観点	ローリングアップデート	Blue/Green
リソース	一時的に maxSurge の分だけ増える (既定 25 %)	2 倍のリソースが必要
切り替え速度	段階的 (数分)	即座 (DNS/LB 切り替え)
ロールバック	段階的	即座
新旧混在	更新中は混在する	混在しない

よくある落とし穴

Graceful Shutdown の未実装

旧 Pod が削除される際、処理中のリクエストが中断される。Pod の終了開始と、Service の EndpointSlice からその Pod を外す処理は並行して進み、終了し始めた Pod のエンドポイントも即座には消えない。そのため除外が行き渡るまでの短い間、終了中の Pod へリクエストが届き得る。preStop フックでその間を待ち、SIGTERM を受けてから処理中のリクエストを終える実装にする。

lifecycle:
  preStop:
    exec:
      command: ["sh", "-c", "sleep 5"]  # 経路から外れるまで待つ

preStop は SIGTERM より前に実行され、その待ち時間は終了猶予 (terminationGracePeriodSeconds・既定 30 秒) の中から消費される。猶予が切れても preStop が終わらない場合に与えられる延長は 2 秒だけで、その後は SIGKILL になる。長く待たせたいなら猶予そのものを延ばす。

更新が思ったように進まないときは、kubectl rollout status と kubectl describe deployment の Conditions を最初に見る。Available と Progressing のどちらが落ちているかで、容量が足りないのか、新 Pod が Ready になれないのかを切り分けられる。