このページでは、VMware クラスタの Google Distributed Cloud（ソフトウェアのみ）のアップグレード プロセスとバージョン スキュー情報の概要について説明します。この情報は、マルチクラスタ環境でクラスタをアップグレードする順序を計画する際に役立ちます。アップグレードの計画に役立つチェックリストなど、計画に関する詳細情報については、アップグレードのベスト プラクティスをご覧ください。
このページは、基盤となる技術インフラストラクチャのライフサイクルを管理する IT 管理者と運用担当者を対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
バージョン ルール
アップグレードのルールは、クラスタのマイナー バージョンによって異なります。
バージョン 1.30 以前では、ユーザー クラスタのマイナー バージョンが管理クラスタのマイナー バージョン以上である必要があります。パッチ バージョンは関係ありません。たとえば、ユーザー クラスタのバージョンが 1.30.1 の場合、管理クラスタを 1.30.3 などのよりグレードの高いパッチ バージョンにアップグレードできます。
バージョン 1.31 以降では、パッチ バージョンを含む管理クラスタのバージョンがユーザー クラスタのバージョン以上である必要があります。たとえば、管理クラスタのバージョンが 1.31.1 の場合、ユーザー クラスタは最大でバージョン 1.31.1 までアップグレードできます。
クラスタをバージョン 1.31 にアップグレードする場合は、まずすべてのクラスタをバージョン 1.30 にアップグレードする必要があります。すべてのクラスタがバージョン 1.30 になったら、管理クラスタをバージョン 1.31 にアップグレードします。そうして初めて、ユーザー クラスタを管理クラスタと同じ 1.31 パッチ バージョンにアップグレードできるようになります。
gkectl のバージョン ルール
アップグレードに使用できる gkectl のバージョンは、ターゲット クラスタ バージョン（アップグレード先のクラスタのバージョン）によって異なります。通常、クラスタのターゲット バージョンと同じバージョンの gkectl を使用します。アップグレード中は、次のルールが適用されます。
gkectlバージョンのマイナー バージョンを、ターゲット マイナー クラスタ バージョンよりも低くすることはできません。たとえば、1.29 クラスタを 1.30 にアップグレードする場合、ターゲット クラスタ バージョンよりも低いgkectl1.29 は使用できません。パッチ バージョンは関係ありません。たとえば、gkectlバージョン 1.29.0-gke.1456 を使用して、1.29.1000-gke.94 などのパッチ バージョンにアップグレードできます。gkectlのバージョンは、現在のクラスタ バージョンより 2 つ前のマイナー バージョンにすることはできません。たとえば、1.28 クラスタを 1.29 にアップグレードする場合、gkectlのバージョンは 1.29 または 1.30 にできます。ただし、gkectlバージョン 1.31 はクラスタ バージョンより 3 つ後のマイナー バージョンであるため、使用できません。
必要に応じて、gkectl をダウンロードするを参照して、サポートされているバージョンの gkectl を入手してください。
管理クラスタとユーザー クラスタ間のバージョン スキューについては、このドキュメントのバージョン スキューをご覧ください。
アップグレードの順序
管理クラスタとユーザー クラスタのアップグレードの流れは、アップグレードによって到達したいクラスタ バージョン（これをターゲット バージョンと呼びます）によって異なります。
1.31 以降
ターゲット バージョンが 1.31 以降の場合は、管理クラスタによって管理されているユーザー クラスタをアップグレードする前に、管理クラスタをアップグレードする必要があります。次の手順では、アップグレードの順序について説明します。
管理ワークステーションをアップグレードします。ユーザー クラスタを Google Cloud コンソール、Google Cloud CLI、または Terraform でアップグレードする場合でも、この操作を行うことをおすすめします。
管理クラスタをアップグレードします。
ユーザー クラスタを一度に 1 つずつアップグレードします。
必要に応じて、ユーザー クラスタのノードプールとは別に、ユーザー クラスタのコントロール プレーンをアップグレードできます。詳細については、ノードプールをアップグレードするをご覧ください。
高度なクラスタでは使用できません。
必要に応じて、ノードプールをアップグレードするときにマイナー バージョンをスキップできます。詳細については、ノードプールのアップグレードでバージョンをスキップするをご覧ください。
高度なクラスタでは使用できません。
ユーザー クラスタ内のすべてのノードプールがユーザー クラスタのコントロール プレーンと同じバージョンになったら、ユーザー クラスタは完全にアップグレードされます。
1.30 以前
ターゲット バージョンが 1.30 以前の場合は、ユーザー クラスタを管理する管理クラスタをアップグレードする前に、すべてのユーザー クラスタをアップグレードする必要があります。
管理ワークステーションをアップグレードします。ユーザー クラスタを Google Cloud コンソール、Google Cloud CLI、または Terraform でアップグレードする場合でも、この操作を行うことをおすすめします。
ユーザー クラスタを一度に 1 つずつアップグレードします。
バージョン 1.14 以降では、ユーザー クラスタのノードプールとは別に、ユーザー クラスタのコントロール プレーンをアップグレードできます。
バージョン 1.16 以降では、ノードプールをアップグレードするときにマイナー バージョンをスキップできます。詳細については、ノードプールのアップグレードでバージョンをスキップするをご覧ください。
ユーザー クラスタ内のすべてのノードプールがユーザー クラスタのコントロール プレーンと同じバージョンになったら、ユーザー クラスタは完全にアップグレードされます。
管理クラスタは、管理するユーザー クラスタよりも新しいマイナー バージョンにできません。ユーザー クラスタのいずれかが管理クラスタと同じマイナー バージョンである場合、管理クラスタをアップグレードできません。
すべてのユーザー クラスタが管理クラスタよりも少なくとも 1 つ後のマイナー バージョンである場合、必要に応じて管理クラスタをアップグレードできます。
1.28 以降では、アップグレードのバージョン スキューとバージョン ルールが変更されました。詳細については、このドキュメントのバージョン スキューをご覧ください。
管理クラスタのアップグレード
1.31 以降
ターゲット バージョンが 1.31 以降の場合は、まず管理クラスタをアップグレードしてから、ユーザー クラスタをアップグレードする必要があります。
管理クラスタをアップグレードするには、gkectl または gcloud CLI を使用します。
1.30 以前
ターゲット バージョンが 1.30 以前の場合は、まずすべてのユーザー クラスタをアップグレードしてから、管理クラスタをアップグレードします。すべてのユーザー クラスタのコントロール プレーンとノードプールが、管理クラスタよりも少なくとも 1 つ前のマイナー バージョンである場合は、管理クラスタをアップグレードできます。
管理クラスタのアップグレードは gkectl でのみサポートされています。GKE On-Prem API クライアントは、管理クラスタのアップグレードをサポートしていません。
ユーザー クラスタのアップグレード
ユーザー クラスタをアップグレードする場合は、ユーザー クラスタ全体をアップグレードする（つまり、コントロール プレーンとクラスタ内のすべてのノードプールをアップグレードする）か、ユーザー クラスタのコントロール プレーンはアップグレードして、ノードプールを現在のバージョンで残すことができます。どのアプローチを採用するかは、次のような複数の要因によって異なります。
- クラスタが存在する環境（本番環境または非本番環境）。
- メンテナンスの時間枠の長さ。
- ユーザー クラスタのバージョン。
たとえば、開発環境では、プロセスを容易にして、ユーザー クラスタのコントロール プレーンとすべてのノードプールの両方をアップグレードすることをおすすめします。ただし、メンテナンスの時間枠が短い本番環境では、コントロール プレーンのみをアップグレードすることをおすすめします。これは、時間を短縮し、高可用性（HA）のコントロール プレーンを使用することで、コントロール プレーンのアップグレードによるユーザー ワークロードの中断を回避できるためです。コントロール プレーンがバージョン 1.28 以降の場合、ノードプールのアップグレード時にマイナー バージョンをスキップできます。
高度なクラスタでは使用できません。
ノードプールを選択してアップグレードする
状況によっては、ユーザー クラスタ内のすべてのノードプールではなく、一部のノードプールをアップグレードすることをおすすめします。たとえば、コントロール プレーンをアップグレードした後、トラフィックが少ないノードプールか、重要度の低いワークロードを実行しているノードプールをアップグレードします。ワークロードが新しいバージョンで正しく実行されることを確認したら、最終的にすべてのノードプールがアップグレードされるまで、追加のノードプールをアップグレードします。詳細については、ノードプールをアップグレードするをご覧ください。
ノードプールのアップグレードでマイナー バージョンをスキップする
クラスタのバージョンが 1.16 以降の場合は、ノードプールをアップグレードするときにマイナー バージョンをスキップできます。バージョン スキップ アップグレードを行うと、ノードプールの 2 つのバージョンを順番にアップグレードする場合に比べて、所要時間が半分に短縮されます。また、バージョン スキップ アップグレードを使用すると、サポート対象のバージョンを維持するために必要なアップグレードの間隔を長くできます。アップグレードの回数を減らすと、ワークロードの中断と検証時間が短縮されます。詳細については、ノードプールのアップグレードでバージョンをスキップするをご覧ください。
ユーザー クラスタのアップグレード ツールを選択する
Google Distributed Cloud では、ユーザー クラスタをアップグレードするためのツールを選択できます。
gkectlコマンドライン ツール。管理ワークステーションで実行します。アップグレードの前に、ユーザー クラスタの構成ファイルを変更して、クラスタのコントロール プレーンを設定します。必要であれば、ノードプールのターゲット バージョンを設定することもできます。このファイルをコマンドラインでgkectlに指定します。高度なクラスタを有効にしている場合は、アップグレードに
gkectlを使用する必要があります。GKE On-Prem API クライアントは、高度なクラスタではサポートされていません。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.31 以降
バージョン 1.31 以降では、管理クラスタはユーザー クラスタよりも最大で 2 つ後のマイナー バージョンにできます。たとえば、管理クラスタが 1.31 の場合、その管理クラスタが管理するユーザー クラスタは 1.29、1.30、1.31 のいずれかになります。
一般的に、管理クラスタのマイナー バージョンが 1.n の場合、ユーザー クラスタは 1.n-2、1.n-1、1.n のいずれかになります。すべてのユーザー クラスタが 1.n または 1.n-1 になるまで、管理クラスタを次のマイナー バージョンにアップグレードすることはできません。
1.29～1.30
バージョン スキューは 1.28 と同じです。1.29 では、この機能は一般提供のステージに移行しました。
バージョン 1.29 以降では、ユーザー クラスタは管理クラスタよりも最大で 2 つ後のマイナー バージョンにする高ことができます。たとえば、管理クラスタが 1.29 の場合、その管理クラスタが管理するユーザー クラスタは 1.29、1.30、1.31 のいずれかになります。
一般的に、管理クラスタのマイナー バージョンが 1.n の場合、ユーザー クラスタは 1.n、1.n+1、1.n+2 のいずれかになります。管理クラスタの少なくとも 1 つでマイナー バージョンが完了するまで、1.n+2 のユーザー クラスタを次のマイナー バージョンにアップグレードすることはできません。
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.31 の場合、クラスタ内のノードプールは 1.29、1.30、1.31 のいずれかになります。
一般的に、ユーザー クラスタ コントロール プレーンのマイナー バージョンが 1.n の場合、クラスタ内のノードプールは 1.n、1.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.31.0 から 1.31.1、または 1.30.1 から 1.31.0 にアップグレードできます。パッチ バージョンはアップグレード バージョン ルールに影響しません。
次回のマイナー リリースに含まれないバージョンにアップグレードする場合は、現在のバージョンと目的のバージョンの間の各マイナー リリースを経由してアップグレードする必要があります。マイナー バージョンのスキップはサポートされていません。たとえば、バージョン 1.29.x からバージョン 1.31 x には、直接アップグレードすることはできません。まず、1.29.x から 1.30.x にアップグレードし、続いて 1.31 にアップグレードする必要があります。
一般に、管理クラスタのアップグレードとユーザー クラスタのコントロール プレーンのアップグレードでは、1.n から 1.n+1 へのアップグレードのみがサポートされます。
ノードプール アップグレードのバージョン ルール
バージョン 1.28 以降では、ユーザー クラスタ内のノードプールをアップグレードするときに、1 つのマイナー バージョンをスキップできます。たとえば、ユーザー クラスタのコントロール プレーンが 1.31 で、ノードプールが 1.29 の場合、1.30 をスキップしてノードプールを 1.31 に直接アップグレードできます。パッチ バージョンはアップグレード バージョン ルールに影響しません。
一般に、ユーザー クラスタのコントロール プレーンが 1.n の場合、1.n-2 のノードプールを直接 1.n にアップグレードできます。ノードプールをアップグレードするときに、マイナー バージョンを 1 つスキップすると、ノードプールを 2 回アップグレードする場合よりも時間を短縮できます（1.n-2 から 1.n-1 にアップグレードし、その後 1.n にアップグレード）。これもまた、ユーザー クラスタで実行されるノードプールとは別に、ユーザー クラスタのコントロール プレーンをアップグレードする理由になります。
高度なクラスタでは使用できません。
パッチ バージョンのアップグレード
クラスタに最新のセキュリティ修正が適用されているように、可能な限り最新のパッチ バージョンにアップグレードすることをおすすめします。パッチ バージョンは、バージョン スキューとアップグレード ルールには影響しません。マイナー バージョンは、より上位のパッチ バージョンにアップグレードできます。つまり、Y が X より大きければ、1.31.X バージョン クラスタをバージョン 1.31.Y にアップグレードできます。たとえば、1.30.0 から 1.30.1 にアップグレードしたり、1.30.1 から 1.30.3 にアップグレードできます。
次のステップ
アップグレードのベスト プラクティスで、クラスタのアップグレード プランを作成する