このページでは、アップグレード プロセスの概要とバージョン スキュー情報について説明します。これは、マルチクラスタ環境でクラスタをアップグレードする順序を計画する際に役立ちます。アップグレードの計画に役立つチェックリストなど、計画に関する詳細情報については、アップグレードのベスト プラクティスをご覧ください。
アップグレードの順序
バージョン 1.7 以降でインプレース アップグレードを行う場合は、常に特定のアップグレード順序に従う必要があります。
管理ワークステーションをアップグレードします。ユーザー クラスタを Google Cloud コンソール、Google Cloud CLI、または Terraform でアップグレードする場合でも、この操作を行うことをおすすめします。
ユーザー クラスタを一度に 1 つずつアップグレードします。バージョン 1.14 以降では、ユーザー クラスタのノードプールとは別に、ユーザー クラスタのコントロール プレーンをアップグレードできます。これを実行する理由については、ユーザー クラスタのアップグレードをご覧ください。
ユーザー クラスタ内のすべてのノードプールがユーザー クラスタのコントロール プレーンと同じバージョンになったら、ユーザー クラスタは完全にアップグレードされます。
管理クラスタは、管理するユーザー クラスタよりも新しいマイナー バージョンにできません。ユーザー クラスタのいずれかが管理クラスタと同じマイナー バージョンである場合、管理クラスタをアップグレードできません。
すべてのユーザー クラスタが管理クラスタよりも少なくとも 1 つ後のマイナー バージョンである場合、必要に応じて管理クラスタをアップグレードできます。
1.28 以降では、アップグレードのバージョン スキューとバージョン ルールが変更されました。詳細については、バージョン スキューをご覧ください。
ユーザー クラスタのアップグレード
ユーザー クラスタをアップグレードする場合は、ユーザー クラスタ全体をアップグレードする（つまり、コントロール プレーンとクラスタ内のすべてのノードプールをアップグレードする）か、ユーザー クラスタのコントロール プレーンはアップグレードして、ノードプールを現在のバージョンで残すことができます。どのアプローチを採用するかは、次のような複数の要因によって異なります。
- クラスタが存在する環境（本番環境または非本番環境）。
- メンテナンスの時間枠の長さ。
- ユーザー クラスタのバージョン。
たとえば、開発環境では、プロセスをシンプルにして、ユーザー クラスタのコントロール プレーンとすべてのノードプールの両方をアップグレードすることをおすすめします。ただし、メンテナンスの時間枠が短い本番環境では、コントロール プレーンのみをアップグレードすることをおすすめします。これは、時間を短縮し、高可用性（HA）のコントロール プレーンを使用することで、コントロール プレーンのアップグレードによるユーザー ワークロードの中断を回避できるためです。コントロール プレーンがバージョン 1.28 以降の場合、ノードプールのアップグレード時にマイナー バージョンをスキップできます。
コントロール プレーンとは別にノードプールをアップグレードする方法は、Ubuntu ノードプールと COS ノードプールではサポートされていますが、Windows ノードプールではサポートされていません。
ノードプールを選択してアップグレードする
状況によっては、ユーザー クラスタ内のすべてのノードプールではなく、一部のノードプールをアップグレードすることをおすすめします。たとえば、コントロール プレーンをアップグレードした後、トラフィックが少ないノードプールか、重要度の低いワークロードを実行しているノードプールをアップグレードします。ワークロードが新しいバージョンで正しく実行されることを確認したら、最終的にすべてのノードプールがアップグレードされるまで、追加のノードプールをアップグレードします。
ユーザー クラスタのアップグレード ツールを選択する
Google Distributed Cloud では、ユーザー クラスタをアップグレードするためのツールを選択できます。
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.28 の場合、その管理クラスタが管理するユーザー クラスタは 1.28、1.29、1.30 のいずれかになります。
一般的に、管理クラスタのマイナー バージョンが 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.30 の場合、クラスタ内のノードプールは 1.28、1.29、1.30 のいずれかになります。
一般的に、ユーザー クラスタ コントロール プレーンのマイナー バージョンが 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.30.0 から 1.30.1、または 1.29.1 から 1.30.0 にアップグレードできます。パッチ バージョンはアップグレード バージョン ルールに影響しません。
次回のマイナー リリースに含まれないバージョンにアップグレードする場合は、現在のバージョンと目的のバージョンの間の各マイナー リリースを経由してアップグレードする必要があります。マイナー バージョンのスキップはサポートされていません。たとえば、バージョン 1.28.x からバージョン 1.30.x には、直接アップグレードすることはできません。まず、1.28.x から 1.29.x にアップグレードし、続いて 1.30.x にアップグレードする必要があります。
一般に、管理クラスタのアップグレードとユーザー クラスタのコントロール プレーンのアップグレードでは、1.n から 1.n+1 へのアップグレードのみがサポートされます。
ノードプール アップグレードのバージョン ルール
バージョン 1.28 以降では、ユーザー クラスタ内のノードプールをアップグレードするときに、1 つのマイナー バージョンをスキップできます。たとえば、ユーザー クラスタのコントロール プレーンが 1.30 で、ノードプールが 1.28 の場合、1.29 をスキップしてノードプールを 1.30 に直接アップグレードできます。パッチ バージョンはアップグレード バージョン ルールに影響しません。
一般に、ユーザー クラスタのコントロール プレーンが 1.n の場合、1.n-2 のノードプールを直接 1.n にアップグレードできます。ノードプールをアップグレードするときに、マイナー バージョンを 1 つスキップすると、ノードプールを 2 回アップグレードする場合よりも時間を短縮できます（1.n-2 から 1.n-1 にアップグレードし、その後 1.n にアップグレード）。これもまた、ユーザー クラスタで実行されるノードプールとは別に、ユーザー クラスタのコントロール プレーンをアップグレードする理由になります。
パッチ バージョンのアップグレード
クラスタに最新のセキュリティ修正が適用されているように、可能な限り最新のパッチ バージョンにアップグレードすることをおすすめします。パッチ バージョンは、バージョン スキューとアップグレード ルールには影響しません。任意のマイナー バージョンをより上位のパッチ バージョンにアップグレードできます。つまり、Y が X より大きければ、1.30.X バージョン クラスタをバージョン 1.30.Y にアップグレードできます。たとえば、1.29.0 から 1.29.1 にアップグレードしたり、1.29.1 から 1.29.3 にアップグレードできます。
次のステップ
アップグレードのベスト プラクティスで、クラスタのアップグレード プランを作成する