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


このページでは、Google Kubernetes Engine(GKE)クラスタのクラスタのアップグレードのコンセプトについて説明します。クラスタのアップグレードの仕組みに精通している場合は、クラスタのアップグレードに関するベスト プラクティスの実装をご覧ください。

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

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

GKE は、コントロール プレーンのアップグレードノードのアップグレードの両方を含む、次のタイプのクラスタ アップグレードを実行します。

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

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

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

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

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

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

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

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

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

上記の機能について学習したら、クラスタのアップグレードに関するベスト プラクティスを実装できます。

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

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

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

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

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

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

クラスタノードの自動アップグレードとは何ですか?

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

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

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

ノードの自動アップグレードを延期する場合は、GKE クラスタのノードに次の制約を考慮してください。

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

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

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

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

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

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

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

GKE では、クラスタのアップグレードとクラスタの更新は関連する意味を持ちます。

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

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

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

次のステップ