このページでは、Google Kubernetes Engine（GKE）クラスタで使用できるノードのアップグレード戦略について説明します。
GKE Standard クラスタでは、ノードプールごとに次のいずれかのノード アップグレード戦略を構成できます。
- サージ アップグレード: ノードはローリング ウィンドウでアップグレードされます。一度にアップグレードできるノードの数と、アップグレードの中断の程度を制御できます。
- Blue/Green アップグレード: 新しいノード構成でワークロードの検証が完了するまで、既存のノードにロールバックできます。
Autopilot クラスタでは、GKE はサージ アップグレードを使用します。詳細については、Autopilot クラスタのアップグレード ページのサージ アップグレードをご覧ください。
Standard クラスタ ノードプールのアップグレード戦略を選択すると、速度、ワークロードの中断、リスクの軽減、費用の最適化のバランスを取ったプロセスを選択できます。環境に適したノードのアップグレード戦略については、サージ アップグレードを選択すると Blue/Green アップグレードを選択するをご覧ください。
どちらの方法でも、アップグレード設定を構成して、環境のニーズに基づいてプロセスを最適化できます。詳しくは、選択したアップグレード戦略を構成するをご覧ください。選択した戦略に、その戦略でノードをアップグレードするのに十分な割り当て、リソースの可用性、または予約容量があることを確認してください。詳細については、ノードのアップグレード用のリソースを確保するをご覧ください。
サージ アップグレード
サージ アップグレードはデフォルトのアップグレード戦略で、増分変更を処理できるアプリケーションに最適です。サージ アップグレードではローリング方式を使用します。ノードは不定の順序でアップグレードされます。新しく作成できるサージノードの数を maxSurge に設定し、一度に中断できる既存のノードの数を maxUnavailable で設定して、環境に最適な速度と中断のバランスを見つけます。
また、サージ アップグレードはクラスタ オートスケーラーと連動して、アップグレード中のノードの変更を防止します。
環境に合わせてサージ アップグレードを選択する
コストの最適化が重要であり、ワークロードが 60 分間以内のシャットダウンを許容できる場合は、ノードプールのサージ アップグレードを選択することをおすすめします。
サージ アップグレードは次のシナリオに最適です。
- アップグレードの速度を最適化したい場合。
- ワークロードの中断が許容され、正常終了を最大 60 分間待つことができる場合。
- 新しいノードの作成を最小限に抑えてコストを抑える場合。
GKE がサージ アップグレードを使用する場合
有効にした場合、GKE は、次のタイプの変更が発生したときにサージ アップグレードを使用します。
- バージョンの変更（アップグレード）
- ノードのマシン属性（マシンタイプ、ディスクタイプ、ディスクサイズなど）を変更してノードを垂直方向にスケーリングする
- イメージの種類の変更
- IP ローテーション
- 認証情報のローテーション
- ネットワーク ポリシーの作成
- 画像ストリーミングの有効化
- ネットワーク パフォーマンス構成の更新
- gVNIC の有効化
- ノードシステム構成の変更
- 機密ノード
他の変更（既存のノードプールのノードラベルや taint への更新の適用など）では、ノードの再作成が不要であるため、サージ アップグレードは使用しません。
サージ アップグレードの設定について
サージ アップグレードの設定を使用して、クラスタのメンテナンス中のノードプールの速度と中断の適切なバランスを選択します。Standard ノードプールでサージ アップグレード パラメータを変更することで、GKE が一度にアップグレードを試みるノードの数を変更できます。
サージ アップグレードの動作は maxSurge と maxUnavailable の設定によって決まります。これらの設定により、ローリング ウィンドウ内に上記のステップで同時にアップグレードされるノードの数が決まります。
maxSurge: GKE は既存のサージノードを削除する前に新しいサージノードを作成する
maxSurge を設定して、アップグレード中にノードプールに追加できるサージノードの最大数をゾーンごとに選択します。これにより、既存のノードで実行されているワークロードが新しいノードにすぐに移行される可能性が高くなります。デフォルトは 1 です。1 つのノードをアップグレードするために、GKE は次の処理を行います。
- 新しいノードをプロビジョニングします。
- 新しいノードの準備ができるまで待機します。
- 既存のノードを閉鎖します。
- 最大で 1 時間、PodDisruptionBudget と GracefulTerminationPeriod の設定を使用して既存のノードをドレインします。
- 既存のノードを削除します。
GKE でサージノードを作成するには、追加のノードを一時的に作成するためのリソースがプロジェクトに存在する必要があります。追加の容量がない場合、リソースが使用可能になるまで GKE はノードのアップグレードを開始しません。詳細については、サージ アップグレードのリソースをご覧ください。
maxUnavailable: GKE は既存のノードを再作成できないようにする
maxUnavailable を設定して、アップグレード中に同時に使用不能にできるノードの最大数をゾーンごとに選択します。デフォルトは 0 です。容量のあるノードがほかにない場合、既存のノードで実行されているワークロードは、そのノードがアップグレードされるまで待機しなければなりません。1 つのノードをアップグレードするために、GKE は次の処理を行います。
- 既存のノードを閉鎖します。
- 最大で 1 時間、PodDisruptionBudget と GracefulTerminationPeriod の設定を使用して既存のノードをドレインします。
- 新しい構成で既存のノードを再作成します。
- 既存のノードの準備ができるまで待機します。
- アップグレードされた既存ノードの閉鎖を解除します。
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 分以上かかるときに段階的なロールアウトを行う場合。
- ワークロードで中断を許容できない場合。
- リソース使用量の増加による一時的な費用の増加が許容される場合。
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 アップグレードをキャンセルすると、アップグレードは現在のフェーズで一時停止します。キャンセル後、再開またはロールバックできます。このフェーズでロールバックすると Blue プールのドレインが停止され、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 ノードプールのアップグレードを完了するをご覧ください。