ノードのアップグレード戦略


このページでは、Google Kubernetes Engine(GKE)クラスタで使用できるノードのアップグレード戦略について説明します。

GKE Standard クラスタでは、ノードプールごとに次のいずれかのノード アップグレード戦略を構成できます。

  • サージ アップグレード: ノードはローリング ウィンドウでアップグレードされます。一度にアップグレードできるノードの数と、アップグレードの中断の程度を制御できます。
  • Blue/Green アップグレード: 新しいノード構成でワークロードの検証が完了するまで、既存のノードにロールバックできます。

Autopilot クラスタでは、GKE はサージ アップグレードを使用します。詳細については、Autopilot クラスタのアップグレード ページのサージ アップグレードをご覧ください。

Standard クラスタ ノードプールのアップグレード戦略を選択すると、速度、ワークロードの中断、リスクの軽減、費用の最適化のバランスを取ったプロセスを選択できます。環境に適したノードのアップグレード戦略については、サージ アップグレードを選択するBlue/Green アップグレードを選択するをご覧ください。

どちらの方法でも、アップグレード設定を構成して、環境のニーズに基づいてプロセスを最適化できます。詳しくは、選択したアップグレード戦略を構成するをご覧ください。選択した戦略に、その戦略でノードをアップグレードするのに十分な割り当て、リソースの可用性、または予約容量があることを確認してください。詳細については、ノードのアップグレード用のリソースを確保するをご覧ください。

サージ アップグレード

サージ アップグレードはデフォルトのアップグレード戦略で、増分変更を処理できるアプリケーションに最適です。サージ アップグレードではローリング方式を使用します。ノードは不定の順序でアップグレードされます。新しく作成できるサージノードの数を maxSurge に設定し、一度に中断できる既存のノードの数を maxUnavailable で設定して、環境に最適な速度と中断のバランスを見つけます。

また、サージ アップグレードはクラスタ オートスケーラーと連動して、アップグレード中のノードの変更を防止します。

環境に合わせてサージ アップグレードを選択する

コストの最適化が重要であり、ワークロードが 60 分間以内のシャットダウンを許容できる場合は、ノードプールのサージ アップグレードを選択することをおすすめします。

サージ アップグレードは次のシナリオに最適です。

  • アップグレードの速度を最適化したい場合。
  • ワークロードの中断が許容され、正常終了を最大 60 分間待つことができる場合。
  • 新しいノードの作成を最小限に抑えてコストを抑える場合。

GKE がサージ アップグレードを使用する場合

有効にした場合、GKE は、次のタイプの変更が発生したときにサージ アップグレードを使用します。

他の変更(既存のノードプールのノードラベルや taint への更新の適用など)では、ノードの再作成が不要であるため、サージ アップグレードは使用しません。

サージ アップグレードの設定について

サージ アップグレードの設定を使用して、クラスタのメンテナンス中のノードプールの速度と中断の適切なバランスを選択します。Standard ノードプールでサージ アップグレード パラメータを変更することで、GKE が一度にアップグレードを試みるノードの数を変更できます。

サージ アップグレードの動作は maxSurgemaxUnavailable の設定によって決まります。これらの設定により、ローリング ウィンドウ内に上記のステップで同時にアップグレードされるノードの数が決まります。

maxSurge: GKE は既存のサージノードを削除する前に新しいサージノードを作成する

maxSurge を設定して、アップグレード中にノードプールに追加できるサージノードの最大数をゾーンごとに選択します。これにより、既存のノードで実行されているワークロードが新しいノードにすぐに移行される可能性が高くなります。デフォルトは 1 です。1 つのノードをアップグレードするために、GKE は次の処理を行います。

  1. 新しいノードをプロビジョニングします。
  2. 新しいノードの準備ができるまで待機します。
  3. 既存のノードを閉鎖します。
  4. 最大で 1 時間、PodDisruptionBudgetGracefulTerminationPeriod の設定を使用して既存のノードをドレインします。
  5. 既存のノードを削除します。

GKE でサージノードを作成するには、追加のノードを一時的に作成するためのリソースがプロジェクトに存在する必要があります。追加の容量がない場合、リソースが使用可能になるまで GKE はノードのアップグレードを開始しません。詳細については、サージ アップグレードのリソースをご覧ください。

maxUnavailable: GKE は既存のノードを再作成できないようにする

maxUnavailable を設定して、アップグレード中に同時に使用不能にできるノードの最大数をゾーンごとに選択します。デフォルトは 0 です。容量のあるノードがほかにない場合、既存のノードで実行されているワークロードは、そのノードがアップグレードされるまで待機しなければなりません。1 つのノードをアップグレードするために、GKE は次の処理を行います。

  1. 既存のノードを閉鎖します。
  2. 最大で 1 時間、PodDisruptionBudgetGracefulTerminationPeriod の設定を使用して既存のノードをドレインします。
  3. 新しい構成で既存のノードを再作成します。
  4. 既存のノードの準備ができるまで待機します。
  5. アップグレードされた既存ノードの閉鎖を解除します。

GKE が既存のノードを再作成するときに、その容量が予約によるものではないと、GKE はノードの容量を一時的に解放します。つまり、容量が限られていると、既存の容量が失われる可能性があります。このため、リソースが制限されている環境では、予約済みノードを使用する場合にのみ、この設定を使用してください。詳細については、リソースが制限された環境でのアップグレードをご覧ください。

maxSurge 設定と maxUnavailable 設定の使用例

たとえば、GKE クラスタに 5 つのノードを含むシングルゾーン ノードプールがあり、サージ アップグレード構成が maxSurge=2;maxUnavailable=1 になっているとします。

このノードプールでサージ アップグレードを行うと、GKE はローリング ウィンドウ内に 2 つのアップグレード済みノードを作成し、一度に 1 つの既存ノードを中断します。アップグレードされたノードの準備ができると、GKE は最大で 3 つの既存のノードを停止します。アップグレード プロセス中に、ノードプールには 4~7 個のノードが含まれます。

サージ アップグレードの設定に関する考慮事項

サージ アップグレードを構成する前に、次の点を考慮してください。

速度と中断のバランスを取るためにサージ アップグレードの設定を調整する

次の表に、さまざまな構成を理解できるように、4 つの異なるアップグレード プロファイルの例を示します。

説明 構成 一般的なユースケース
バランスが取れている(デフォルト)、速度は遅いが中断が少ない maxSurge=1 maxUnavailable=0 ほとんどのワークロード
高速。サージリソースなし。中断多発。 maxSurge=0 maxUnavailable=20 ジョブが完了まで実行された後の大規模なノードプール
高速。サージリソース大。中断少なめ。 maxSurge=20 maxUnavailable=0 大規模なノードプール
最も低速で中断が発生、サージリソースなし maxSurge=0 maxUnavailable=1 リソースが制限されているノードプール(予約あり)

バランス(デフォルト)

サージ アップグレードを活用する最も簡単な方法は、デフォルトの構成(maxSurge=1;maxUnavailable=0.)を使用することです。この構成では、一度に 1 つのサージノードのみが追加されるため、アップグレードはゆっくりと進行します。つまり、一度にアップグレードされるノードは 1 つだけです。Pod は新しいサージノードですぐに再起動できます。この構成で必要となるのは、一時的に新しいノードを 1 つ作成することだけです。

高速、サージリソースなし

大規模なノードプールがあり、ワークロードが中断の影響を受けない場合は(完了まで実行されたバッチジョブなど)、構成(maxSurge=0;maxUnavailable=20)を使用して、追加リソースを使用せずに速度を最大化します。この構成では、追加のサージノードを起動することなく、20 ノードを同時にアップグレードできます。

高速、中断少なめ

ワークロードが中断の影響を受けやすく、PodDisruptionBudgets(PDB)を設定していて、externalTrafficPolicy: Local を使用していない(並列ノードのドレインでは機能しない)場合は、maxSurge=20;maxUnavailable=0 を使用してアップグレードの速度を上げることが可能です。この構成では、PDB が一定時間に空にできる Pod の数が制限され、20 ノードを並行してアップグレードできます。PDB の構成はさまざまですが、ノードプールで実行されている 1 つまたは複数のワークロードに対して PDB を maxUnavailable=1 で作成していれば、一度に削除できるのはワークロードの 1 つの Pod のみとなり、これにより、アップグレード全体の並列性が制限されます。この構成では、リソースで一時的に 20 個のノードを作成する必要があります。

低速だがサージリソースがない

追加のリソースを使用できない場合は、maxSurge=0;maxUnavailable=1 を使用して一度に 1 つのノードを再作成できます。

進行中のサージ アップグレードを制御する

サージ アップグレードでは、アップグレードの進行中にコマンドを使用してサージ アップグレードを制御できます。アップグレード プロセスをより細かく制御するには、Blue/Green アップグレードの使用をおすすめします。

サージ アップグレードをキャンセル(一時停止)する

アップグレード プロセス中、いつでも進行中のサージ アップグレードをキャンセルできます。アップグレードをキャンセルするとアップグレードが一時停止し、GKE による新しいノードのアップグレードは停止しますが、アップグレード済みのノードのアップグレードは自動的にロールバックされません。アップグレードをキャンセルした後で、再開またはロールバックできます。

アップグレードをキャンセルすると、GKE は各ノードを次のように処理します。

  • アップグレードを開始したノードのアップグレードは完了します。
  • アップグレードを開始していないノードはアップグレードされません。
  • アップグレードがすでに完了したノードは影響を受けず、ロールバックされません。

ノードプールで、ノードが 2 つの異なるバージョンを実行している状態になる可能性があります。ノードプールで自動アップグレードが有効になっている場合、ノードプールの自動アップグレードを再びスケジュールできます。これにより、旧バージョンを実行しているノードプールで残りのノードがアップグレードされます。

ノードプールのアップグレードをキャンセルする方法について説明します。

サージ アップグレードを再開する

ノードプールのアップグレードがキャンセルされ、部分的にアップグレードされた状態になっている場合は、アップグレードを再開してノードプールのアップグレード プロセスを完了できます。これにより、元のオペレーションでアップグレードされなかった残りのノードがアップグレードされます。ノードプールのアップグレードを再開する方法についてご確認ください。

サージ アップグレードをロールバックする

ノードプールが部分的にアップグレードされた状態の場合は、ノードプールをロールバックして以前の状態に戻すことができます。正常にアップグレードされたノードプールをロールバックすることはできません。アップグレードを開始していないノードは影響を受けません。ノードプールのアップグレードをロールバックする方法をご確認ください。

アップグレードがすでに完了した後でノードプールを以前のバージョンにダウングレードする場合は、ノードプールのダウングレードをご覧ください。

Blue/Green アップグレード

Blue/Green アップグレードは、デフォルトのサージ アップグレード戦略に代わるアップグレード戦略です。Blue/Green アップグレードでは、GKE は、元のリソース(Blue ノード)のワークロードを強制排除する前に、新しいノード構成で新しいノードリソースのセット(Green ノード)を作成します。GKE は、ソーキング時間に達するまで、必要に応じてワークロードをロールバックするために Blue リソースを保持します。アップグレードのペースとソーキング時間は、環境のニーズに応じて調整できます。

この戦略では、アップグレード プロセスをより細かく制御できます。アップグレード中は元の環境が維持されるため、必要に応じて進行中のアップグレードをロールバックできます。ただし、このアップグレード戦略では、より多くのリソースが必要になります。元の環境が複製されるため、アップグレード中にノードプールで使用されるリソース数は 2 倍になります。

環境の Blue/Green アップグレードを選択する

ワークロードがアップグレードを許容できないときに、迅速なロールバックが必要な高可用性の本番環境ワークロードがあり、一時的なコストの増加が許容される場合は、ノードプールに対して Blue/Green アップグレードの使用を選択することをおすすめします。

Blue/Green アップグレードは、次のシナリオに適しています。

  • リスク回避が最も重要で、正常終了に 60 分以上かかるときに段階的なロールアウトを行う場合。
  • ワークロードで中断を許容できない場合。
  • リソース使用量の増加による一時的な費用の増加が許容される場合。

GKE が Blue/Green アップグレードを使用する場合

GKE ノードの場合、ノードの再作成が必要になるさまざまな構成の変更があります。有効にした場合、GKE は、次のタイプの変更が発生したときに Blue/Green アップグレードを使用します。

サージ アップグレードは、ノードの再作成が必要な他の機能に使用されます。詳細については、サージ アップグレードを使用する場合をご覧ください。

Blue/Green アップグレードのフェーズ

Blue/Green アップグレードでは、次の方法でプロセスをカスタマイズして制御できます。

このセクションでは、アップグレード プロセスのフェーズについて説明します。アップグレードの設定でフェーズの動作を調整し、コマンドでアップグレード プロセスを制御できます。

フェーズ 1: Green プールを作成する

このフェーズでは、ターゲット プールの下にあるゾーンごとに、新しいノード構成(新しいバージョンまたはイメージタイプ)でマネージド インスタンス グループ(MIG)の新しいセットが作成されます。

新しい Green リソースのプロビジョニングを開始する前に、割り当てが確認されます。

このフェーズでは、元の MIG(Blue プールとも呼ばれます)のクラスタ オートスケーラーがスケールアップまたはスケールダウンを停止します。Green プールは、このフェーズでのみスケールアップできます。

このフェーズでは、必要に応じてアップグレードをキャンセルできます。Blue/Green アップグレードをキャンセルすると、アップグレードは現在のフェーズで一時停止します。キャンセル後、再開またはロールバックできます。このフェーズでロールバックすると Green プールが削除されます。

フェーズ 2: Blue プールを閉鎖する

このフェーズでは、Blue プール(既存の MIG)内のすべての元のノードが閉鎖されます(スケジュール不可に設定されます)。既存のワークロードは引き続き実行されますが、既存のノードで新しいワークロードがスケジュールされることはありません。

このフェーズでは、必要に応じてアップグレードをキャンセルできます。Blue/Green アップグレードをキャンセルすると、アップグレードは現在のフェーズで一時停止します。キャンセル後、再開またはロールバックできます。このフェーズでロールバックを行うと、Bule プールの閉鎖が解除され、Green プールが削除されます。

フェーズ 3: Blue プールをドレインする

このフェーズでは、Blue プール(既存の MIG)の元のノードがバッチでドレインされます。Kubernetes がノードをドレインすると、ノードで実行されているすべての Pod に強制排除リクエストが送信されます。Pod が再スケジュールされます。ドレイン中に PodDisruptionBudget 違反または長い terminationGracePeriodSeconds が発生した Pod は、ノードが削除される Blue プールの削除フェーズで削除されます。このセクションと次のセクションで説明する BATCH_SOAK_DURATIONNODE_POOL_SOAK_DURATION を使用すると、Pod が削除されるまでの時間を延長できます。

バッチのサイズは、次のいずれかの設定で制御できます。

  • BATCH_NODE_COUNT: バッチでドレインするノードの絶対数。
  • BATCH_PERCENT: バッチでドレインするノードの割合。0~1 の小数値で表されます。割合が整数でない場合は、GKE は最も近いノード数に切り下げます(最小値は 1 ノードです)。

いずれかの設定が 0 に設定されている場合、GKE はこのフェーズをスキップして、ノードプールのソーキング フェーズに進みます。

さらに、BATCH_SOAK_DURATION によってそれぞれのバッチドレインでソーキング時間を制御できます。この期間は秒単位で定義され、デフォルトは 0 秒です。

このフェーズでは、必要に応じてアップグレードをキャンセルできます。Blue/Green アップグレードをキャンセルすると、アップグレードは現在のフェーズで一時停止します。キャンセル後、再開またはロールバックできます。このフェーズでロールバックすると Blue プールのドレインが停止され、Blue プールの閉鎖が解除されます。その後、ワークロードを Blue プールで再スケジュールでき(保証はされません)、Green プールは削除されます。

フェーズ 4: ノードプールをソーキングする

このフェーズは、Blue プールノードがドレインされた後、ワークロードの正常性を確認するために使用されます。

ソーク時間は NODE_POOL_SOAK_DURATION 秒単位で設定されます。デフォルトでは 1 時間(3,600 秒)に設定されています。ソーキングの合計期間が 7 日間(604,800 秒)に達すると、Blue プールを削除するフェーズが直ちに開始されます。

ソーキングの合計時間は、NODE_POOL_SOAK_DURATIONBATCH_SOAK_DURATION を掛けた値にバッチ数(BATCH_NODE_COUNT または BATCH_PERCENT のいずれかで決定)を掛けたものです。

このフェーズでは、アップグレードを完了することでアップグレードを終了し、残りのソーク時間をスキップできます。これにより、Blue プールのノードを削除するプロセスがすぐに開始されます。

この時点では、必要に応じてアップグレードをキャンセルすることもできます。Blue/Green アップグレードをキャンセルすると、アップグレードは現在のフェーズで一時停止します。キャンセル後、再開またはロールバックできます。

このフェーズでは、クラスタ オートスケーラーが Green プールを通常どおりスケールアップまたはスケールダウンできます。

フェーズ 5: Blue プールを削除する

ソーキング時間が期限切れになると、Blue プールノードがターゲット プールから削除されます。このフェーズは一時停止できません。また、このフェーズでは強制排除を使用せず、Pod の削除を試みます。強制排除とは異なり、削除は PDB を尊重せず、Pod を強制的に削除します。この削除により、Pod の terminationGracePeriodSeconds は最大 60 分になります。最後の Pod の削除が行われると、Blue プールノードがノードプールから削除されます。

このフェーズが完了すると、ノードプールには更新された構成(バージョンまたはイメージタイプ)の新しいノードのみが存在します。

クラスタ オートスケーラーと Blue/Green アップグレードの連携

Blue/Green アップグレードのフェーズでは、元の Blue プールのスケールアップやスケールダウンは行われません。新しい Green プールが作成されると、ノードプールのソーキング フェーズまでスケールアップできます。このフェーズでは、スケールアップまたはスケールダウンを行うことができます。アップグレードがロールバックされるときに、追加の容量が必要になると、このプロセスで元の Blue プールがスケールアップされる可能性があります。

進行中の Blue/Green アップグレードを制御する

Blue/Green アップグレードでは、アップグレードの進行中にコマンドを実行してアップグレードを制御できます。ワークロードを古いノード構成にロールバックする必要があると判断した場合などに、プロセスをきめ細かく制御できます。

Blue/Green アップグレードをキャンセル(一時停止)する

Blue/Green アップグレードをキャンセルすると、現在のフェーズでアップグレードが一時停止されます。このコマンドは、Blue プールを削除するフェーズを除くすべてのフェーズで使用できます。キャンセルすると、リクエストが発行されたフェーズに基づいて中間ステータスのノードプールが一時停止します。

ノードプールのアップグレードをキャンセルする方法について説明します。

アップグレードをキャンセルした後で、再開またはロールバックのいずれかを選択できます。

Blue/Green アップグレードを再開する

アップグレードを続行できると判断した場合は、処理を再開します。

再開する場合、アップグレード処理は一時停止した中間フェーズから続行されます。ノードプールのアップグレードを再開する方法については、ノードプールのアップグレードを再開するをご覧ください。

Blue/Green アップグレードをロールバックする

アップグレードを進めるべきでないと判断し、ノードプールを元の状態に戻す場合は、ロールバックを行います。ノードプールのアップグレードをロールバックする方法については、ノードプールのアップグレードをロールバックするをご覧ください。

ロールバックのワークフローでは、プロセスが逆になり、ノードプールを元の状態に戻します。Blue プールの閉鎖が解除され、ワークロードが再スケジュールされる可能性があります。このプロセスで、クラスタ オートスケーラーは必要に応じて Blue プールをスケールアップします。Green プールはドレインされ、削除されます。

アップグレードがすでに完了した後でノードプールを以前のバージョンにダウングレードする場合は、ノードプールのダウングレードをご覧ください。

Blue/Green アップグレードを完了する

新しいノード構成でワークロードをさらに検証する必要がないと判断した場合は、ソーキング フェーズでアップグレードを完了し、古いノードを削除できます。アップグレードを完了すると、ソーキング フェーズの残りの部分がスキップされ、Blue プールを削除するフェーズに進みます。

complete コマンドの使用方法については、Blue/Green ノードプールのアップグレードを完了するをご覧ください。

次のステップ