Autopilot クラスタのアップグレード

このページでは、Google Kubernetes Engine（GKE）Autopilot クラスタでの自動アップグレードの仕組みについて説明します。関連するタスクや設定の詳細情報へのリンクも含まれています。この情報を使用すると、ワークロードの中断を最小限に抑えながら、クラスタの安定性とセキュリティを最新の状態に保つことができます。

クラスタのアップグレードの概要については、GKE クラスタのアップグレードについてをご覧ください。Standard でクラスタがアップグレードされる仕組みについては、Standard クラスタのアップグレードをご覧ください。

コントロール プレーンとノードの自動アップグレード

すべての Autopilot クラスタで自動アップグレードが有効になっています。GKE バージョンが自動アップグレード用に選択されると、GKE は自動アップグレードを開始します。すべてのクラスタで自動アップグレードを監視し、異常なノードなどの問題が発生した場合に介入します。自動アップグレードを無効にすることはできませんが、メンテナンスの時間枠と除外でタイミングを制御できます。

クラスタをアップグレードするために、GKE はコントロール プレーンとノードで実行されているバージョンを更新します。クラスタが新しいマイナー バージョン（1.24～1.25 など）または新しいパッチ バージョン（1.24.2-gke.100～1.24.5-gke.200 など）にアップグレードされます。詳細については、GKE のバージョニングとサポートをご覧ください。

Autopilot クラスタはすべてリリース チャンネルに登録されています。 このため、GKE はコントロール プレーンとノードを自動的にアップグレードして、同じ GKE バージョンを実行します。

GKE は、ノードをアップグレードする前に、クラスタのコントロール プレーンをアップグレードします。

コントロール プレーンの自動アップグレード

Autopilot クラスタはすべてリージョン クラスタです。リージョン クラスタにはコントロール プレーンの複数のレプリカがあり、未定義の順序で一度に 1 つずつレプリカがアップグレードされます。これにより、自動アップグレード中もクラスタの高可用性が維持されます。アップグレードの進行中、各コントロール プレーンのレプリカは使用できなくなります。

メンテナンスの時間枠または除外を構成すると、GKE は可能な限りその構成に従います。

コントロール プレーンのアップグレードが進行中の場合、GKE は新しいノードを作成できません。コントロール プレーンのアップグレード中に、新しいノードタイプを必要とする Pod をデプロイすると、コントロール プレーンのアップグレードが完了するまで遅延が発生することがあります。

ノードの自動アップグレード

GKE は、Autopilot クラスタ コントロール プレーンをアップグレードした後、ノードを同じ GKE バージョンにアップグレードします。

Autopilot では、GKE は類似した特性を持つノードをグループ化します。GKE は、Autopilot ノードにサージ アップグレードを使用し、グループ内で最大 20 個のノードを同時にアップグレードします。ノードとワークロードの高可用性を維持するため、同時にアップグレードされるノード数は変わります。

ノードの数とノードで実行されているワークロードの構成によっては、ノードのアップグレードに数時間かかることがあります。たとえば、次の構成の場合、アップグレードに時間がかかる可能性があります。

メンテナンスの時間枠または除外を構成すると、GKE は可能な限りその構成に従います。

GKE がノードをアップグレードした後、次の処理を行います。

  1. GKE は、新しい GKE バージョンで新しいサージノードを作成し、サージノードがコントロール プレーンに登録されるのを待ちます。
  2. GKE により、アップグレードする既存のノード（ターゲット ノード）が選択されます。
  3. GKE はターゲット ノードを閉鎖して、新しい Pod がターゲット ノードに配置されないようにします。
  4. ターゲット ノードをドレインし、ターゲット ノードから既存の Pod を強制的に排除します。

  5. ワークロード コントローラによって管理される Pod を他の使用可能なノードに再スケジュールします。スケジュールを変更できない Pod は、GKE がスケジュールを変更できるようになるまで、PENDING 状態のままになります。

  6. ターゲット ノードを削除します。

特定の GKE バージョンへの多数の自動アップグレードを行うと、GKE フリート全体で異常なノードが発生する場合、GKE は問題を調査している間、そのバージョンへのアップグレードを停止します。

バージョンが自動アップグレードで選択される仕組み

GKE は、新しいマイナー バージョンを定期的にリリースしていますが、リリース バージョンは自動アップグレードの対象としてすぐに選択されません。GKE バージョンは、十分な使用実績を積んで継続的な安定性が証明されてから、自動アップグレードのターゲットとして認定されます。

認定されると、Google Cloud は、古い GKE バージョンの特定のサブセットを実行するクラスタに対する自動アップグレードのターゲットとして、そのバージョンを選択します。通常、新しいマイナー バージョンが使用可能になるとすぐに、使用可能な最も古いマイナー バージョンはサポート対象外になります。GKE は、サポート対象外のマイナー バージョンを実行しているクラスタを、自動アップグレードのターゲット バージョンにアップグレードします。

GKE の新しい自動アップグレードのターゲット バージョンはリリースノートで通知されます。コントロール プレーンとノードの自動アップグレード対象のバージョンが別々の週に選択されることもあります。GKE は、マイナー バージョン（v1.21.x など）の新しいパッチリリースに自動的にアップグレードします。特定のクラスタの自動アップグレード ターゲットを取得するには、クラスタのアップグレードに関する情報の取得（プレビュー）をご覧ください。

バージョンのライフサイクルとバージョニング スキームについては、GKE のバージョニングとサポートをご覧ください。

バージョンのロールアウトのタイミングに影響する要因

新しいバージョンのクラスタの安定性と信頼性を確保するため、GKE はバージョンのロールアウト中に特定のプラクティスに実施します。

このプラクティスには次のものが含まれますが、これらに限定されません。

  • GKE は、Google Cloud のリージョンとゾーン全体に対して段階的に変更をロールアウトします。
  • GKE は、リリース チャンネル間でパッチ バージョンを段階的にロールアウトします。パッチには、Rapid リリース チャンネル、Regular リリース チャンネルのソーク時間が与えられます。その後、パッチが十分に使用され、安定性が実証されると、Stable リリース チャンネルに昇格します。リリース チャンネルのソーキング中にパッチ バージョンで問題が見つかった場合、対象のバージョンは次のチャンネルに昇格せず、新しいパッチ バージョンで問題が修正されます。
  • GKE は、バージョンにパッチを適用する場合と同様のソークプロセスに従って、マイナー バージョンを段階的にロールアウトします。マイナー バージョンでは、重大な変更が導入されるまでのソーキングの期間が長くなります。
  • 新しいバージョンがクラスタのグループに影響する場合は、GKE が自動アップグレードを遅らせることがあります。たとえば、次のマイナー バージョンで削除される非推奨の API または機能の影響を受けるクラスタを検出した場合、GKE は自動アップグレードを一時停止します。
  • GKE では、ビジネスの継続性を確保するため、ピーク時（主要な休日など）に新しいバージョンのロールアウトが遅れる場合があります。

自動アップグレードの発生のタイミングを構成する

デフォルトでは、自動アップグレードはいつでも発生する可能性があります。特に Autopilot クラスタでは、自動アップグレードが問題になることはほとんどありません。ただし、一部のワークロードでは細かい制御が必要になる場合があります。メンテナンスの時間枠と除外を構成すると、自動アップグレードを発生させる（または発生させない）タイミングを管理できます。

メンテナンスの時間枠と除外設定した場合、現在時刻がメンテナンスの時間枠に入るまではアップグレードが行われません。アップグレードが完了する前にメンテナンスの時間枠が終了した場合は、アップグレードの一時停止が試行されます。アップグレードは、次に利用可能なメンテナンスの時間枠で再開します。

Autopilot クラスタを手動でアップグレードする

Autopilot クラスタ コントロール プレーンの GKE バージョンを手動でアップグレードできます。GKE は、メンテナンスの可用性に応じて、コントロール プレーン バージョンに合わせてノードをできるだけ早くアップグレードします。 手順については、コントロール プレーンの手動アップグレードをご覧ください。Autopilot クラスタのノード バージョンを手動で管理することはできません。

コントロール プレーンのバージョンは、同じリリース チャンネルでサポートされているマイナー バージョンまたはパッチ バージョンにアップグレードすることも、別のリリース チャンネルのクラスタと同じマイナー バージョンのパッチ バージョンにアップグレードすることもできます。

たとえば、Regular リリース チャンネルで GKE バージョン 1.22.8-gke.202 を実行している Autopilot クラスタについて考えてみましょう。次のことが可能です。

  • Regular の任意のバージョンにアップグレードできます。
  • Rapid チャンネルにあるバージョン 1.22 の任意のパッチ バージョンにアップグレードでする。

チャンネル以外でのアップグレードの詳細については、新しいチャンネルからのパッチ バージョンの実行をご覧ください。

サージ アップグレード

Autopilot クラスタは、サージ アップグレードを使用して複数のノードを同時にアップグレードします。サージ アップグレードを使用すると、実行中のワークロードに十分なコンピューティング容量を維持できるため、実行中に発生するワークロードのバージョン アップグレードの中断を軽減できます。Autopilot は、アップグレード中にクラスタに追加されるサージノードの数を管理します。この数は、クラスタの合計サイズによって異なります。GKE は、アップグレード中に同時にオフラインにできるターゲット ノードの合計数も管理します。

実行中のすべてのワークロードに対して、クラスタで十分なコンピューティング容量を確保するため、新しいサージノードと使用できないターゲット ノードの数は変動します。アップグレード中に GKE がターゲット ノードからサージノードにワークロードを移行する際に、軽微な中断が発生する可能性があります。

サージ アップグレードが発生する仕組みについては、ノードの自動アップグレードをご覧ください。

サージ アップグレードの割り当て要件

ノードの再作成とは異なり、サージ アップグレードには追加の Compute Engine リソースが必要です。リソース割り当ては、使用可能な Compute Engine の割り当てによって異なります。構成によっては、この割り当てによって同時アップグレード数が制限されることや、アップグレードが失敗することがあります。スケーリングの問題を回避し、アップグレードを予測しやすくするために、Compute Engine インスタンスの割り当てが 90% を超えないようにすることをおすすめします。

割り当ての詳細については、ノード アップグレード用のリソースを確保するをご覧ください。

アップグレードの通知を受け取る

GKE は Pub/Sub にアップグレードの通知を公開し、クラスタに関する情報を GKE から受け取るためのチャネルをユーザーに提供します。

詳細については、クラスタの通知の受信をご覧ください。

コンポーネントのアップグレード

GKE は、ワーカーノードでシステム ワークロードを実行し、クラスタの特定の機能をサポートします。たとえば、gke-metadata-server システム ワークロードは GKE 用 Workload Identity 連携をサポートしています。GKE は、これらのワークロードの正常性を維持します。これらのコンポーネントの詳細については、関連する機能のドキュメントをご覧ください。

コンポーネントの新機能や修正が利用可能になると、GKE はそれらを含むパッチ バージョンを示します。コンポーネントの最新バージョンを入手するには、関連ドキュメントまたはリリースノートを参照して、コントロール プレーンまたはノードを適切なバージョンにアップグレードする手順を確認してください。

次のステップ