このページでは、Google Kubernetes Engine（GKE）クラスタで使用できるノードのアップグレード戦略について説明します。
GKE Standard クラスタでは、ノードプールごとに次のいずれかのノード アップグレード戦略を構成できます。
- サージ アップグレード: ノードはローリング ウィンドウでアップグレードされます。一度にアップグレードできるノードの数と、アップグレードの中断の程度を制御できます。
- Blue/Green アップグレード: 新しいノード構成でワークロードの検証が完了するまで、既存のノードにロールバックできます。
- 自動スケーリングされる Blue/Green アップグレード（プレビュー）: ワークロードをより長く実行しながら、アイドル状態または使用率の低いノードのコストを最小限に抑えることが可能です。
GKE は、これらの特定のシナリオに対して次の戦略を選択します。
- Autopilot クラスタでは、GKE はサージ アップグレードを使用します。詳細については、Autopilot クラスタのアップグレード ページのサージ アップグレードをご覧ください。
- Flex Start VM を使用するノードの場合、GKE は短時間のアップグレードを使用します。キュー方式のプロビジョニングを使った Flex-Start は、Flex-Start プレビュー版リリースで導入された新しいフラグに対応しています。Flex Start は Dynamic Workload Scheduler によって動作しています。
Standard クラスタ ノードプールのアップグレード戦略を選択すると、速度、ワークロードの停止、リスク軽減、費用の最適化のバランスを取ったプロセスを選択できます。環境に適したノードのアップグレード戦略の詳細については、以下をご覧ください。
どの方法でも、アップグレード設定を構成して、環境のニーズに基づいてプロセスを最適化できます。詳細については、選択したアップグレード戦略を構成するをご覧ください。選択した戦略に、その戦略でノードをアップグレードするのに十分な割り当て、リソースの可用性、または予約容量があることを確認してください。詳細については、ノードのアップグレード用のリソースを確保するをご覧ください。
サージ アップグレード
サージ アップグレードはデフォルトのアップグレード戦略で、増分変更を処理できるアプリケーションに最適です。サージ アップグレードではローリング方式を使用します。ノードは不定の順序でアップグレードされます。新しく作成できるサージノードの数を maxSurge に設定し、一度に中断できる既存のノードの数を maxUnavailable で設定して、環境に最適な速度と中断のバランスを見つけます。
また、サージ アップグレードはクラスタ オートスケーラーと連動して、アップグレード中のノードの変更を防止します。
環境のサージ アップグレードを選択する場合
コストの最適化が重要であり、ワークロードが 60 分間以内のシャットダウンを許容できる場合は、ノードプールのサージ アップグレードを選択することをおすすめします。
サージ アップグレードは次のシナリオに最適です。
- アップグレードの速度を最適化したい場合。
- ワークロードの中断が許容され、正常終了を最大 60 分間待つことができる場合。
- 新しいノードの作成を最小限に抑えてコストを抑える場合。
GKE がサージ アップグレードを使用する場合
有効にした場合、GKE は、次のタイプの変更が発生したときにサージ アップグレードを使用します。
- バージョンの変更（アップグレード）
- ノードのマシン属性（マシンタイプ、ディスクタイプ、ディスクサイズなど）を変更してノードを垂直方向にスケーリングする
- イメージの種類の変更
- IP ローテーション
- 認証情報のローテーション
- ネットワーク ポリシーの作成
- 画像ストリーミングの有効化
- ネットワーク パフォーマンス構成の更新
- gVNIC の有効化
- ノードシステム構成の変更
- 機密ノード
他の変更（既存のノードプールのノードラベルや taint への更新の適用など）では、ノードの再作成が不要であるため、サージ アップグレードは使用しません。
サージ アップグレードの設定について
サージ アップグレードの設定を使用して、クラスタのメンテナンス中のノードプールの速度と中断の適切なバランスを選択します。Standard ノードプールでサージ アップグレード パラメータを変更することで、GKE が一度にアップグレードを試みるノードの数を変更できます。
サージ アップグレードの動作は maxSurge と maxUnavailable の設定によって決まります。これらの設定により、ローリング ウィンドウ内に上記のステップで同時にアップグレードされるノードの数が決まります。
maxSurge: GKE は既存のサージノードを削除する前に新しいサージノードを作成する
maxSurge を設定して、アップグレード中にノードプールに追加できるサージノードの最大数をゾーンごとに選択します。これにより、既存のノードで実行されているワークロードが新しいノードにすぐに移行される可能性が高くなります。デフォルトは 1 です。1 つのノードをアップグレードするために、GKE は次の処理を行います。
- 新しいノードをプロビジョニングします。
- 新しいノードの準備ができるまで待機します。
- 既存のノードを閉鎖します。
- 最大で 1 時間、PodDisruptionBudget と GracefulTerminationPeriod の設定を使用して既存のノードをドレインします。1 時間後、残りの Pod は強制的に削除され、アップグレードが続行されます。
- 既存のノードを削除します。
GKE でサージノードを作成するには、追加のノードを一時的に作成するためのリソースがプロジェクトに存在する必要があります。追加の容量がない場合、リソースが使用可能になるまで GKE はノードのアップグレードを開始しません。詳細については、サージ アップグレードのリソースをご覧ください。
maxUnavailable: GKE は既存のノードを再作成できないようにする
maxUnavailable を設定して、アップグレード中に同時に使用不能にできるノードの最大数をゾーンごとに選択します。デフォルトは 0 です。容量のあるノードがほかにない場合、既存のノードで実行されているワークロードは、そのノードがアップグレードされるまで待機しなければなりません。1 つのノードをアップグレードするために、GKE は次の処理を行います。
- 既存のノードを閉鎖します。
- 最大で 1 時間、PodDisruptionBudget と GracefulTerminationPeriod の設定を使用して既存のノードをドレインします。1 時間後、残りの Pod は強制的に削除され、アップグレードが続行されます。
- 新しい構成で既存のノードを再作成します。
- 既存のノードの準備ができるまで待機します。
- アップグレードされた既存ノードの閉鎖を解除します。
GKE が既存のノードを再作成するときに、その容量が予約によるものではないと、GKE はノードの容量を一時的に解放します。つまり、容量が限られていると、既存の容量が失われる可能性があります。このため、リソースが制限されている環境では、予約済みノードを使用する場合にのみ、この設定を使用してください。詳細については、リソースが制限された環境でのアップグレードをご覧ください。
maxSurge 設定と maxUnavailable 設定の使用例
たとえば、GKE クラスタに 5 つのノードを含むシングルゾーン ノードプールがあり、サージ アップグレード構成が maxSurge=2;maxUnavailable=1 になっているとします。
このノードプールでサージ アップグレードを行うと、GKE はローリング ウィンドウ内に 2 つのアップグレード済みノードを作成し、一度に 1 つの既存ノードを中断します。アップグレードされたノードの準備ができると、GKE は最大で 3 つの既存のノードを停止します。アップグレード プロセス中に、ノードプールには 4～7 個のノードが含まれます。
サージ アップグレードの設定に関する考慮事項
サージ アップグレードを構成する前に、次の点を考慮してください。
- サージ アップグレードによって作成されたノードは、 Google Cloudのリソースの割り当て、リソースの可用性、特定の予約アフィニティを持つノードプールに対する予約容量の対象となります。リソースが制限されている環境の場合は、リソースが制限された環境でのアップグレードをご覧ください。
- GKE が同時にアップグレードするノードの数は、
maxSurgeとmaxUnavailableの合計です。同時にアップグレードできるノードの最大数は 20 です。また、サージ アップグレードはクラスタ オートスケーラーと連動して、アップグレード中のノードの変更を防止します。 - GKE はマルチゾーン ノードプールをアップグレードします。アップグレードは一度に 1 つのゾーンで行われます。サージ アップグレード パラメータは、ゾーン内のノード数までしか適用できません。同時にアップグレードできるノードの最大数は、
maxSurgeとmaxUnavailableの合計以下で、ゾーン内のノード数以下になります。 - ノードプールで Spot VM を使用している場合、GKE は Spot VM を使用してサージノードを作成しますが、Spot VM の準備が完了するのを待たずに既存ノードの閉鎖とドレインを行います。詳細については、Spot VM を使用して Standard ノードプールをアップグレードするをご覧ください。
速度と停止のバランスを取るためにサージ アップグレードの設定を調整する
次の表に、さまざまな構成を理解できるように、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 分以上かかるときに段階的なロールアウトを行う場合。
- ワークロードで中断を許容できない場合。
- リソース使用量の増加による一時的な費用の増加が許容される場合。
Blue / Green アップグレードは、メンテナンスの時間枠を超えても完了するまで続行されます。詳細については、ノードのアップグレード戦略とメンテナンスの時間枠の連携方法をご覧ください。
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_DURATION と NODE_POOL_SOAK_DURATION を使用すると、Pod が削除されるまでの時間を延長できます。
バッチのサイズは、次のいずれかの設定で制御できます。
BATCH_NODE_COUNT: バッチでドレインするノードの絶対数。BATCH_PERCENT: バッチでドレインするノードの割合。0～1 の小数値で表されます。割合が整数でない場合は、GKE は最も近いノード数に切り下げます（最小値は 1 ノードです）。
いずれかの設定が 0 に設定されている場合、GKE はこのフェーズをスキップして、ノードプールのソーキング フェーズに進みます。
さらに、BATCH_SOAK_DURATION によってそれぞれのバッチドレインでソーキング時間を制御できます。この期間は秒単位で定義され、デフォルトは 0 秒です。
このフェーズでは、必要に応じてアップグレードをキャンセルできます。Blue/Green アップグレードをキャンセルすると、アップグレードは現在のフェーズで一時停止します。キャンセル後、再開またはロールバックできます。前のバッチがすでにドレインされていて、アップグレードを再開すると、そのバッチの BATCH_SOAK_DURATION が適用されずに、次のバッチのノードがすぐに処理されることがあります。このフェーズでロールバックすると、Blue プールのドレインが停止し、閉鎖が解除されます。その後、ワークロードを Blue プールで再スケジュールでき（保証はされません）、Green プールはドレインされて削除されます。
フェーズ 4: ノードプールをソーキングする
このフェーズは、Blue プールノードがドレインされた後、ワークロードの正常性を確認するために使用されます。
ソーク時間は NODE_POOL_SOAK_DURATION 秒単位で設定されます。デフォルトでは 1 時間（3,600 秒）に設定されています。ソーキングの合計期間が 7 日間（604,800 秒）に達すると、Blue プールを削除するフェーズが直ちに開始されます。
ソーキングの合計時間は、NODE_POOL_SOAK_DURATION に BATCH_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 ノードプールのアップグレードを完了するをご覧ください。
自動スケーリングされる Blue/Green アップグレード
自動スケーリングされる Blue/Green アップグレードは、中断に耐性のないワークロードが強制排除されるまでの時間を最大化し、費用を最小限に抑える、別の種類のアップグレード戦略です。この戦略は、標準の Blue/Green アップグレードから派生したものです。ただし、自動スケーリングされる Blue/Green アップグレードでは、GKE は、安全に強制排除できないとマークされたワークロードを含むノードを、ノードの閉鎖から最大 7 日間ドレインしません。
次のセクションでは、どのような場合にこの戦略を選択するか、この戦略の Blue/Green アップグレードの実装が標準の Blue/Green アップグレードとどのように異なるか、この戦略を使用する場合のベスト プラクティスについて説明します。
自動スケーリングされる Blue/Green アップグレードを使用するには、自動スケーリングされる Blue/Green アップグレードの構成をご覧ください。
環境に自動スケーリングされる Blue/Green アップグレードを選択する場合
強制排除されるまでの時間を最長にし、早期に再スケジュールする必要のないワークロードがある場合は、ノードプールに自動スケーリングされる Blue/Green アップグレードを選択することをおすすめします。
次のシナリオに該当する場合は、自動スケーリングされる Blue/Green アップグレードが最適です。
- 完了するまで実行する必要のあるバッチ ワークロード（AI/ML トレーニングなど）がある。
- アイドル状態のノードまたは十分に活用されていないノードの数を最小限に抑えることで、標準の Blue/Green アップグレードと比較して費用を最小限に抑える必要がある。
- Pod の即時再スケジューリングや、以前のノード構成への即時ロールバックを保証する必要がない。
ワークロードを新しいノードに再スケジュールする時間と、以前のノード構成にロールバックする機能を最小限にする必要がある場合は、標準の Blue/Green アップグレードを選択します。
自動スケーリングされる Blue/Green アップグレードは、標準の Blue/Green アップグレードと同様に、メンテナンスの時間枠を超えても完了するまで続行されます。詳細については、ノードのアップグレード戦略とメンテナンスの時間枠の連携方法をご覧ください。
自動スケーリングされる Blue/Green アップグレードのフェーズ
GKE が自動スケーリングされる Blue/Green アップグレードでノードプールをアップグレードする場合のフェーズは、標準の Blue/Green アップグレードと異なります。標準のアップグレード戦略のフェーズについては、Blue/Green アップグレードのフェーズをご覧ください。
自動スケーリングされる Blue/Green アップグレード ポリシーが有効になっている場合、GKE はオペレーション中に次の処理を行います。
- GKE が Green プールを作成します。ただし、Green プールはゼロノードから開始します。後のフェーズで GKE が Blue プールから Pod を強制排除すると、クラスタ オートスケーラーが Green プールをスケールアップして、それらの Pod を実行します。
- GKE が Blue プールを閉鎖します。
GKE は、0～7 日（デフォルトは 3 日）の期間待機します。この期間は構成できます。この間、GKE は次の処理を行います。
- クラスタ オートスケーラーは使用率の低い Blue プールノードをスケールダウンします（ただし、そのノードに
"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"アノテーションを実行する Pod がない場合）。このアノテーションがある場合は、スピンダウンに多くの時間を必要とするワークロードも、確実に実行を継続できます。クラスタ オートスケーラーが使用率の低いノードを積極的にスケールダウンしない場合は、クラスタ オートスケーラーがスケールダウンしない問題のトラブルシューティングと Pod のスケジューリングと停止を検討するをご覧ください。 - GKE は、Blue プールをスケールダウンするときに、
--min-nodesパラメータと--total-min-nodesパラメータの自動スケーリングの制限を無視します。この期間が完了する前にすべての Blue プールノードがスケールダウンされると、GKE は直ちに Blue プールを削除するフェーズに進みます。
- クラスタ オートスケーラーは使用率の低い Blue プールノードをスケールダウンします（ただし、そのノードに
GKE が Blue プールをドレインします。残りの Blue プールノードを一度に最大 20 個並行してドレインします。GKE は、
PodDisruptionBudget設定を最大 1 時間、terminationGracePeriodSeconds設定を最大 24 時間適用します。GKE がソーク ノードプール フェーズをスキップします。
GKE が Blue プールを削除します。
自動スケーリングされる Blue/Green アップグレードのベスト プラクティス
次のセクションでは、自動スケーリングされる Blue/Green アップグレード中にワークロードの停止を最小限に抑えるためのクラスタ、ノードプール、Pod に関するベスト プラクティスについて説明します。
クラスタとノードプールの構成
- GKE は、Green プールをスケールアップするときに自動スケーリングの制限に従います。GKE がワークロードを Blue プールから Green プールに再スケジュールするときに、クラスタ オートスケーラーが Green プールをスケールアップできるように、
--max-nodesパラメータまたは--total-max-nodesパラメータに十分な値を設定します。GKE は、Blue プールをスケールダウンするときに--min-nodesパラメータまたは--total-min-nodesパラメータを無視します。 - GKE で使用率の低い Blue プールのノードをより積極的にスケールダウンする場合は、
optimize-utilization自動スケーリング プロファイルを構成します。詳細については、自動スケーリング プロファイルをご覧ください。 - ノードの自動プロビジョニングで作成されたノードプールを、自動スケーリングされる Blue/Green アップグレードを使用するように更新しないでください。また、自動プロビジョニングされた新しいノードプールに自動スケーリングされる Blue/Green アップグレードを使用するようにクラスタを構成しないでください。
Pod の構成
- Blue プールをドレインする前の一時停止期間中に Pod が強制排除されないようにするには、その Pod に
"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"アノテーションを追加します。このアノテーションにより、Pod のノードの使用率が低い場合でも、クラスタ オートスケーラーによる Pod の強制排除を防ぐことができます。 - 標準の Blue/Green アップグレードと同様に、Bule プール内のノードから強制排除された Pod が、Green プール内のノードにのみ再スケジュールされるようにするには、ワークロードに
cloud.google.com/gke-nodepool:NODE_POOL_NAMEラベルの nodeSelector を追加します。このラベルを省略して、クラスタで他のノードプールを保持する場合は、強制排除された Pod が他のノードプールのノードにスケジュールされる可能性があります。
自動スケーリングされる Blue/Green アップグレードの制限事項
- 自動スケーリングされる Blue/Green アップグレードは、キャンセルして再開できます。ただし、キャンセルされたアップグレードをロールバックすることはできません。
- Blue プールが閉鎖されてドレインされたときに、割り当てと上限またはリソースの可用性が原因でクラスタ オートスケーラーが Green プールをスケールアップできない場合、Pod が一時的にスケジュールできなくなる可能性があります。これは、Green プールが 0 ノードで作成されているためです。
- クラスタのコントロール プレーンがバージョン 1.34.0-gke.2201000 以降を実行し、クラスタ オートスケーラーが有効になっている場合にのみ、自動スケーリングされる Blue/Green アップグレードが有効なノードプールのみをアップグレードできます。
GKE が自動スケーリングされる Blue/Green アップグレードを使用する場合
GKE は、標準の Blue/Green アップグレードと同じ種類の変更に、自動スケーリングされる Blue/Green アップグレードを使用します。GKE が標準の Blue/Green アップグレード戦略を使用する変更の種類について詳しくは、GKE が Blue/Green アップグレードを使用する場合をご覧ください。
クラスタ オートスケーラーと自動スケーリングされる Blue/Green アップグレードの連携
自動スケーリングされる Blue/Green アップグレードを構成するには、クラスタ オートスケーラーも構成する必要があります。
自動スケーリングされる Blue/Green アップグレードを使用する場合、クラスタ オートスケーラーは次の処理を行います。
- GKE が Blue プールのドレインを待機するフェーズでは、Blue プールはスケールアップされず、ノードの使用率が低下した場合にのみクラスタ オートスケーラーによってスケールダウンされます。クラスタ オートスケーラーは、
--min-nodesパラメータまたは--total-min-nodesパラメータを考慮せずに、ブループールをゼロにスケールダウンできます。他のすべてのフェーズでは、クラスタ オートスケーラーは Blue プールをスケールアップまたはスケールダウンしません。 - クラスタ オートスケーラーは、アップグレード戦略のすべてのフェーズで必要に応じて、Green プールを 0 個のノードからスケールアップするか、
--min-nodes設定までスケールダウンします。
短時間のアップグレード（Flex Start とキューに格納されたプロビジョニングのみ）
短時間のアップグレードは、Flex Start VM を使用するノードとキューに格納されたプロビジョニングを使用するノード（1.32.2-gke.1652000 以降）でのみ使用されるノードのアップグレード方法です。どちらも Dynamic Workload Scheduler を基盤としています。短期アップグレードを使用するノードの詳細については、Dynamic Workload Scheduler での GPU の入手性についてをご覧ください。
GKE は、Autopilot クラスタの Standard ノードプールとノードのグループに短時間のアップグレード戦略を使用します。
この戦略では、GKE は既存のワークロードを中断することなく、これらの限定ランタイム ノードをアップグレードします。この戦略は次のように機能します。
- 既存のノードは、プリエンプトされるまで実行されます。
- 新しいノードは新しいノード構成を使用します。
- ノードは、最大 7 日間かけて、既存の構成の実行から新しい構成の実行に移行します。
GKE は、Flex Start VM を使用するノードにこの戦略を自動的に構成します。この戦略には構成設定がありません。
GKE が短時間のアップグレードを使用する場合
GKE は、短時間のアップグレードを適用するように Flex Start VM を使用するノードを自動的に設定します。キューに格納されたプロビジョニングのみを使用し、GKE バージョン 1.32.2-gke.1652000 以降のクラスタで実行されるノードも、短時間のアップグレードを使用します。
短時間のアップグレードを使用する Standard ノードプールと Autopilot クラスタ内のノードグループの場合、GKE は、サージ アップグレードが使用される状況でこの戦略を使用します。GKE は、サージ アップグレードを使用する方法と同様に、ノードのアップグレード（バージョン変更）に加えて、他のタイプのノードの更新にも短時間のアップグレードを使用します。詳細については、サージ アップグレードを使用する場合をご覧ください。