GKE のクラスタ アップグレードについて

このページでは、Google Kubernetes Engine（GKE）クラスタの「クラスタ アップグレード」のコンセプトを紹介します。クラスタ アップグレードの仕組みについてご存じの場合は、代わりにクラスタのアップグレードに関するベスト プラクティスをご覧ください。

クラスタ アップグレードとは

GKE の Kubernetes クラスタは、ユーザー ワークロードを実行するコントロール プレーンとワーカーノードで構成されます。コントロール プレーンとワーカーノードの両方が Kubernetes のバージョンを実行します。GKE は、コントロール プレーンとノードのバージョンを自動的にアップグレードし、クラスタに新機能、バグの修正、セキュリティ パッチが確実に適用されるようにします。GKE がクラスタのバージョンを選択する方法の詳細については、GKE のバージョニングとサポートをご覧ください。

GKE は、コントロール プレーンのアップグレードとノードのアップグレードの両方を含む、以下の種類のクラスタ アップグレードを実施します。

  • パッチ バージョン アップグレード: リリース チャンネルに応じて、クラスタを新しいパッチに毎週自動的にアップグレードします。
  • マイナー バージョン アップグレード: マイナー アップグレードは年に約 3 回発生します。Extended チャンネル クラスタの場合、マイナー アップグレードは、マイナー バージョンの拡張サポートの終了が近づいたときにのみ行われます。

リリース チャンネルに登録されていないクラスタの場合、GKE はコントロール プレーンとノードの両方を自動的にアップグレードします。GKE がこれらのクラスタの自動アップグレード ターゲットを選択する方法については、リリース チャンネルに登録されているクラスタと登録されていないクラスタの比較の表にある「アップグレードのタイミング」行をご覧ください。

GKE による自動アップグレードではなく、クラスタのコントロール プレーンとノードを利用可能なバージョンに手動でアップグレードすることもできます。GKE の機能を使用して、GKE によるクラスタのアップグレードのタイミングと方法を選択します。詳細については、クラスタ アップグレードを制御するをご覧ください。

クラスタ アップグレードに関する情報を得る

現在のアップグレードについて詳しくは、次のリソースをご覧ください。

クラスタ アップグレードを制御する

プラットフォーム管理者は、ワークロードのパフォーマンス、信頼性、セキュリティを維持しながらも、ワークロードの中断は最小限に抑えたいと考えるものです。GKE の共有責任モデルの一環として、GKE の責任はクラスタをアップグレードし、ワークロードを処理するために稼働し続けることです。

GKE との共有責任の一環として、ユーザーはクラスタのアップグレードに向けてワークロードを準備する必要があります。自動アップグレードを完全に無効にすることはできませんが、GKE がアップグレードを実施するタイミングと方法を制御することはできます。

ワークロード用に最適化された GKE クラスタのアップグレードを管理するには、次の機能を使用します。

上記の機能について理解したら、クラスタのアップグレードに関するベスト プラクティスを実践できるようになります。

ワークロードの可用性を最大限に高めるには、クラスタの管理とモニタリングとワークロードを準備するで説明されている推奨事項や手法を併用してください。

クラスタ コントロール プレーンの自動アップグレードとは

GKE では、クラスタのコントロール プレーンが定期的に、Kubernetes の新しい安定版のマイナー バージョンとパッチへ自動的にアップグレードされます。クラスタのリリース チャンネルの登録に基づいて、クラスタの新しいバージョンが選択されます。

自動アップグレードは通常、GKE クラスタのフリート全体で、数週間にわたって段階的に実施されます。GKE ではインフラストラクチャのセキュリティは優先度の高い事項であるため、コントロール プレーンのアップグレードは定期的に行われ、無効にすることはできません。

コントロール プレーンのアップグレードを無効にすることはできませんが、メンテナンスの除外を使用すると、クラスタがリリース チャンネルに登録されているかどうかにかかわらず、マイナー アップグレードやパッチ アップグレードなど、すべてのコントロール プレーンのアップグレードを最長 30 日間、一時的に回避できます。リリース チャンネルに登録されているクラスタの場合、マイナー バージョンのサポートが終了するまでマイナー バージョンのアップグレードを回避できます。

メンテナンスの時間枠を使用すると、GKE がコントロール プレーンをアップグレードできる定期的な期間を設定できます。

クラスタノードの自動アップグレードとは

Autopilot クラスタでは、ノードは常にコントロール プレーンのバージョンに自動的にアップグレードされます。Standard クラスタの場合、デフォルトでは、ノードはコントロール プレーンのバージョンに自動的にアップグレードされます。

どちらのクラスタモードでも、メンテナンスの時間枠と除外を使用することで、ノードのアップグレードのタイミングと範囲を制御できます。

  • リリース チャンネルに登録されているクラスタの場合、メンテナンスの除外を使用することで、ノードのマイナー バージョンのサポートが終了するまでノードの自動アップグレードを回避できます。
  • リリース チャンネルに登録されていない Standard クラスタの場合、クラスタレベルでノードの自動アップグレードを最長 30 日間回避できます。ノードプール レベルでは、ノードプールのマイナー バージョンが標準サポートの終了に達するまで、自動アップグレードを無効にすることができます。

ノードの自動アップグレードの延期を計画するときは必ず、GKE クラスタのノードについて以下の制約を考慮してください。

  • ノードのバージョンは、コントロール プレーンのバージョンから最大 2 つ前のマイナー バージョンまで許容されます。
  • ノードは、クラスタの現在のコントロール プレーン バージョンより新しいバージョンを実行できません。
  • ノードは、サポートが終了したマイナー バージョンを実行できません。ほとんどのリリース チャンネルのクラスタの場合、これは標準サポートの終了を意味します。Extended チャンネルに登録されているクラスタの場合、これは拡張サポートの終了を意味します。クラスタのチャンネルでマイナー バージョンが引き続きサポートされているかどうかを確認するには、リリース チャンネルのおおよそのスケジュールをご覧ください。

これらの制約の詳細については、GKE バージョン スキュー ポリシーをご覧ください。

セキュリティと互換性を確保するための自動クラスタ アップグレード

メンテナンスの時間枠と除外を使用してクラスタのアップグレードを回避している場合、またはクラスタがリリース チャンネルに登録されていないときに特定のノードプールに対してノードの自動アップグレードを無効にしている場合、セキュリティと互換性を確保するために、GKE がクラスタを自動的にアップグレードすることがあります。こうした阻害要因に関係なく GKE がクラスタをアップグレードする理由には、以下のようなものがあります。

  • サポート終了バージョンを実行しているクラスタ コントロール プレーン。
  • サポート終了バージョンを実行しているクラスタノード。
  • 状態ループのクラスタ、つまり、実行から劣化、修復、一時停止、そして実行に戻るというように状態がループしているクラスタ。

詳細については、サポート終了時の自動アップグレードとマネージド プラットフォームと責任共有をご覧ください。

GKE クラスタのライフサイクル管理によるアップグレードと更新

GKE では、クラスタのアップグレードとクラスタの更新は関連しています。

GKE において、クラスタのアップグレード（または単にアップグレード）という用語は、コントロール プレーンの Kubernetes バージョンの更新（コントロール プレーンのアップグレード）またはノードの Kubernetes バージョンの更新（ノードのアップグレード）、あるいはその両方を指します。Standard クラスタを使用する場合、GKE は単一のオペレーションでノードのノードプールをアップグレードするため、ノードのアップグレードは「ノードプールのアップグレード」とも呼ばれます。

クラスタの更新（または単に更新）という用語は、バージョンの更新など、コントロール プレーンまたはノードのあらゆる種類の変更を指す、より一般的な用語です。GKE は、アップグレード、その他の種類の更新、必要なメンテナンス オペレーションを行うことで、クラスタ環境を積極的に管理します。そうしてクラスタがパフォーマンスに優れた安全な状態に保たれ、最新の機能とバグの修正に関して最新の状態に維持されます。GKE では、ノードのアップグレード戦略やメンテナンス ポリシーなどの手段で、これらのプロセスにおける中断が最小限に抑えられています。

アップグレードを含め、クラスタのライフサイクルの変更をすべて管理する方法について詳しくは、クラスタのライフサイクルの変更を管理して中断を最小限に抑えるをご覧ください。

次のステップ