ノードプールのサージ アップデートを構成する

このドキュメントでは、ノードプールのサージ アップデートを有効にして管理する方法について説明します。ノードプールのサージ アップデートの仕組みについては、サージ アップデートについてをご覧ください。

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

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

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

サージ アップデートを有効にして構成する

サージ アップデートを有効にする場合は、Google Cloud サポートにお問い合わせください。サポートチームがこの機能を有効にしたら、ノードプールの作成または更新時に max-surge-update パラメータと max-unavailable-update パラメータに値を割り当てることができます。

作成

gcloud container aws node-pools create NODE_POOL_NAME
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --max-surge-update MAX_SURGE \
    --max-unavailable-update MAX_UNAVAILABLE

更新

gcloud container aws node-pools update NODE_POOL_NAME
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --max-surge-update MAX_SURGE \
    --max-unavailable-update MAX_UNAVAILABLE

次のように置き換えます。

  • NODE_POOL_NAME: 更新するノードプールの名前。
  • CLUSTER_NAME: クラスタの名前。
  • GOOGLE_CLOUD_LOCATION: クラスタを管理する、サポートされている Google Cloud リージョン。例: us-west1
  • MAX_SURGE: 更新中に現在のノードプール サイズを超えて一時的に作成できる追加ノードの最大数。この値を調整することで、同時に更新されるノードの数を制御できます。デフォルト設定は 1 ですが、0 に設定することもできます。max-surge-update を 0 より大きい値に設定すると、GKE on AWS によってサージノードが作成されます。0 に設定すると、作成されません。
  • MAX_UNAVAILABLE: 更新プロセス中に同時に使用不可になることが許容されるノードの最大数。この値を増やすと、同時に更新できるノードが増えます。デフォルト値は 0 ですが、値を大きくすることもできます。

ノードプールのサージ アップデートの設定を確認する

ノードプールのサージ アップデートの設定を確認するには、次のコマンドを実行します。

gcloud alpha container aws node-pools describe NODE_POOL_NAME
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \

次のように置き換えます。

ノードプールでサージ アップデートが有効になっている場合、このコマンドの出力には surge_settings というラベルの付いたセクションが表示されます。この surge_settings セクションには、max_surge と max_unavailable のパラメータの値が表示されます。

進行中のサージ アップデートを管理する

進行中のサージ アップデートをキャンセルしたり、失敗したサージ アップデートのロールバックできます。また、中断されたアップデートを再開することもできます。

サージ アップデートをキャンセル（一時停止）して再開する

GKE on AWS でサージ アップデートの「キャンセル」とは、実際には一時停止を意味します。アップデートをキャンセルする方法について詳しくは、アップデート オペレーションをキャンセルするをご覧ください。

つまり、サージ アップデートをキャンセルしても、アップデートはロールバックされません。2 つの自動スケーリング グループ（以前の構成を実行するノードのグループと新しい構成を実行するノードのグループ）が存在し、ノードプールが部分的に更新された状態になる可能性があります。この問題を回避するには、中断されたオペレーションと同じターゲット パラメータを使用し、update コマンドを再実行してサージ アップデートを再開します。別のノードプール パラメータを使用したアップデートの開始は、前回の更新が完了するまで制限されます。

失敗したサージ アップデートをロールバックする

サージ アップデートがキャンセルされた場合や失敗した場合、ノードプールを元の状態にロールバックできます。

サージ アップデートをロールバックする前に考慮すべきこと

  • ロールバックできるのは、部分的に更新された状態（または DEGRADED 状態）にあるサージ対応のノードプールのみです。
  • ノードプールでロールバックが開始した後にキャンセルすることはできません。
  • ロールバック オペレーションが正常に終了するまで、追加のアップデート オペレーションは制限されます。
  • ロールバックは、失敗した場合にのみ再試行できます。
  • 正常に更新されたノードプールをロールバックすることはできません。

失敗したサージ アップデートをロールバックする方法

ノードプールで失敗したアップデート オペレーションをロールバックするには、次のコマンドを実行します。

gcloud container aws node-pools rollback NODE_POOL_NAME
    --cluster CLUSTER_NAME

次のように置き換えます。

  • NODE_POOL_NAME: 更新するノードプールの名前。
  • CLUSTER_NAME: クラスタの名前。

ロールバックの仕組み

内部でロールバックを開始すると、ノードプールで新しいアップデート オペレーションが開始されます。ここでの「内部」とは、このプロセスがシステム自体の内部で実行され、ユーザーの介入を必要としないことを意味します。このオペレーションは、ノードプール ノードをベスト エフォートで元の状態に戻します。

古い自動スケーリング グループに属するノードの閉鎖を解除し、このグループのクラスタ オートスケーラーを有効にして、ノードでワークロードをスケジューリングできるようにします。新しい自動スケーリング グループで部分的に更新されたノードプール ノードを、最初のサージ アップデートの試行で定義したサージ設定に基づいて閉鎖し、ドレインして終了します。

失敗したサージ アップデートを管理する

失敗したアップデートに対処する方法は 3 つあります。

  1. アップデートを続ける: 最初に失敗した試行と同じターゲット ノードプールの設定を使用して、失敗したアップデートを続行できます。
  2. ロールバック: ロールバック コマンドを使用して、ノードプールを元の状態に戻します。
  3. 変更して再起動する: サージ アップデートのパラメータを変更する場合は、既存のノードプールを削除してから、新しい設定で再作成する必要があります。ノードプールを削除する方法については、ノードプールを削除するをご覧ください。