サージ アップデートについて

このドキュメントでは、標準のローリング アップデートの概要を簡単に説明した後、特別な種類のローリング アップデートであるサージ アップデートについて詳しく説明します。標準のローリング アップデートと比較すると、サージ アップデートでは更新の速度を構成できます。サージ アップデートでは、更新停止がワークロードに与える影響を制御することもできます。

GKE on AWS のサージ アップデートを有効にして構成する方法については、ノードプールのサージ アップデートを構成するをご覧ください。

標準のローリング アップデートの仕組み

ノードプールの一部の更新（ノードプールのアノテーションを変更する場合など）では、ノードの再起動は必要ないため、ローリング アップデートを呼び出さないでください。GKE on AWS がリソースを再起動または再作成せずにノードプールに変更を適用できる場合は、そうすることで中断を回避できます。

ただし、GKE on AWS のノードプールの更新のほとんどには、通常、既存のノードの停止と、更新された設定での新しいノードの起動が含まれます。既存のノードを停止するプロセスにより、ワークロードが中断される可能性があります。

デフォルトでは、GKE on AWS は標準のローリング アップデートを実行します。この方法では、ノードを 1 つずつ更新し、「作成前に停止」の方法（まずノードを停止し、次に更新したノードを起動します）で置換します。これにより、特定の時点で停止して置換されるノードが 1 つのみになるため、中断が最小限になります。

標準のローリング アップデート中に GKE on AWS が実行する手順は次のとおりです。

  1. ノードプールからノードを選択し、新しい Pod がそこで起動しないようにノードを「使用不可」としてマークします。この操作は閉鎖と呼ばれます。
  2. アクティブな Pod を、閉鎖されたノードからクラスタ内の他の利用可能なノードに再配置します。他のノードに十分な容量がある場合、排除された Pod を収容します。それ以外の場合は、標準のローリング アップデート中にアクティブのままであるクラスタ オートスケーラーが、スケールアップを開始し、排除された Pod をスケジューリングするのに十分な容量があるように追加のノードをプロビジョニングします。このプロセスでワークロードを保護するための対策については、サイズ変更中のワークロードの保護をご覧ください。
  3. 閉鎖されたノードを停止します。
  4. 閉鎖されたノードを、更新された設定の新しいものに置き換えます。
  5. 新しい動作するノードでヘルスチェックを実施します。ノードプールがヘルスチェックに失敗すると、DEGRADED ステータスでマークされます。このステータスは、gcloud container aws node-pools describe コマンドを実行して確認できます。ノードプールが DEGRADED とマークされると、そのプール内のノードで新しい Pod がスケジューリングされない場合があります。
  6. プール内のすべてのノードが更新されるまで、ノードごとに更新を続けます。

サージ料金の更新の仕組み

GKE on AWS では、標準のローリング方式でノードが 1 つずつ更新されます。ローリング アップデートの形態の 1 つであるサージ アップデートでは、複数のノードを同時に更新できます。したがって、サージ アップデートは標準のローリング アップデートよりも高速です。ただし、複数のノードを同時に更新すると、ワークロードが中断される可能性があります。これを軽減するため、サージ アップデートには、ワークロードの停止レベルを調節するオプションがあります。

サージ アップデートが標準的なローリング アップデートと異なるようにできるもう 1 つの方法は、ノードを置き換える方法です。標準ローリング アップデートでは、「作成前に停止」戦略でノードを置き換えます。選択した設定に応じて、サージ アップデートは「停止前に作成」戦略と「作成前に停止」戦略のいずれか、または両方の組み合わせでさえも使用できます。

クラスタ オートスケーラーは、サージ アップデートにおいて標準のローリング アップデートよりも重要な役割を担います。そのために、サージ アップデート中に GKE on AWS が実行する次のアクションのリストで、それが目立ちます。

  1. 新しい自動スケーリング グループの作成: GKE on AWS は、アップデート コマンドで指定された変更で新しいノードをプロビジョニングし、これらの新しいノードを新しい AWS オートスケーリング グループ（ASG）に割り当てます。
  2. クラスタ オートスケーラーの動作: サージ アップデートが開始されると、クラスタ オートスケーラーは新しい自動スケーリング グループに対して有効になります。元の自動スケーリング グループのクラスタ オートスケーラーは無効になっています。これにより、スケーリング オペレーションは新しいグループのみをターゲットにします。
  3. ノードの置換: サージ アップデート パラメータに応じて、ノードの置換の異なる戦略が用いられます。
    • 「停止前に作成」: この戦略は、max-surge-update パラメータがゼロより大きい値に設定されている場合に有効になります。それでは、サービスの中断を最小限にするために、元の ASG では古いノードを停止する前に、新しい ASG で新しいノードが生成されます。
    • 「作成前に停止」: この方法は、max-surge-update パラメータがゼロに設定され、max-unavailable-update パラメータの値がゼロより大きい場合にトリガーされます。元の ASG のノードが最初に停止され、次に新しい ASG に新しいノードが作成されます。
  4. ノードプール サイズの調整: 更新中、ノードプール サイズ（すなわち、古い ASG と新しい ASG のノードの合計）は、更新の開始前にノードプールに存在するノードの元の数の上下に変動する場合があります。具体的には、GKE on AWS は、ノードの合計数を（original_count - max-unavailable-update）から（original_count + max-surge-update）の範囲内に維持することを目的としています。最終的には、古い ASG（original_count）のノードが新しい ASG の更新されたノードに置き換えられます。クラスタ オートスケーラーは、Pod をスケジューリングできないが min-nodes と max-nodes で定義された制限内に収まっていることをそれが検出すると、新しい ASG でより多くのノードを起動する場合があります。

プロセスを示す例

サージ アップデートの仕組みをより理解するには、次の例について考えてみてください。5 つのノードを含むノードプールがあり、次のコマンドを実行します。

  gcloud container aws node-pools update production-node-pool
      --cluster my-cluster \
      --location us-west1 \
      --max-surge-update 2 \
      --max-unavailable-update 1 \
      --node-version 1.27.6-gke.700

この例では、max-surge-update が 2 に設定され、max-unavailable-update が 1 に設定され、新しいノードプール バージョンが指定されています（つまり、ノードプール内のノードで動作している GKE バージョンを変更しています）。

このコマンドを実行するとサージ アップデートがトリガーされ、GKE on AWS は次のアクションを実行します。

  1. max-surge-update の値が 2 に等しいため、2 つのノードが追加で作成されます。
  2. これらの 2 つの追加ノードを新しい AWS 自動スケーリング グループに割り当てます。
  3. これらの新しいノードが運用可能になったら、元の自動スケーリング グループからノードを削除します。GKE on AWS では、最大 3 つのノード（max-surge-update と max-unavailable-update の組み合わせた値）は停止しますが、いつでも最大 1 つのノードのみが使用不可になります（max-unavailable-update の値 1 による）。
  4. ノードプールのすべてのノードが新しい GKE バージョンに更新されるまで、この手順を繰り返します。

この更新の間、ノードプールには 4～7 個の稼働中のノードが含まれます。

サージ アップデートを実行する前に考慮すべきこと

サージ アップデートを実行する前に、次の点に留意してください。

  • このサージステップの一部として作成された追加のインスタンスは、AWS インスタンスの割り当ての上限を超える可能性があります。十分な割り当てがなく、これらの追加のインスタンスをプロビジョニングできない場合は、更新が失敗する場合があります。
  • max-unavailable-update が 0 に設定されている場合、Pod が排除されてより新しいノードに再スケジューリングされると、ワークロードの中断が発生する可能性がまだあります。
  • 同時に更新できるノードの最大数は max-surge-update と max-unavailable-update の合計で、20 に制限されています。

ニーズに合った正しいサージ設定を選択する

標準のローリング アップデートでは多くの場合、「作成前に停止」方式を用いますが、サージ アップデートではより柔軟になります。構成に応じて、サージ アップデートは、「停止前に作成」戦略、「作成前に停止」戦略、または両方の組み合わせに従うことができます。このセクションでは、ワークロードに最適なアプローチを選択するのに役立つように、異なる構成について説明します。

次の表は、3 つの設定例を示し、更新の速度と起こりうるワークロードの停止についてのそれらの影響を強調しています。

名前 説明 構成
バランス設定（デフォルト） バランス重視。遅いが中断は最小。 maxSurge=1, maxUnavailable=0
追加のリソースなしで迅速に更新 高速。サージリソースなし。中断多発。 maxSurge=0, maxUnavailable=20
中断の少ない迅速な更新 高速。サージリソース大。中断少なめ。 maxSurge=20, maxUnavailable=0

次のセクションでは、表の各設定について説明します。

バランス設定（デフォルト）

サージ アップデートを使用する最も簡単な方法は、max-surge-update=1 と max-unavailable-update=0 のデフォルト構成をとることです。この構成では、更新中にノードプールにサージノードが 1 つだけ追加され、「停止前に作成」のアプローチに従って、一度に 1 つのノードのみ更新されます。標準の非サージ ローリング アップデート（max-surge-update=0、max-unavailable-update=1 と同等）と比較して、この方法は中断が少なく、更新中の Pod の再起動を加速し、進行中により安定します。

バランス設定を採用すると、更新中に追加された一時的なサージノードのために追加費用が発生する可能性がある点に注意してください。この追加ノードによって、それがアクティブな間は料金が発生します。サージノードがない方法と比較して、全体的な費用がわずかに増加します。

追加のリソースなしで迅速に更新

中断を許容できるワークロードの場合は、より高速な更新方法が適している可能性があります。max-surge-update=0 と max-unavailable-update=20 を構成すると、これが有効になります。この構成では、サージノードを追加せずに 20 ノードを同時に更新できます。この更新方法は、「作成前に停止」のアプローチに従います。プロセスの間に追加のサージノードが導入されないため、この方法は最も費用対効果が高く、一時的なノードに関連する余分な費用を回避できます。

中断の少ない迅速な更新

ワークロードが停止の影響を受けやすい場合は、max-surge-update=20 と max-unavailable-update=0 の設定で更新速度を上げることができます。この構成では、「停止前に作成」方式で 20 ノードを並行して更新します。

ただし、ワークロードに PodDisruptionBudgets（PDB）を設定している場合、更新の全体的な速度が制限される可能性があります。これは、PDB が任意の瞬間に空にできる Pod の数が制限されるためです。PDB の構成はさまざまですが、ノードプールで実行されている 1 つまたは複数のワークロードに対して PDB を 1 に等しい maxUnavailable で作成していれば、一度に削除できるのはワークロードの 1 つの Pod のみとなり、これにより、更新全体の並列性が制限されます。

更新プロセスの開始時に複数のサージノードを開始すると、特に更新時にさらにノードを追加しない、またはより少ない数のノードを追加する構成と比較して、一時的な費用の増加につながる可能性があります。

次のステップ

GKE on AWS のサージ アップデートを有効にして構成する方法については、ノードプールのサージ アップデートを構成するをご覧ください。