アップグレードの概要

このページでは、マルチクラスタ環境でクラスタをアップグレードする順序を計画する際に役立つアップグレード プロセスとバージョン スキュー情報の概要について説明します。アップグレードを計画する際に役立つチェックリストなどの詳細な計画情報については、アップグレードのベスト プラクティスをご覧ください。

アップグレードの順序

バージョン 1.7 以降のインプレース アップグレードは、常に特定のアップグレード順序に従う必要があります。

  1. 管理ワークステーションをアップグレードします。Google Cloud コンソール、Google Cloud CLI、または Terraform を使用してユーザー クラスタをアップグレードする場合でも、これを行うことをおすすめします。

  2. ユーザー クラスタを一度に 1 つずつアップグレードします。バージョン 1.14 以降では、必要に応じてユーザー クラスタのコントロール プレーンをユーザー クラスタのノードプールとは別にアップグレードできます。この操作を行う理由については、ユーザー クラスタのアップグレードをご覧ください。

    ユーザー クラスタ内のすべてのノードプールが、ユーザー クラスタのコントロール プレーンと同じバージョンになると、ユーザー クラスタは完全にアップグレードされます。

    管理クラスタは、管理するユーザー クラスタよりのマイナー バージョンにすることはできません。いずれかのユーザー クラスタが管理クラスタと同じマイナー バージョンにある場合、管理クラスタはアップグレードできません。

  3. すべてのユーザー クラスタが管理クラスタよりも少なくとも 1 つ後のマイナー バージョンである場合、必要に応じて管理クラスタをアップグレードできます。

1.28 以降では、アップグレードのバージョン スキューとバージョンルールが変更されました。 詳細については、バージョン スキューをご覧ください。

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

ユーザー クラスタをアップグレードする場合は、ユーザー クラスタ全体をアップグレードする(つまり、コントロール プレーンとクラスタ内のすべてのノードプールをアップグレードする)か、ユーザー クラスタのコントロール プレーンはアップグレードして、ノードプールを現在のバージョンで残すことができます。どのアプローチを採用するかは、次のような複数の要因によって異なります。

  • クラスタが存在する環境(本番環境または非本番環境)。
  • メンテナンスの時間枠の長さ。
  • ユーザー クラスタのバージョン。

たとえば、開発環境では、プロセスをシンプルにして、ユーザー クラスタのコントロール プレーンとすべてのノードプールの両方をアップグレードすることをおすすめします。ただし、メンテナンスの時間枠が短い本番環境では、コントロール プレーンのみをアップグレードすることをおすすめします。これは、時間を短縮し、高可用性(HA)のコントロール プレーンをしようすることでコントロール プレーンのアップグレードがユーザー ワークロードを中断しないためです。 コントロール プレーンがバージョン 1.28 以降の場合、ノードプールのアップグレード時にマイナー バージョンをスキップできます。

コントロール プレーンとは別でノードプールをアップグレードすることは、Ubuntu ノードプールと COS ノードプールではサポートされていますが、Windows ノードプールではサポートされていません。

ノードプールを選択してアップグレードする

状況によっては、ユーザー クラスタ内のすべてのノードプールではなく、一部のノードプールをアップグレードすることをおすすめします。たとえば、コントロール プレーンをアップグレードした後、トラフィックが少ないノードプールか、重要度の低いワークロードを実行するノードプールをアップグレードします。ワークロードが新しいバージョンで正しく実行されることを確認したら、最終的にすべてのノードプールがアップグレードされるまで、追加のノードプールをアップグレードします。

ユーザー クラスタをアップグレードするツールを選択する

GKE on VMware には、ユーザー クラスタをアップグレードするためのツールの選択肢が用意されています。

  • コマンドライン ツール gkectl。管理ワークステーションで実行します。アップグレードの前に、ユーザー クラスタの構成ファイルを変更して、クラスタのコントロール プレーンと必要に応じてノードプールのターゲット バージョンを設定します。このファイルをコマンドラインで gkectl に指定します。

  • Google Cloud コンソール、Google Cloud CLI、Terraform。GKE On-Prem API にネットワーク接続できる任意のコンピュータから実行できます。これらの標準ツールは、GKE On-Prem API のクライアントで、Google Cloud インフラストラクチャで実行されます。

    • Terraform を使用してユーザー クラスタを作成した場合にのみ、アップグレードに Terraform を使用できます。

    • gkectl を使用してユーザー クラスタを作成した場合、アップグレードにコンソールまたは gcloud CLI を使用するには、クラスタを GKE On-Prem API に登録する必要があります。1.16 以降では、gkectl を使用して作成されたクラスタは、デフォルトで GKE On-Prem API に登録されます。以前のバージョンで作成したクラスタの場合は、作成後にクラスタを登録できます。

      アップグレードに gkectl を使用する場合は、コンソールまたはgcloud CLI を使用して情報を取得するために、クラスタを GKE On-Prem API に登録することをおすすめします。

使用するツールは、ユーザー クラスタをアップグレードする方法によって異なります。

  • クラスタ全体をアップグレードする: gkectl、Google Cloud コンソール、Google Cloud CLI、Terraform を使用して、ユーザー クラスタ(コントロール プレーンとすべてのノードプール)をアップグレードできます。

  • コントロール プレーンのみをアップグレードする: gkectl、gcloud CLI、Terraform を使用して、ノードプールとは別にユーザー クラスタのコントロール プレーンをアップグレードできます。コンソールでは、コントロール プレーンのみのアップグレードはサポートされていません。

  • コントロール プレーンのアップグレード後にノードプールを選択してアップグレードする: gkectl、gcloud CLI、Terraform を使用して、コントロール プレーンのアップグレード後に特定のノードプールをアップグレードできます。

  • コントロール プレーンと 1 つ以上のノードプールを同時にアップグレードする: gkectl のみがこのユースケースをサポートしています。

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

すべてのユーザー クラスタのコントロール プレーンとノードプールが管理クラスタよりも少なくとも 1 つ後のマイナー バージョンの場合、必要に応じて管理クラスタをアップグレードできます。gkectl のみが管理クラスタのアップグレードをサポートしています。GKE On-Prem API クライアントは、管理クラスタのアップグレードをサポートしていません。

バージョン スキュー

バージョン スキューは、管理クラスタとその管理対象のユーザー クラスタのマイナーバージョンの違いです。次のセクションでは、ユーザー クラスタ バージョンは、コントロール プレーンとノードプールのバージョン全体を指します。

さらに、バージョン スキューは、ユーザー クラスタのコントロール プレーンとユーザー クラスタのノードプールとのマイナー バージョンの違いです。

マルチクラスタ環境では、サポートされているバージョン スキューとアップグレードのバージョン ルールを把握することで、クラスタをアップグレードする順序を計画できる場合があります。

管理クラスタとユーザー クラスタのバージョン スキュー

管理クラスタは、異なるバージョンのユーザー クラスタを管理できます。この機能により、組織に適したスケジュールでユーザー クラスタのフリートをアップグレードできます。

1.29 以上

バージョン スキューは 1.28 と同じです。1.29 では、この機能は一般提供ステージに移行されました。

バージョン 1.29 以降では、ユーザー クラスタは管理クラスタよりも最大 2 つのマイナー バージョンに高くできます。たとえば、管理クラスタが 1.16 の場合、その管理クラスタによって管理されるユーザー クラスタは 1.16、1.28、1.29 に設定できます。

一般的に、1.n が管理クラスタのマイナー バージョンの場合、ユーザー クラスタは 1.n1.n+1 または 1.n+2 のいずれかになります。1.n+2 のユーザー クラスタは、管理クラスタが少なくとも 1 つのマイナー バージョンにアップグレードされるまで、次のマイナー バージョンにアップグレードできません。

1.28

バージョン 1.28 では、ユーザー クラスタは、管理クラスタよりも最大 2 つ後のマイナー バージョンにすることができます。たとえば、管理クラスタが 1.15 の場合、その管理クラスタが管理するユーザー クラスタは 1.15、1.16、1.28 に設定できます。管理クラスタが 1.16 以降にアップグレードされるまで、1.28 のユーザー クラスタは 1.29 にアップグレードできません。

1.16 以下

バージョン 1.16 以前では、ユーザー クラスタは管理クラスタより 1 つ後のマイナー バージョンにできます。たとえば、管理クラスタが 1.15 の場合、その管理クラスタによって管理されるユーザー クラスタは 1.15 または 1.16 になります。

一般的に、1.n が管理クラスタのマイナー バージョンの場合、ユーザー クラスタは 1.n、または 1.n+1 のいずれかになります。管理クラスタがユーザー クラスタと同じマイナー バージョンになるまで、ユーザー クラスタは、次のマイナー バージョンにアップグレードできません。

ユーザー クラスタ コントロール プレーンとノードプールのバージョン スキュー

1.29 以上

バージョン スキューは 1.28 と同じです。1.29 では、この機能は一般提供ステージに移行されました。

バージョン 1.29 以降では、ユーザー クラスタのコントロール プレーンは、クラスタ内のノードプールよりも最大 2 つ高いマイナー バージョンにできます。たとえば、ユーザー クラスタのコントロール プレーンが 1.29 の場合、クラスタ内のノードプールは 1.16、1.28、または 1.29 に設定できます。

一般的に、1.n がユーザー クラスタ コントロール プレーンのマイナー バージョンの場合、クラスタ内のノードプールは 1.n1.n-1 または 1.n-2 のいずれかになります。すべてのノードプールが 1.n または 1.n-1 になるまで、ユーザー クラスタ コントロール プレーンを次のマイナー バージョンにアップグレードすることはできません。

1.28

バージョン 1.28 では、ユーザー クラスタのコントロール プレーンは、クラスタ内のノードプールよりも最大 2 つ高いマイナー バージョンにできます。たとえば、ユーザー クラスタのコントロール プレーンが 1.28 の場合、クラスタ内のノードプールは 1.15、1.16、または 1.28 に設定できます。すべてのノードプールが 1.28 または 1.16 になるまで、ユーザー クラスタ コントロール プレーンは 1.29 にアップグレードできません。

1.16 以下

バージョン 1.16 以前では、ユーザー クラスタのコントロール プレーンはクラスタ内のノードプールよりも 1 つ後のマイナー バージョンまでしか使用できません。たとえば、ユーザー クラスタのコントロール プレーンが 1.16 の場合、クラスタ内のノードプールは 1.15 または 1.16 に設定できます。

一般的に、1.n がユーザー クラスタ コントロール プレーンのマイナー バージョンの場合、クラスタ内のノードプールは 1.n、または 1.n-1 のいずれかになります。すべてのノードプールがコントロール プレーンと同じマイナー バージョンになるまで、ユーザー クラスタを次のマイナー バージョンにアップグレードすることはできません。

管理クラスタとユーザー クラスタのコントロール プレーンのアップグレードのバージョン ルール

管理クラスタとユーザー クラスタのコントロール プレーンのアップグレードのバージョン ルールは同じです。同じマイナー リリースか、その次のマイナー リリースのバージョンに直接アップグレードできます。たとえば、1.29.0 から 1.29.1、または 1.28.1 から 1.29.0 にアップグレードできます。パッチ バージョンはアップグレード バージョン ルールに影響しません。

1 つ上のマイナー リリースではないバージョンにアップグレードする場合は、現在のバージョンと目的のバージョンの間の各マイナー リリースを経由してアップグレードする必要があります。マイナー バージョンのスキップはサポートされていません。たとえば、バージョン 1.16.x からバージョン 1.29.x にアップグレードする場合、直接アップグレードすることはできません。まず、1.16.x から 1.28.x にアップグレードし、続いて 1.29.x にアップグレードする必要があります。

一般に、管理クラスタのアップグレードとユーザー クラスタ コントロール プレーンのアップグレードでは、1.n から 1.n+1 へのアップグレードのみがサポートされます。

ノードプールのアップグレードのバージョン ルール

バージョン 1.28 以降では、ユーザー クラスタのノードプールをアップグレードするときに、1 つのマイナー バージョンをスキップできます。たとえば、ユーザー クラスタのコントロール プレーンが 1.29 で、ノードプールが 1.16 の場合、1.28 をスキップしてノードプールを 1.29 に直接アップグレードできます。 パッチ バージョンはアップグレード バージョン ルールに影響しません。

一般に、ユーザー クラスタのコントロール プレーンが 1.n の場合、1.n-2 のノードプールを直接 1.n にアップグレードできます。ノードプールをアップグレードするときに、マイナー バージョンを 1 つスキップすると、ノードプールの 2 回のアップグレードよりも時間を短縮できます(1.n-2 から 1.n-1 にアップグレードし、その後 1.n にアップグレード)。これもまた、ユーザー クラスタで実行されるノードプールとは別に、ユーザー クラスタのコントロール プレーンをアップグレードする理由になります。

パッチ バージョンのアップグレード

クラスタに最新のセキュリティ修正を適用するために、可能な限り最新のパッチ バージョンにアップグレードすることをおすすめします。パッチ バージョンは、バージョン スキューとアップグレード ルールには影響しません。任意のマイナー バージョンについて、より上位のパッチ バージョンにアップグレードできます。つまり、YX より大きければ、1.29.X バージョン クラスタをバージョン 1.29.Y にアップグレードできます。たとえば、1.28.0 から 1.28.1 にアップグレードしたり、1.28.1 から 1.28.3 にアップグレードしたりできます。

次のステップ

アップグレードのベスト プラクティスを確認し、クラスタのアップグレード計画を作成します。