9.3.2.2. ローリングデプロイメントの使用のタイミング
- ダウンタイムを発生させずに、アプリケーションの更新を行う場合
- 以前のコードと新しいコードの同時実行がアプリケーションでサポートされている場合
ローリングデプロイメントとは、以前のバージョンと新しいバージョンのコードを同時に実行するという意味です。これは通常、アプリケーションで N-1 互換性に対応する必要があります。
以下は、ローリングストラテジーの例です。
strategy: type: Rolling rollingParams: updatePeriodSeconds: 1 1 intervalSeconds: 1 2 timeoutSeconds: 120 3 maxSurge: "20%" 4 maxUnavailable: "10%" 5 pre: {} 6 post: {}
- 1
- 各 Pod が次に更新されるまで待機する時間。指定されていない場合、デフォルト値は
1
となります。 - 2
- 更新してからデプロイメントステータスをポーリングするまでの間待機する時間。指定されていない場合、デフォルト値は
1
となります。 - 3
- イベントのスケーリングを中断するまでの待機時間。この値はオプションです。デフォルトは
600
です。ここでの 中断 とは、自動的に以前の完全なデプロイメントにロールバックされるという意味です。 - 4
maxSurge
はオプションで、指定されていない場合には、デフォルト値は25%
となります。以下の手順の次にある情報を参照してください。- 5
maxUnavailable
はオプションで、指定されていない場合には、デフォルト値は25%
となります。以下の手順の次にある情報を参照してください。- 6
ローリングストラテジーは以下を行います。
-
pre
ライフサイクルフックを実行します。 - サージ数に基づいて新しいレプリケーションコントローラーをスケールアップします。
- 最大利用不可数に基づいて以前のレプリケーションコントローラーをスケールダウンします。
- 新しいレプリケーションコントローラーが希望のレプリカ数に到達して、以前のレプリケーションコントローラーの数がゼロになるまで、このスケーリングを繰り返します。
-
post
ライフサイクルフックを実行します。
スケールダウン時には、ローリングストラテジーは Pod の準備ができるまで待機し、スケーリングを行うことで可用性に影響が出るかどうかを判断します。Pod をスケールアップしたにもかかわらず、準備が整わない場合には、デプロイメントプロセスは最終的にタイムアウトして、デプロイメントに失敗します。
maxUnavailable
パラメーターは、更新時に利用できない Pod の最大数です。maxSurge
パラメーターは、元の Pod 数を超えてスケジュールできる Pod の最大数です。どちらのパラメーターも、パーセント (例: 10%
) または絶対値 (例: 2
) のいずれかに設定できます。両方のデフォルト値は 25%
です。
以下のパラメーターを使用して、デプロイメントの可用性やスピードを調整できます。以下は例になります。
-
maxUnavailable=0
およびmaxSurge=20%
が指定されていると、更新時および急速なスケールアップ時に完全なキャパシティーが維持されるようになります。 -
maxUnavailable=10%
およびmaxSurge=0
が指定されていると、追加のキャパシティーを使用せずに更新を実行します (インプレース更新)。 -
maxUnavailable=10%
およびmaxSurge=10%
の場合は、キャパシティーが失われる可能性がありますが、迅速にスケールアップおよびスケールダウンします。
一般的に、迅速にロールアウトする場合は maxSurge
を使用します。リソースのクォータを考慮して、一部に利用不可の状態が発生してもかまわない場合には、maxUnavailable
を使用します。