ローリング更新の数理と可用性制約

ローリング更新を数で捉える

デプロイ戦略 のローリング更新は「数台ずつ入れ替える」と説明されますが、その「数台」を決めるのが maxSurge と maxUnavailable という2つのパラメータです。Kubernetes の Deployment では、この2つが更新中に許される 台数の上限と下限の窓 を定義します。記号を整理します。

R  = desired replicas（目標レプリカ数）
S  = maxSurge（一時的に R を超えて作れる Pod 数の上限）
U  = maxUnavailable（更新中に不足してよい Pod 数の上限）

S と U はパーセント指定もでき、その場合は R を掛けて Pod 数に変換します。maxSurge は切り上げ（ceil）、maxUnavailable は切り捨て（floor）で丸められる点が重要です。たとえば R=4、maxSurge=25%、maxUnavailable=25% なら S = ceil(1.0) = 1、U = floor(1.0) = 1 です。この丸めの非対称は安全側、つまり「サージはやや多め、不足はやや少なめ」に倒すための仕様です。

更新中の可用性：下限を支配するのは maxUnavailable

ローリング更新中、コントローラが保証する 利用可能 Pod 数の下限 は次式で近似できます。

最小可用台数 ≒ R − U

R=10、U=2 なら、更新の全工程を通じて少なくとも 8 台は Ready であり続けます。ここが設計の一次制約です。サービスがピーク時に「7 台では捌けない」とわかっているのに U=4 と設定すれば、デプロイそのものがキャパシティ不足、すなわち自己誘発的な障害になります。可用性の床は maxSurge ではなく maxUnavailable が支配する、と覚えてください。

ただし「最小可用台数」は Ready とカウントされた Pod の数 であって、実際に流量を受けられる台数とは限りません。新しい Pod が起動直後でまだウォームアップ中だと、Ready 判定は通っていても性能が出ません。SRE と SLO の観点では、必要キャパシティに安全マージンを足した値を R − U が下回らないよう設計します。

ロールアウト時間：1ステップで何台進むか

ロールアウトに要する時間は「全 R 台を入れ替えるのに、1回のステップで何台進めるか」で決まります。1ステップで前進できる台数 P は、サージ枠と不足枠の合計に支配されます。

1ステップで前進できる台数 P ≒ S + U
（ただし新規 Pod の起動と古い Pod の終了が並行するため）

直感は次の通りです。コントローラは古い Pod を最大 U 台まで先に削れ、同時にサージ枠 S で新しい Pod を S 台余分に立てられます。つまり1サイクルあたり最大で S + U 台ぶんの置換が並行します。総ロールアウト時間は次のように近似できます。

ロールアウト時間 ≒ ceil(R ÷ (S + U)) × T_step

T_step = 新 Pod が起動して Ready になるまでの時間
         （イメージ pull + 起動 + Readiness 待ち）

例として R=12、S=2、U=2、T_step=30秒 なら、12 ÷ 4 = 3 ステップ、合計およそ 90 秒です。ここで効くのは S + U という 並列度 です。並列度を上げればステップ数は減りますが、後述するコストと可用性の制約に突き当たります。

サージ容量とリソースのトレードオフ

maxSurge を上げる最大の代償は 一時的なリソース消費 です。更新中、クラスタには最大で R + S 台ぶんの Pod が同時に存在し得ます。各 Pod の要求リソースを r（CPU・メモリ）とすると、ピーク時の追加要求は次の通りです。

更新中のピーク Pod 数 ≒ R + S
追加で必要なリソース ≒ S × r

maxSurge が大きいほど、この余剰枠をスケジュールできるだけの空きがノード側に必要です。空きがなければ新しい Pod は Pending のまま スケジューラ に弾かれ、ロールアウトはそこで停滞します。つまり maxSurge を上げる前提として、クラスタに S × r ぶんのヘッドルームを常時確保するか、Cluster Autoscaler でノードを増やせる構成が要ります。3つのパラメータ設定が何を最適化するかを整理します。

要点は、速度・可用性・コストの3つを同時には最大化できない ことです。maxUnavailable=0 は可用性を保ったまま更新できますが、サージ枠なしでは1台も置換を始められないため maxSurge >= 1 が必須となり、その余剰リソースを払い続けます。逆に maxSurge=0 は余剰ゼロですが、maxUnavailable を上げないと進まず、可用性を削ることになります。

まとめ

• 更新中の 最小可用台数は おおよそ R − maxUnavailable。ここが必要キャパシティを割ると、デプロイが障害化する。可用性の床を支配するのは maxUnavailable。
• ロールアウト時間は おおよそ ceil(R ÷ (S + U)) × T_step。並列度 S + U を上げるとステップは減るが、多くの場合ボトルネックは1台あたりの T_step。
• maxSurge を上げると速く・可用性を保てるが、更新中ピークで R + maxSurge 台ぶん のリソースを食う。S × r のヘッドルームかオートスケールが前提。
• 速度・可用性・コストは三すくみ。両方 0 は不可、少なくとも一方は 1 以上。Readiness プローブの質が可用性の床の質を決める。
• ステートフルワークロードや PDB が絡むと並列度の前提が変わる。実効上限は最も厳しい制約で決まる。