This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.9.3.2.2. ローリングデプロイメントの使用のタイミング
- ダウンタイムを発生させずに、アプリケーションの更新を行う場合
 - 以前のコードと新しいコードの同時実行がアプリケーションでサポートされている場合
 
ローリングデプロイメントとは、以前のバージョンと新しいバージョンのコードを同時に実行するという意味です。これは通常、アプリケーションで N-1 互換性に対応する必要があります。
以下は、ローリングストラテジーの例です。
- 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 を使用します。