GKE のバージョニングとサポート

---

このページでは、Google Kubernetes Engine（GKE）のバージョニングと、バージョン サポートのポリシーについて説明します。現在のバージョンのロールアウトとサポート スケジュールについては、GKE リリース スケジュールをご覧ください。

注: Kubernetes API は Kubernetes 自体とは別にバージョニングされます。Kubernetes API のバージョニングについては、Kubernetes API のドキュメントをご覧ください。

バージョン サポート

Kubernetes のマイナー バージョンの GKE サポートは、Kubernetes オープンソース ポリシーに基づいています。GKE は、同じマイナー リリースのパッチ バージョンを提供し、定期的にクラスタを新しいパッチに自動的にアップグレードすることで、マイナー バージョンをサポートします。

Kubernetes がマイナー バージョンをサポートする方法

Kubernetes オープンソース ソフトウェア（OSS）コミュニティは、新機能や機能強化を盛り込んだマイナー バージョンを年 3 回リリースしています。各リリース サイクルは約 15 週間です。

Kubernetes では、各マイナー バージョンが 14 か月間サポートされます。サポートされているマイナー バージョンで見つかった重大なバグやセキュリティの脆弱性は、アドホック パッチ バージョンのリリースによって修正されます。バージョンのサポート カレンダーは、Kubernetes コミュニティによって必要に応じて更新される場合があります。詳細については、サポート期間をご覧ください。

GKE がマイナー バージョンをサポートする方法

Kubernetes が新しいマイナー バージョンをリリースすると、GKE はまず Rapid チャンネルでマイナー バージョンを導入します。この期間中、GKE はパッチ バージョンを提供しますが、Rapid チャンネルでは最新の GKE バージョンが提供されるため、これらのバージョンは GKE SLA から除外されます。このため、既知の解決策のない問題が存在する可能性があります。

Rapid チャンネルで最初に利用可能になった後、GKE は新しいマイナー バージョンを Regular チャンネルにプロモートします。そのバージョンが Regular チャンネルで新しいクラスタの作成に使用可能になると、GKE はマイナー バージョンに対して合計で最長 24 か月間のサポートを提供します。このサポートには、標準サポートが約 14 か月間、Extended チャンネルで利用できる拡張サポートがさらに約 10 か月間含まれます。特定のマイナー バージョンの提供状況については、GKE リリース スケジュールをご覧ください。

GKE マイナー バージョンのライフサイクル

GKE マイナー バージョンのライフサイクルには、次の主なステップが含まれます。

1. Kubernetes が新しいマイナー バージョンをリリースします。
2. GKE が新しいマイナー バージョンを Rapid チャンネルで利用できるようにします。
3. GKE が新しいマイナー バージョンを Regular チャンネルで利用できるようにします（標準サポート期間の開始）。
4. 標準サポートの期間中、GKE は新機能、セキュリティに関する修正、バグの修正を含むマイナー バージョンのパッチを提供します。
5. マイナー バージョンは、合計で約 14 か月後に標準サポートが終了し、拡張サポート期間に入ります。これ以降、GKE は Extended チャンネルのクラスタにセキュリティ パッチを提供します。
6. マイナー バージョンの拡張サポートが終了します。つまり、マイナー バージョンにセキュリティ パッチが提供されなくなります。

バージョンの提供状況の調整

Kubernetes OSS コミュニティのポリシーの変更、脆弱性の検出、効果的な解決策のない技術的な問題のために、GKE バージョンのサポート終了日が変更される場合があります。また、ブラック フライデーやサイバー マンデーなどの重要なビジネス期間にサポート終了日が延長されることもあります。

GKE は 14 か月以上の標準サポートを提供しており、サポート期間は拡張サポートを含めて合計で最長 24 か月間になります。

使用可能な最新バージョンについては、GKE リリースノートをご覧ください。GKE は、自動アップグレードのタイミングを反映するようにリリース スケジュールを定期的に更新します。

マイナー バージョンのライフサイクルにおける利用期間

GKE は、Kubernetes のマイナー バージョンについて次の利用期間を設けています。

次の表に、利用期間の概要を示します。詳細については、次のセクションをご覧ください。

利用期間	Regular チャンネルにおける提供開始からのおおよその期間	GKE が提供するサポート	この利用期間のアクセス
Rapid のみの利用期間	-1～0 か月目	GKE は、新機能、セキュリティに関する修正、バグの修正を含むパッチ バージョンを提供します。ただし、これらのバージョンは GKE SLA から除外されるため、既知の解決策のない問題が存在する可能性があります。	Rapid チャンネルのみ
標準サポート期間	1～14 か月目	GKE は、新機能、セキュリティに関する修正、バグの修正を含むパッチ バージョンを提供します。	Rapid、Regular、Stable、Extended の各チャンネル、チャンネルなし
拡張サポート期間	15～24 か月目	GKE は、セキュリティに関する修正を含むパッチ バージョンを提供します。	Extended チャンネルのみ（GKE Enterprise またはクラスタごとの追加料金が必要です。Extended チャンネルで長期サポートを利用するをご覧ください）

Rapid のみの利用期間

GKE は、まず Rapid チャンネルで新しいマイナー バージョンをリリースします。バージョンは、まずこのチャンネルのクラスタ全体で使用実績を積んで安定性が実証されてから、Regular チャンネルにプロモートされます。この利用期間中に新しいマイナー バージョンを実行できるのは、Rapid チャンネルに登録されているクラスタだけです。

この期間は通常 1～2 か月ほどですが、正確なタイミングはマイナー バージョンによって異なります。詳しくは、リリース チャンネルのスケジュールをご覧ください。

標準サポート期間

GKE マイナー バージョンの標準サポート期間は、そのバージョンが Regular チャンネルにリリースされたときに開始されます。すべての GKE クラスタは、リリース チャンネルに登録されているかどうかに関係なく、標準サポートでマイナー バージョンを実行できます。この期間中、GKE はクラスタを定期的に新しいパッチ バージョンに自動でアップグレードします。このパッチ バージョンには、新機能、セキュリティに関する修正、バグの修正が含まれます。

GKE は、次の方法でクラスタを自動的にアップグレードします。

• Rapid、Regular、Stable の各チャンネル、チャンネルなし: サポートされている他のマイナー バージョン、または同じマイナー バージョンのパッチ バージョンへの自動アップグレード。
• Extended: GKE は、同じマイナー バージョンの新しいパッチ バージョンにのみ自動的にアップグレードします。

Extended リリース チャンネルに登録されていないクラスタの場合、GKE は、クラスタのリリース チャンネルのスケジュールに基づいて、標準サポートが終了する前に、クラスタを最終的に次のサポート対象のマイナー バージョンに自動でアップグレードします。詳しくは、リリース チャンネルのスケジュールをご覧ください。ただし、クラスタで非推奨の機能または API を使用している場合、GKE はこの期間中にクラスタをアップグレードしません。メンテナンスの除外を使用すると、GKE がクラスタを次のマイナー バージョンにアップグレードするのを一時停止できます。

標準サポートの終了（以前の「サポート終了」）

注: GKE では以前、標準サポートの終了日を「サポート終了」という用語で表していました。拡張サポートの導入に伴い、GKE マイナー バージョンの複数のサポート期間を反映するようにこの用語を更新しました。

標準サポート期間が終了すると、マイナー バージョンは標準サポートの終了（以前の「サポート終了」）に達し、Extended チャンネルに登録されていないすべてのクラスタでサポート対象外となり、利用できなくなります。

サポート終了バージョンを実行しているお客様は、バージョンのサポートが終了する前にプロジェクトの連絡先に通知メールが届きます。GKE は、セキュリティと互換性を目的としてサポート対象外のバージョンを実行しているノードの自動アップグレードを段階的に開始します（この処理は自動アップグレードが有効かどうかにかかわらず行われます）。これは、サポート終了後に新しいセキュリティ パッチやバグの修正は行われないためです。サポート対象外のバージョンを実行しているクラスタまたはノードで問題が発生した場合は、Cloud カスタマーケアを利用する前に、サポート対象バージョンにアップグレードする必要があります。

サポートが終了した GKE のマイナー バージョンに対してはセキュリティ パッチやバグの修正は提供されません。サポートが終了したマイナー バージョンのパッチ バージョンは、サポート対象外であり使用できません。GKE は、Extended チャンネルに登録されていないすべてのクラスタを自動的にアップグレードします。詳しくは、サポート終了時の自動アップグレードをご覧ください。

拡張サポート期間

標準サポートの終了後、マイナー バージョンは拡張サポート期間（15～24 か月目）に入ります。この期間中、GKE はセキュリティに関する修正のパッチを提供します。パッチには、次の種類の修正が含まれます。

• GKE クラスタ バージョンにバンドルされているコア Kubernetes コンポーネント、ノード オペレーティング システム、Google が管理するコンテナ向けの、重大度が中、高、重要のセキュリティ パッチ。
• Container-Optimized OS の場合、GKE マイナー バージョンの拡張サポートが終了する前にノード オペレーティング システムのサポートが終了する可能性があります。また、互換性のない変更が導入される可能性があります。GKE が引き続きサポートを提供する方法の詳細については、拡張サポート期間中の Container-Optimized OS のアップデートをご覧ください。

拡張サポートの終了に向けて、GKE はクラスタを次のマイナー バージョンにアップグレードし始めます。非推奨の機能または API を使用しているクラスタは、GKE によってアップグレードされません。メンテナンスの除外を使用すると、GKE がクラスタを次のマイナー バージョンにアップグレードするのを一時停止できます。

拡張サポートの終了

拡張サポートの終了後、GKE はセキュリティに関する修正のパッチを提供しません。マイナー バージョンはサポート対象外と見なされます。GKE は、サポート対象外のマイナー バージョンを実行しているクラスタを、クラスタで非推奨の機能や API が使用されているかどうかに関係なく、次のマイナー バージョンにアップグレードします。

サポート終了時の自動アップグレード

GKE は、マイナー バージョンのサポートが終了する前に、クラスタのマイナー バージョンから次のサポート対象マイナー バージョンへの自動アップグレードをスケジュールします。このアップグレードのタイミングは、クラスタのリリース チャンネルのスケジュールによって異なります。詳しくは、リリース チャンネルのスケジュールをご覧ください。たとえば、Stable チャンネルに登録されているクラスタが次のマイナー バージョンにアップグレードされるタイミングは、Rapid チャンネルに登録されているクラスタと比べて、標準サポートの終了に近いタイミングになります。

標準サポート期間中、および Extended チャンネルに登録されているクラスタの拡張サポート期間中は、メンテナンスの除外を使用してこのマイナー バージョンのアップグレードを停止できます。また、非推奨の機能または API を使用しているクラスタは、GKE によってアップグレードされません。

ただし、標準サポートの終了時、または Extended チャンネルに登録されているクラスタの拡張サポートの終了時に、GKE はクラスタを次のサポート対象のマイナー バージョンに自動的にアップグレードし、クラスタのパフォーマンス、可用性、安全性を維持します。

各 GKE バージョンは、標準サポートで 14 か月間、拡張サポートを含めて合計 24 か月間サポートされます。サポート終了後はセキュリティ パッチやバグの修正が提供されないため、サポート対象外の GKE バージョンを使用しているクラスタを運用すると、セキュリティ、信頼度、互換性について重大なリスクが生じます。そのため、クラスタを特定のバージョンに無期限に保持することはできません。GKE は、サポートが終了したバージョンのパッチやアップデートの提供を約束できません。

GKE は次の方法でクラスタをアップグレードします。

• コントロール プレーン: 新しいクラスタの作成にそのコントロール プレーン バージョンが利用できなくなったときに、GKE はクラスタ コントロール プレーンをサポート対象のバージョンに自動的にアップグレードします。
• ノード: バージョンのサポート終了後にサポート対象外となったバージョンを実行しているノードが自動的にアップグレードされ、クラスタの健全性および GKE バージョン スキュー ポリシーとの整合性が確保されます。サポート対象外のバージョンを実行しているノードは、通常、サポート終了日から 1 か月以内にサポート対象バージョンに自動アップグレードされるようにスケジュール設定されています。サポート対象外のバージョンを実行しているノードは、バージョンがサポート終了となってもすぐにアップグレードされない場合があり、実際のタイミングは Google の裁量で変わる可能性があります。

拡張サポート期間中の Container-Optimized OS のアップデート

GKE マイナー バージョンの拡張サポート期間中、GKE はクラスタのパッチ アップグレードを提供します。これには、Container-Optimized OS のアップデートが含まれる場合があります。

Container-Optimized OS LTS リリースがマイナー バージョンより先にサポート終了となる

Container-Optimized OS LTS リリースは、そのリリースを使用しているマイナー バージョンの拡張サポートの終了より先にサポートが終了する場合があります。このシナリオでは、GKE は、可能な限り、今後のパッチ アップグレードに使用できる次の Container-Optimized OS LTS リリースを使用します。GKE は、ノードのマイナー バージョンで使用されている Container-Optimized OS LTS リリースのサポートが終了する前に、この更新を行います。クラスタ管理者は、新しい Container-Optimized OS LTS リリースを含む次の GKE パッチ バージョンにアップグレードするか、同じ GKE パッチ バージョンを使い続けて、ノード オペレーティング システムのアップデートを受け取らず、GKE クラスタ バージョンにバンドルされているコア Kubernetes コンポーネントのセキュリティ パッチも受け取らないかを判断する必要があります。

次の Container-Optimized OS LTS リリースで既存のマイナー バージョンと互換性のない変更が導入される

次の Container-Optimized OS LTS リリースで、GKE システム コンポーネントと互換性のない変更が導入される可能性があります。GKE は、ノード オペレーティング システムのアップデートを含むパッチ バージョンを提供できません。クラスタ管理者は、次の GKE マイナー バージョンにアップグレードするか、前の段落で説明したトレードオフを検討するかを判断する必要があります。

バージョニング体系

GKE では、Kubernetes のセマンティック バージョニングの業界標準に GKE のパッチ バージョンを付加した形式（x.y.z-gke.N）を採用しています。

Kubernetes メジャー バージョン（x）

メジャー バージョンは、下位非互換性の変更が公開 API に導入された場合に増加します。メジャー バージョンでは、Kubernetes バージョンが x.y から x+1.y に上がります。

Kubernetes のマイナー バージョン（y）

Kubernetes の新しいマイナー バージョンは、年 3 回リリースされます。各リリース サイクルは約 15 週間です。非推奨 API は、新しいマイナー バージョン（1.22 など）で削除される可能性があります。マイナー バージョンがリリースされるたびに Kubernetes のバージョンが 1.y から 1.y+1 に上がります。たとえば、Kubernetes 1.31 の次のマイナー リリースは Kubernetes 1.32 になります。

Kubernetes パッチリリース（z）

通常、GKE で使用される新しい Kubernetes のパッチリリース（1.32.6 など）は毎週提供されます。パッチリリースは、各ゾーンに段階的にロールアウトされます。

GKE パッチリリース（-gke.N）

-gke.N という接尾辞が付加されたパッチリリース（1.32.6-gke.N など）には、オープンソースのアップストリーム Kubernetes ソフトウェアに加えて GKE のセキュリティ アップデートやバグの修正が組み込まれています。これらのアップデートや修正は、Google Cloud との互換性と相互運用性を維持するために必要です。

利用可能なバージョンとデフォルト バージョンの確認

利用可能なバージョンについては、GKE リリースノートをご覧ください。

特定のゾーンで利用可能な Kubernetes のバージョンとデフォルト バージョンは、Google Cloud コンソールまたは Google Cloud CLI でも確認できます。

Google Cloud コンソールを使用してバージョンを確認する

注: チャンネルのデフォルト バージョンより前のバージョンを表示するには、gcloud CLI と Kubernetes Engine API を使用する必要があります。

デフォルト バージョンと利用可能なバージョンを確認する手順は次のとおりです。

1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. [ 作成] をクリックします。

3. Standard クラスタモードを選択し、[構成] をクリックします。

4. [ロケーション タイプ] セクションで、クラスタのロケーション タイプと目的のロケーションを選択します。

5. [コントロール プレーンのバージョン] セクションで、リリース チャンネルを選択します。チャンネルで利用可能なすべてのバージョンが一覧表示されます。デフォルト バージョンが自動的に選択されています。

注: バージョンのロールアウトが完了する前に Google Cloud コンソールを使用してクラスタを作成すると、該当のゾーンで利用可能なバージョンのリストが不正確になる場合があります。

gcloud CLI を使用してバージョンを確認する

利用可能なバージョンとデフォルト バージョンを確認するには、クラスタタイプに応じて次のいずれかの gcloud コマンドを実行します。各タブで、特定のリリース チャンネルのバージョンまたはチャネルなし（静的）のバージョンを確認するためのコマンドを説明します。

Rapid

Rapid リリース チャンネルのデフォルトと使用可能なバージョンを確認するには、次のコマンドを実行します。

デフォルトのバージョン

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=RAPID" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

利用可能なバージョン

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=RAPID" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

次のように置き換えます。

• COMPUTE_LOCATION: Compute Engine のロケーション。

Regular

Regular リリース チャンネルのデフォルトと使用可能なバージョンを確認するには、次のコマンドを実行します。

デフォルトのバージョン

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=REGULAR" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

利用可能なバージョン

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=REGULAR" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

次のように置き換えます。

• COMPUTE_LOCATION: Compute Engine のロケーション。

Stable

Stable リリース チャンネルのデフォルトと使用可能なバージョンを確認するには、次のコマンドを実行します。

デフォルトのバージョン

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=STABLE" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

利用可能なバージョン

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=STABLE" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

次のように置き換えます。

• COMPUTE_LOCATION: Compute Engine のロケーション。

Extended

Extended リリース チャンネルのデフォルトと使用可能なバージョンを確認するには、次のコマンドを実行します。

デフォルトのバージョン

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=EXTENDED" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

利用可能なバージョン

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=EXTENDED" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

次のように置き換えます。

• COMPUTE_LOCATION: Compute Engine のロケーション。

チャンネルなし

チャンネルなし（静的）のデフォルト バージョンと使用可能なバージョンを確認するには、次のコマンドを実行します。

デフォルトのバージョン

gcloud container get-server-config \
   --format="yaml(defaultClusterVersion)" \
   --location=COMPUTE_LOCATION

使用可能なコントロール プレーンのバージョン

gcloud container get-server-config \
   --format="yaml(validMasterVersions)" \
   --location=COMPUTE_LOCATION

使用可能なノードのバージョン

gcloud container get-server-config \
   --format="yaml(validNodeVersions)" \
   --location=COMPUTE_LOCATION

次のように置き換えます。

• COMPUTE_LOCATION: Compute Engine のロケーション。

注: 高度な get-server-config 出力の操作については、gcloud ドキュメントのフィルタリングとフォーマットをご覧ください。

クラスタ バージョンの指定

このセクションは、Standard モードで作成されたクラスタにのみ適用されます。

gcloud CLI を使用してクラスタを作成またはアップグレードする場合は、--cluster-version フラグを使用してクラスタ バージョンを指定できます。特定のバージョン（1.9.7-gke.N など）を使用できます。バージョンのエイリアスを使用することも可能です。

• latest: クラスタのゾーンまたはリージョンの GKE で現在利用可能なサポート対象の Kubernetes バージョンのうち最も番号が大きいものを指定します。
• 1.X: 1.X のマイナー バージョンのうち、最も番号が大きい有効なパッチ + gke.N パッチリリースを指定します。
• 1.X.Y: 1.X.Y パッチリリースのうち、最も番号が大きい有効な gke.N パッチを指定します。
• -: クラスタ コントロール プレーンの場合は、コントロール プレーンのデフォルト Kubernetes バージョンを指定します。ノードのアップグレードの場合は、クラスタ コントロール プレーンが走行しているバージョンを指定します。

バージョンに latest を指定してクラスタを作成またはアップグレードしても、自動アップグレードは行われません。クラスタ内のノードを常に最新の安定バージョンにするには、ノードの自動アップグレードを有効にします。

ノード バージョンの指定

このセクションは、Standard モードで作成されたクラスタにのみ適用されます。Autopilot クラスタでは、ノードはコントロール プレーンのバージョンに自動的にアップグレードされ、バージョンを指定することはできません。

ノードプールを作成またはアップグレードする際に、ノードプールのバージョンを指定できます。デフォルトでは、ノードはコントロール プレーンと同じバージョンの GKE を実行します。ノードは、コントロール プレーンよりも 2 つ前のマイナー バージョンより古いバージョンを実行できません。

まれなケースとして、クラスタのバージョンが利用できなくなってもノードのバージョンを使用できる場合があります。

GKE バージョン スキュー ポリシー

GKE バージョン スキュー ポリシーにより、GKE クラスタはコントロール プレーンとノード間の互換性を維持します。GKE クラスタでは、ノードはコントロール プレーンのバージョンと一致するか、コントロール プレーンの 2 つ前までのマイナー バージョンを実行できます。

ノードは、コントロール プレーンのバージョンより新しいバージョンを実行できません。たとえば、クラスタのコントロール プレーンがバージョン 1.31 を実行している場合、ノードは 1.31、1.30、1.29 のバージョンを実行できますが、1.28 以前のバージョンは実行できません。Kubernetes OSS バージョン スキュー ポリシーにより、ノードのバージョンはコントロール プレーンのバージョンよりも新しいバージョンにすることはできません。

サポートと信頼度を維持するため、有効なバージョン スキューに関係なく、ノードでサポート対象のバージョンを使用する必要があります。

マイナー バージョンのスキップのサポート

GKE ではクラスタ コントロール プレーンのマイナー バージョンをスキップすることはできませんが、パッチ バージョンをスキップすることは可能です。ワーカーノードではマイナー バージョンをスキップできます。たとえば、ノードプールを 1.32 から 1.34 にアップグレードできます（1.33 はスキップ）。

複数のマイナー バージョン間でクラスタをアップグレードするには、コントロール プレーンをマイナー バージョンごとに 1 つずつアップグレードし、ワーカーノードを毎回同じバージョンにアップグレードします。たとえば、コントロール プレーンをバージョン 1.32 から 1.34 にアップグレードするには、まずバージョン 1.32 から 1.33 にアップグレードしてから、コントロール プレーンに合わせてワーカーノードをアップグレードします。この処理を繰り返してバージョン 1.33 から 1.34 にアップグレードします。

ワーカーノードをバージョンに合わせてアップグレードすると、サポートされていないバージョンのスキューを回避できます。バージョンのスキップは極力行わないことをおすすめします。ワーカーノード バージョンをスキップするとテスト範囲が広くなり、対応は可能ではあるものの、検討事項が多くなりがちです。

代替策として、目的のバージョンで新しいクラスタを作成し、ワークロードを再デプロイするという方法も一つです。