このページでは、Google Kubernetes Engine（GKE）クラスタのクラスタ アップグレードのコンセプトについて説明します。クラスタ アップグレードの仕組みについてご存じの場合は、代わりにクラスタのアップグレードに関するベスト プラクティスをご覧ください。
クラスタ アップグレードとは
GKE の Kubernetes クラスタは、ユーザー ワークロードを実行するコントロール プレーンとワーカーノードで構成されます。コントロール プレーンとワーカーノードの両方が Kubernetes のバージョンを実行します。GKE は、コントロール プレーンとノードのバージョンを自動的にアップグレードし、クラスタに新機能、バグの修正、セキュリティ パッチが確実に適用されるようにします。GKE がクラスタのバージョンを選択する方法の詳細については、GKE のバージョニングとサポートをご覧ください。
GKE は、コントロール プレーンのアップグレードとノードのアップグレードの両方を含む、以下の種類のクラスタ アップグレードを実施します。
- パッチ バージョン アップグレード: リリース チャンネルに応じて、クラスタを新しいパッチに毎週自動的にアップグレードします。
- マイナー バージョン アップグレード: マイナー アップグレードは年に約 3 回発生します。Extended チャンネル クラスタの場合、マイナー アップグレードは、マイナー バージョンの拡張サポートの終了が近づいたときにのみ行われます。
リリース チャンネルに登録されていないクラスタの場合、GKE はコントロール プレーンとノードの両方を自動的にアップグレードします。GKE がこれらのクラスタの自動アップグレード ターゲットを選択する方法については、リリース チャンネルに登録されているクラスタと登録されていないクラスタの比較の表にある「アップグレードのタイミング」行をご覧ください。
GKE による自動アップグレードではなく、クラスタのコントロール プレーンとノードを利用可能なバージョンに手動でアップグレードすることもできます。GKE の機能を使用して、GKE によるクラスタのアップグレードのタイミングと方法を選択します。詳細については、クラスタ アップグレードを制御するをご覧ください。
クラスタ アップグレードに関する情報を得る
現在のアップグレードについて詳しくは、次のリソースをご覧ください。
- 現在の 自動アップグレード ターゲットなど、特定のクラスタのアップグレードについては、クラスタの アップグレードの可視性を高めるをご覧ください。
- 一般的な自動アップグレード ターゲットを取得するには、現在のバージョンの表をご覧ください。クラスタのマイナー バージョンへの具体的なマッピングについては、バージョン アップデートのリリースノートをご覧ください。
- GKE リリース スケジュールで、マイナー バージョンがアップグレード可能になり、サポート終了になるおおよその日付をご確認ください。
- クラスタ通知を使用して、Cloud Logging または Pub/Sub によりクラスタのアップグレード イベント（スケジュールされたクラスタ アップグレード（プレビュー）など）に関する最新情報を入手します。
クラスタ アップグレードを制御する
プラットフォーム管理者は、ワークロードのパフォーマンス、信頼性、セキュリティを維持しながらも、ワークロードの中断は最小限に抑えたいと考えるものです。GKE の共有責任モデルの一環として、GKE の責任はクラスタをアップグレードし、ワークロードを処理するために稼働し続けることです。
GKE との共有責任の一環として、ユーザーはクラスタのアップグレードに向けてワークロードを準備する必要があります。自動アップグレードを完全に無効にすることはできませんが、GKE がアップグレードを実施するタイミングと方法を制御することはできます。
ワークロード用に最適化された GKE クラスタのアップグレードを管理するには、次の機能を使用します。
- リリース チャンネル: リリース チャンネルを選択して、機能の可用性と安定性のバランスを考慮してクラスタ バージョンを取得します。
- メンテナンスの時間枠: アップグレードなどの特定のタイプの GKE クラスタ メンテナンスを行える繰り返しの時間枠を指定します。
- メンテナンス の除外: 特定の期間にクラスタのメンテナンスが行われないようにします。
- クラスタ停止 予算: パッチ アップグレードやマイナー アップグレードなど、特定のタイプのクラスタ アップグレード間の最小時間間隔をカスタマイズします。
- ノードのアップグレード 戦略: Standard ノードプールを使用している場合は、ノードの更新方法（サージ アップグレード、Blue/Green アップグレード、自動スケーリングされる Blue/Green アップグレード（プレビュー）アップグレード）を選択して、ワークロードの停止を最小限に抑えます。また、クラスタ内で GKE が同時に自動アップグレードするノードプールの数を選択します。
- ロールアウト の順序付け: GKE が本番環境クラスタをアップグレードする前に、本番前環境でアップグレードの適格性を確認します。
- 手動アップグレード: クラスタを手動でアップグレードし、進行中の自動アップグレードまたは手動アップグレードのキャンセル、再開、ロールバック、完了などの操作を行います。
上記の機能について理解したら、クラスタのアップグレードに関するベスト プラクティスを実践できるようになります。
ワークロードの可用性を最大限に高めるには、クラスタの管理とモニタリングとワークロードを準備するで説明されている推奨事項や手法を併用してください。
クラスタ コントロール プレーンの自動アップグレードとは
GKE では、クラスタのコントロール プレーンが定期的に、Kubernetes の新しい安定版のマイナー バージョンとパッチへ自動的にアップグレードされます。クラスタのリリース チャンネルの登録に基づいて、クラスタの新しいバージョンが選択されます。
自動アップグレードは通常、GKE クラスタのフリート全体で、数週間にわたって段階的に実施されます。GKE ではインフラストラクチャのセキュリティは優先度の高い事項であるため、コントロール プレーンのアップグレードは定期的に行われ、無効にすることはできません。
コントロール プレーンのアップグレードを無効にすることはできませんが、メンテナンス の除外 を使用すると、クラスタが リリース チャンネルに登録されているかどうかにかかわらず、マイナー アップグレードやパッチ アップグレードなど、すべてのコントロール プレーンのアップグレードを最長 90 日間、一時的に回避できます。リリース チャンネルに登録されているクラスタの場合、マイナー バージョンのサポートが終了するまでマイナー バージョンのアップグレードを回避できます。
メンテナンスの時間枠を使用すると、GKE がコントロール プレーンをアップグレードできる定期的な期間を設定できます。
クラスタノードの自動アップグレードとは
GKE は、クラスタとノードのタイプに応じて、次の方法でクラスタノードの自動アップグレードを実行します。
- Autopilot クラスタでは、ノードは常にコントロール プレーンのバージョンに自動的にアップグレードされます。
Standard クラスタの場合、GKE は次の処理を行います。
- Standard ノードプールの場合、デフォルトでは、ノードはコントロール プレーンなどの適切な 自動アップグレード ターゲットに 自動的にアップグレードされます。必要に応じて、メンテナンスの除外を使用してノードの自動アップグレードを無効にできます。このタイプのノードプールは手動でアップグレードすることもできます。
- Autopilot 管理ノード プールの場合、ノードは時間の経過とともにコントロール プレーンのバージョンに自動的にアップグレードされます。このタイプのノードプールは手動でアップグレードすることもできます。
どちらのクラスタモードでも、メンテナンスの時間枠と除外を使用することで、ノードのアップグレードのタイミングと範囲を制御できます。
- リリース チャンネルに登録されているクラスタの場合、メンテナンスの除外を使用することで、ノードのマイナー バージョンのサポートが終了するまでノードの自動アップグレードを回避できます。これは、GKE クラスタ内のすべてのノードに対して行うことも、ノードプールのメンテナンス除外がある Standard クラスタ内の特定のノードプールに対してのみ行うこともできます。
- リリース チャンネルに登録されていない Standard クラスタの場合、クラスタレベルでノードの自動アップグレードを最長 90 日間回避できます。Standard ノードプール レベルでは、ノードプールのマイナー バージョンが標準サポートの終了に達するまで、自動アップグレードを無効 にすることができます。
ノードの自動アップグレードの延期を計画するときは必ず、GKE クラスタのノードについて以下の制約を考慮してください。
- ノードのバージョンは、コントロール プレーンのバージョンから最大 2 つ前のマイナー バージョンまで許容されます。
- ノードは、クラスタの現在のコントロール プレーン バージョンより新しいバージョンを実行できません。
- ノードは、サポートが終了したマイナー バージョンを実行できません。ほとんどのリリース チャンネルのクラスタの場合、これは標準サポートの終了を意味します。Extended チャンネルに登録されているクラスタの場合、これは拡張サポートの終了を意味します。クラスタのチャンネルでマイナー バージョンが引き続きサポートされているかどうかを確認するには、リリース チャンネルのおおよそのスケジュールをご覧ください。
これらの制約の詳細については、GKE バージョン スキュー ポリシーをご覧ください。
セキュリティと互換性を確保するための自動クラスタ アップグレード
メンテナンスの時間枠と除外を使用してクラスタのアップグレードを回避している場合、またはクラスタがリリース チャンネルに登録されていないときに特定の Standard ノードプールに対してノードの自動アップグレードを無効にしている場合、セキュリティと互換性を確保するために、GKE がクラスタを自動的にアップグレードすることがあります。こうした阻害要因に関係なく GKE がクラスタをアップグレードする理由には、以下のようなものがあります。
- サポート終了バージョンを実行しているクラスタ コントロール プレーン。
- サポート終了バージョンを実行しているクラスタノード。
- 状態ループのクラスタ、つまり、実行から劣化、修復、一時停止、そして実行に戻るというように状態がループしているクラスタ。
詳細については、サポート終了時の自動アップグレードとマネージド プラットフォームと責任共有をご覧ください。
GKE クラスタのライフサイクル管理によるアップグレードと更新
GKE では、クラスタのアップグレードとクラスタの更新は関連しています。
GKE において、クラスタのアップグレード（または単にアップグレード）という用語は、コントロール プレーンの Kubernetes バージョンの更新（コントロール プレーンのアップグレード）またはノードの Kubernetes バージョンの更新（ノードのアップグレード）、あるいはその両方を指します。Standard クラスタを使用する場合、GKE は単一のオペレーションでノードのノードプールをアップグレードするため、ノードのアップグレードは「ノードプールのアップグレード」とも呼ばれます。
クラスタの更新（または単に更新）という用語は、バージョンの更新など、コントロール プレーンまたはノードのあらゆる種類の変更を指す、より一般的な用語です。GKE は、アップグレード、その他の種類の更新、必要なメンテナンス オペレーションを行うことで、クラスタ環境を積極的に管理します。そうしてクラスタがパフォーマンスに優れた安全な状態に保たれ、最新の機能とバグの修正に関して最新の状態に維持されます。GKE では、ノードのアップグレード戦略やメンテナンス ポリシーなどの手段で、これらのプロセスにおける中断が最小限に抑えられています。
アップグレードを含め、クラスタのライフサイクルの変更をすべて管理する方法について詳しくは、クラスタのライフサイクルの変更を管理して中断を最小限に抑えるをご覧ください。
次のステップ
- Autopilot クラスタのアップグレードの詳細を確認する。
- Standard クラスタのアップグレードの詳細を確認する。
- GKE のバージョニングとサポートの詳細を確認する。
- GKE リリースノートの詳細を確認する。
- ノードの自動アップグレードを構成する方法を確認する。