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

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

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

クラスタとノードプールのアップグレードの仕組み

このセクションでは、自動アップグレード中または手動アップグレード中のクラスタの動作について説明します。自動アップグレードでは、GKE が自動アップグレードを開始します。GKE は、すべての GKE クラスタ全体で自動アップグレードと手動アップグレードを監視し、問題が発生したら介入します。

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

クラスタをリリース チャンネルに登録すると、クラスタのコントロール プレーンのアップグレードが完了する時点と、ノードプールのアップグレードが開始される時点の間の短い期間（通常は数日間、そのときのリリースによって異なる）を除き、またはコントロール プレーンが手動でアップグレードされた場合、クラスタ自身と同じバージョンの GKE を実行します。詳細については、リリースノートをご覧ください。

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

このセクションでは、GKE がお客様のクラスタを自動アップグレードしたとき、またはお客様が手動アップグレードを開始したときの動作を説明します。

  • ゾーンクラスタにはコントロール プレーンが 1 つしかありません。アップグレード中は、ワークロードが引き続き実行されますが、アップグレードが完了するまで、新しいワークロードのデプロイ、既存のワークロードの変更、クラスタの構成に対するその他の変更を行うことはできません。

  • リージョン クラスタにはコントロール プレーンの複数のレプリカがあり、不定の順序で一度に 1 つずつレプリカがアップグレードされます。アップグレード中もクラスタの高可用性は維持されます。各コントロール プレーン レプリカはアップグレード中にのみ使用不可になります。

メンテナンスの時間枠または除外を構成した場合には、それが可能な限り尊重されます。

ノードプールのアップグレード

このセクションでは、GKE がお客様のノードプールを自動アップグレードしたとき、またはお客様が手動ノードプール アップグレードを開始したときの動作について説明します。

GKE は、クラスタ内のノードプールを 1 つずつ自動的にアップグレードします。または、1 つ以上のノードプールを並行して手動でアップグレードすることもできます。デフォルトでは、ノードプール内のノードは任意の順序で一度に 1 つずつアップグレードされます。複数のゾーンにまたがるノードプールでは、アップグレードはゾーンごとに行われます。ゾーン内では、ノードは未定義の順序でアップグレードされます。

GKE ノードプールのアップグレードでは、2 つの構成可能な組み込みのアップグレード戦略から選択でき、クラスタ環境のニーズに基づいてアップグレード プロセスを調整できます。サージ アップグレード戦略と Blue/Green アップグレードの戦略の詳細については、アップグレード戦略をご覧ください。

ノードプールのアップグレード中には、アップグレードをキャンセルしない限り、クラスタ構成に変更を加えることはできません。

GKE は、自動アップグレード中は可能な限りメンテナンスの時間枠と除外に従います。手動アップグレードでは、構成したメンテナンスの時間枠と除外は省略されます。

ノードのアップグレード方法

ノードプールのアップグレード中にノードをアップグレードする方法は、ノードプールのアップグレード戦略と構成方法によって異なります。ただし、基本的な手順は同じです。ノードをアップグレードする場合、GKE はノードから Pod を削除して、アップグレードできるようにします。

ノードがアップグレードされると、Pod で次のことが起こります。

  1. ノードは閉鎖されているため、Kubernetes は対象のノードで新しい Pod をスケジュールしません。
  2. その後、ノードがドレインされます。つまり、Pod は削除されます。サージ アップグレードの場合、GKE では Pod の PodDisruptionBudget と GracefulTerminationPeriod の設定が最大 1 時間適用されます。Blue/Green アップグレードでは、より長いソーク時間を構成することで、これを延長できます。
  3. コントロール プレーンは、コントローラで管理される Pod を他のノードに再スケジュールします。スケジュールを変更できない Pod は、再スケジュールが可能になるまで「保留」フェーズのままになります。

ノードプールのアップグレード プロセスには、アップグレード戦略、ノード数、ワークロード構成に応じて最大で数時間を要する場合があります。

ノードのアップグレード期間に影響を与える考慮事項

ノードのアップグレードが完了するまでに長時間を要する可能性のある構成には、次のようなものがあります。

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

GKE には、ノードプールのアップグレード方法を決定する構成可能な戦略が組み込まれています。ノードのアップグレード戦略を使用する変更の種類について詳しくは、GKE がサージ アップグレードを使用する場合と GKE が Blue/Green アップグレードを使用する場合をご覧ください。

サージ アップグレード

デフォルトでは、サージ アップグレード戦略がノードプールのアップグレードに使用されます。サージ アップグレードでは、ローリング方式を使用してノードがアップグレードされます。この戦略は、中断のない増分変更を処理できるアプリケーションに最適です。この方法では、ノードはローリング ウィンドウでアップグレードされます。設定を使用すると、一度にアップグレードできるノードの数とアップグレードの中断の程度を変更でき、環境のニーズに応じて速度と中断の最適なバランスを見つけることができます。

Blue/Green アップグレード

もう一つのアプローチは、Blue/Green アップグレードです。このアプローチでは、2 つの環境セット（元の環境と新しい環境）が一度に維持され、ロールバックが可能な限り容易になります。Blue/Green はリソースを大量に消費するため、変更の影響を受けやすいアプリケーションに適しています。この戦略では、ワークロードが元の「Blue」環境から新しい「Green」環境に段階的に移行され、新しい構成で検証するためのソーク時間が与えられます。必要に応じて、ワークロードを既存の「Blue」環境にすばやくロールバックできます。

ノードのアップグレード戦略の仕組みについては、ノードのアップグレード戦略をご覧ください。

ノード アップグレード戦略のリソース要件

サージ アップグレードによって追加のノードが作成され（maxSurge が 0 より大きな値に設定されている場合）、Blue/Green アップグレードはノードプール内のノード数を一時的に 2 倍にします。これには追加のリソースが必要であり、Compute Engine の割り当て、リソースの可用性、予約容量の影響を受けます。ノードプールに十分なリソースがない場合、アップグレードに時間がかかることや、アップグレードに失敗することがあります。

プロジェクトにノードのアップグレードに十分なリソースを確保する方法と、環境にリソースの制約がある場合の対応方法については、ノードのアップグレード用にリソースを確保するをご覧ください。

自動アップグレード

Standard クラスタを作成すると、デフォルトでクラスタとそのノードプールの自動アップグレードが有効になります。

GKE はクラスタのコントロール プレーンの保護を行い、新しい GKE バージョンが自動アップグレード用に選択されたときにクラスタをアップグレードします。インフラストラクチャのセキュリティは GKE において優先度の高い事項であるため、コントロール プレーンは定期的にアップグレードされ、無効にすることはできません。ただし、メンテナンスの時間枠と除外を適用すると、コントロール プレーンとノードのアップグレードを一時停止できます。

GKE 共有責任モデルの一環として、ノード、コンテナ、Pod の保護をお客様の責任で行っていただきます。ノードの自動アップグレードはデフォルトで有効になっています。推奨されませんが、ノードの自動アップグレードを無効にすることは可能です。ノードの自動アップグレードを無効にしても、クラスタのコントロール プレーンのアップグレードは妨げられません。ノードの自動アップグレードを無効にする場合は、クラスタのノードがクラスタ バージョンと互換性のあるバージョンを実行するようにすることと、バージョンが Kubernetes のバージョン スキューのサポート ポリシーに準拠するようにすることは、お客様の責任で行っていただきます。

自動アップグレードを発生させる（または発生させない）タイミングを制御するには、メンテナンスの時間枠と除外を構成します。

クラスタ API との互換性を維持する目的で、クラスタのノードプールでは、コントロール プレーン バージョンの 2 つ前のマイナー バージョンより古いバージョンを実行できません。またノードプール バージョンは、各ノードにインストールされるソフトウェア パッケージのバージョンも決定します。ノードプールを常にクラスタ バージョンに更新し続けることをおすすめします。

クラスタをリリース チャンネルに登録すると、クラスタのコントロール プレーンのアップグレードが完了する時点と、特定のノードプールのアップグレードが開始される時点の間の短い期間（通常は数日間、そのときのリリースによって異なる）を除き、ノードは常にクラスタ自身と同じバージョンの GKE を実行します。詳細については、リリースノートをご覧ください。

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

新しい GKE バージョンは定期的にリリースされますが、その直後に自動アップグレード用としてバージョンが選択されるわけではありません。ある GKE バージョンが安定性を証明するのに十分なクラスタ使用量を達成したら、GKE はそのバージョンを、旧バージョンのサブセットを実行するクラスタ向けの自動アップグレード ターゲットとして選択します。

新しい自動アップグレード ターゲットはリリースノートで発表されます。利用可能なバージョンが自動アップグレード用として選択されるまでの間、手動でアップグレードすることができます。クラスタ自動アップグレード対象のバージョンとノード自動アップグレード対象のバージョンが別々の週に選択される場合があります。

通常は、新しいマイナー バージョンが一般公開されるとすぐに、使用可能な最も古いマイナー バージョンがサポートされなくなります。サポートされないマイナー バージョンを実行しているクラスタは、その次のマイナー バージョンに自動的にアップグレードされます。

1 つのマイナー バージョン（v1.14.x など）の中で、クラスタが新しいパッチリリースに自動アップグレードされることがあります。

リリース チャンネルを使用すると、バージョンを直接管理する代わりに、バージョンの安定性に基づいてクラスタとノードプールのバージョンを制御できます。

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

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

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

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

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

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

手動アップグレード

いつでも、利用可能な互換性のあるバージョンにクラスタまたはそのノードプールを手動でアップグレードするようリクエストできます。手動アップグレードは、設定済みのメンテナンス時間枠とメンテナンス除外をすべてバイパスします。

クラスタを手動でアップグレードするとき、その可用性は、クラスタがリージョンであるかどうかに左右されます。

  • ゾーンクラスタの場合、アップグレード中はコントロール プレーンが使用できなくなります。ほとんどの場合、アップグレード中はワークロードが正常に実行されますが、ワークロードを変更できません。

  • リージョン クラスタの場合は、アップグレード中の 1 つのコントロール プレーン レプリカが使用不可になるだけで、クラスタの高可用性は維持されます。

コントロール プレーンと互換性のあるバージョンへのノードのアップグレードを手動で開始することができます。

自動アップグレード エラーに対する GKE の対応

基盤となる Compute Engine インスタンスの問題、または Kubernetes の問題が原因で、ノードプールの自動アップグレードが失敗することがあります。たとえば、次のような場合、自動アップグレードは失敗します。

  • 構成済みの maxSurge の設定が Compute Engine リソースの割り当てを超えている。
  • 新しいサージノードがクラスタ コントロール プレーンに登録されなかった。
  • ノードのドレインに時間がかかりすぎた、または削除に時間がかかりすぎた。

個々のノードのアップグレードで問題が発生した場合は、GKE がアップグレードを数回再試行し、再試行の間隔を徐々に広げます。ノードプール内のノードのアップグレードに失敗した場合、GKE はアップグレードされたノードをロールバックしません。代わりに、GKE はすべてのノードが正常にアップグレードされるまで、ノードプールの自動アップグレードを再試行します。

サージノードのリクエストが Compute Engine の割り当てを超過したためにノードのアップグレードが失敗した場合、GKE は同時に実行するサージノードの数を減らして割り当てに対処し、アップグレードの続行を試みます。

アップグレードの通知を受信する

GKE は、クラスタに関連するイベント（バージョン アップグレードやセキュリティ情報など）に関する通知を Pub/Sub に公開し、クラスタに関する情報を GKE から受け取るためのチャンネルをユーザーに提供します。

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

アップグレードのログを確認する

GKE のデフォルトでは、コントロール プレーンとノードプールのアップグレード イベントが Cloud Logging に記録されます。アップグレード イベントログでは、アップグレード プロセスが可視化され、必要に応じてトラブルシューティングに役立つ有益な情報が得られます。

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

クラスタのアップグレード イベントは、次のフィルタを使用してクエリできます。

resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

これらのログは、構造化ロギング形式で記録されます。アップグレード イベントの詳細を確認するには、次のフィールドを使用します。



フィールド 説明
protoPayload.metadata.operationType クラスタのアップグレード イベントには、UPGRADE_MASTER と UPDATE_CLUSTER の 2 種類があります。
UPGRADE_MASTER は、Kubernetes コントロール プレーンのバージョンを変更します。
UPDATE_CLUSTER は、Kubernetes コントロール プレーンのバージョンを変更しない更新を表します。
どちらのタイプのクラスタ アップグレードでも、ゾーンクラスタでコントロール プレーンを使用できなくなる可能性があります。詳細については、クラスタとノードプールのアップグレードの仕組みをご覧ください。
protoPayload.methodName このフィールドには、クラスタのアップグレードをトリガーした API が表示されます。
google.container.v1.ClusterManager.UpdateCluster: コントロール プレーンの手動アップグレード
google.container.internal.ClusterManagerInternal.UpdateClusterInternal: コントロール プレーンの自動アップグレード
google.container.v1.ClusterManager.PatchCluster: クラスタ構成の変更。
protoPayload.metadata.previousMasterVersion このフィールドは MASTER_UPGRADE オペレーション タイプにのみ使用され、アップグレード前に使用された前のコントロール プレーン バージョンが含まれます。
protoPayload.metadata.currentMasterVersion このフィールドは MASTER_UPGRADE オペレーション タイプにのみ使用され、アップグレード後に使用される新しいコントロール プレーンのバージョン番号が含まれます。

ノードプールのアップグレードのログ

ノードプールのアップグレード イベントを表示するには、次のクエリを使用します。

resource.type="gke_nodepool"
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"

アップグレード イベントの詳細については、次のフィールドを使用します。

protoPayload.methodName フィールドは、次のようにアップグレードが手動でトリガーされたか、自動的にトリガーされたかを示します。

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

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

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

次のステップ