このドキュメントでは、プラットフォーム管理者が Google Kubernetes Engine（GKE）クラスタのアップグレードを管理するためのベスト プラクティスについて説明します。デフォルトでは、GKE はクラスタのコントロール プレーンとノードのバージョンを自動的にアップグレードし、新機能、バグの修正、セキュリティ パッチを提供して、環境のパフォーマンスとセキュリティを維持します。
これらの自動アップグレードが運用上のニーズに沿って行われ、ワークロードの中断を最小限に抑えるために、GKE は最大限の制御を可能にするツールを提供しています。このガイドでは、これらのツールを効果的に使用して、高いパフォーマンスと可用性を維持する方法について説明します。基本的な理解については、GKE クラスタのアップグレードについてをご覧ください。
クラスタのアップグレード（コントロール プレーンとノードの GKE バージョンの更新のみ）に加えて、GKE はクラスタに対して定期的に追加の更新を行います。このドキュメントのベスト プラクティスを実装することで、これらのタイプの変更の一部に対応できます。詳細については、クラスタのライフサイクルの変更を管理して中断を最小限に抑えるをご覧ください。
すべての GKE ベスト プラクティスの概要については、GKE のベスト プラクティスをご覧ください。チェックリスト
次の表は、以降のセクションで詳しく説明するタスクをまとめたものです。クラスタのアップグレード用に環境を準備するときに、これらのタスクを行うことをおすすめします。
| ベスト プラクティス | ToDo リスト |
|---|---|
| リリース チャンネルを使用して機能のリリース速度とアップグレードの安定性のバランスを選択する | |
| メンテナンス ポリシーでアップグレードのタイミングを選択する | |
| クラスタ間のアップグレードのロールアウトを制御する | |
| アップグレードのトリガー方法を制御する | |
| クラスタのアップグレードをモニタリングする | |
| ノードのアップグレード中に既存のワークロードの中断を最小限に抑える |
リリース チャンネルを使用して機能のリリース速度とアップグレードの安定性のバランスを選択する
リリース チャンネルを使用すると、機能のリリース速度とアップグレードの安定性のバランスを選択できます。デフォルトでは、GKE クラスタは Regular リリース チャンネルに登録されます。GKE がクラスタのコントロール プレーンとノードをアップグレードして、セキュリティ パッチを適用し、既知の問題を修正し、新機能を導入する場合、リリース チャンネルによってクラスタで実行される GKE バージョンが決まります。たとえば、新機能をいち早く利用したい場合は Rapid チャンネルを選択し、安定性が実証されているバージョンを利用したい場合は Stable チャンネルを選択します。特定のチャンネルの選択について詳しくは、利用可能なチャンネルをご覧ください。
クラスタを手動でアップグレードする場合でも、新しいバージョンを選択する前に、チャンネルで利用可能なバージョンと自動アップグレード ターゲットを確認することで、リリース チャンネルの選択のメリットを享受できます。
また、リリース チャンネルでパッチ バージョンをできるだけ早く取得する場合（たとえば、重要なセキュリティ パッチを受け取る場合）は、以前のパッチ バージョンの取得についてをご覧ください。
マイナー バージョンに必要なサポートのレベルを選択する
GKE では、マイナー バージョンが Regular チャンネルで利用可能になった後、そのバージョンに対して合計で最長 24 か月間のサポートを提供します。このサポートには、14 か月間の標準サポートと、Extended チャンネルで利用できる約 10 か月間の拡張サポートが含まれます。GKE がマイナー バージョンをサポートする方法の詳細については、マイナー バージョンのサポートをご覧ください。
標準サポートの終了日を過ぎてもセキュリティ パッチを受け取り、クラスタを長期間マイナー バージョンで維持する必要がある場合や、標準サポートの終了の適用を回避する場合は、Extended チャンネルを使用することもできます。詳細については、後述の長期サポートが必要な場合に Extended チャンネルを使用するをご覧ください。
マイナー バージョンのサポートが終了すると、クラスタが登録されているリリース チャンネルに応じて、GKE はクラスタを自動的にアップグレードし、クラスタのパフォーマンスとセキュリティを維持します。詳細については、セキュリティと互換性を確保するための自動クラスタ アップグレードをご覧ください。このドキュメントで説明するツールを使用してクラスタの自動アップグレードを阻止または遅延させている場合は、クラスタが実行しているマイナー バージョンのサポートが終了する前に、クラスタを手動でアップグレードすることをおすすめします。それ以外の場合、GKE はクラスタを自動的にアップグレードします。
メンテナンス ポリシーでアップグレードのタイミングを選択する
アップグレードの実行可否を制御するには、次のものを使用します。
- メンテナンスの時間枠: GKE がクラスタをアップグレードできる繰り返しの時間枠（ビジネスの営業時間外など）を選択します。アップグレード プロセスがメンテナンスの時間枠を超えて実行されると、GKE はオペレーションを一時停止し、次のメンテナンスの時間枠の間に再開を試みます。
- メンテナンスの除外: GKE がクラスタをアップグレードできない特定の期間（小売業の主要な販売イベントなど）を選択します。また、メンテナンスの除外を使用して、クラスタの自動アップグレードを一時的に延期することもできます。たとえば、他のクラスタが新しいバージョンにアップグレードされたときに問題が発生した場合などです。
- 高度なユースケースでは、GKE が実行するのではなく、特定のタイプのアップグレードを手動で実行する必要がある場合があります。メンテナンスの除外を使用して、これらのタイプの自動アップグレードを無効にできます。たとえば、「マイナー アップグレードまたはノード アップグレードなし」のスコープを使用して、すべてのマイナー アップグレードとすべてのノード アップグレードを無効にできます。これらのアップグレードは手動で行う必要があります。または、GKE がマイナー バージョンのサポート終了時にクラスタをアップグレードします。
- メンテナンス頻度: 高度なユースケースでは、クラスタ停止予算を使用して、連続する 2 つの自動アップグレード間の最小間隔を制御します。
メンテナンス ポリシーを構成することで、アップグレードの予測可能性を高め、ワークロードにとって最も都合のよいタイミングでアップグレードが行われるようにすることができます。
クラスタ間のアップグレードのロールアウトを制御する
複数の環境を用意し、本番環境とは別の環境でソフトウェアとインフラストラクチャの変更をテストすることで、リスクや不要なダウンタイムを最小限に抑えることをおすすめします。少なくとも、本番環境と本番前環境またはテスト環境を用意することをおすすめします。
次の推奨環境を検討してください。
| 環境 | 説明 |
|---|---|
| 本番環境 | ミッション クリティカルなビジネス アプリケーションのエンドユーザーにライブ トラフィックを提供します。 |
| カナリア | すべてのクラスタがアップグレードされる前に、本番環境の小規模な部分をテストします。 |
| ステージング | 本番環境にデプロイする前に、以前の環境で行ったすべての変更が意図したとおりに機能していることを確認します。 |
| テスト | 本番環境で使用する GKE バージョンでワークロードのベンチマーク、テスト、品質保証（QA）を実施します。 |
| 開発 | 本番環境で実行されているバージョンと同じバージョンで開発を行います。この環境では、本番環境にデプロイする修正と増分変更を作成します。 |
GKE には、次のセクションで説明するように、ロールアウトの順序付けなどの機能が用意されており、これらのさまざまな環境にアップグレードをデプロイする方法を制御できます。
ロールアウト シーケンスを使用して環境全体にロールアウトする
これらの環境内で新しい GKE バージョンを段階的にロールアウトするには、ロールアウト シーケンスを使用することをおすすめします。ロールアウト シーケンスでは、すべてのクラスタがデプロイのステージ全体で同じリリース チャンネルとマイナー バージョンを使用します。GKE は、構成した順序で新しいバージョンを段階的にロールアウトします。GKE が新しいバージョンを環境全体にロールアウトしたら、クラスタ環境とワークロードが新しいバージョンで期待どおりに実行されていることを確認できます。
新しい環境を構成する場合は、カスタム ステージを使用したロールアウト シーケンス（プレビュー）を使用します。この新しいバージョンのロールアウト シーケンスでは、新しいバージョンのフリートへのロールアウトを複数のステージに分割できます。このアプローチでは、たとえば、GKE は本番環境の残りの部分をアップグレードする前に、本番環境のカナリア環境をアップグレードできます。または、カスタム ステージのないより線形なモデルを使用する機能の一般提供バージョンについては、ロールアウト シーケンスを使用したクラスタ アップグレードについてをご覧ください。
GKE パッチとマイナー アップグレードのテスト
GKE は、クラスタを新しいパッチに毎週自動的にアップグレードします。ただし、マイナー バージョンのアップグレードは年に約 3 回しか行われません。新しい Kubernetes マイナー バージョンでは、同じマイナー バージョンのパッチと比較して、変更の量が多くなります。環境全体でマイナー バージョンのアップグレードをロールアウトする際は、新しいマイナー バージョンがクラスタとワークロードで想定どおりに動作することを確認するため、追加の精査を行うことをおすすめします。
クラスタをアップグレードする前にチェックを実行する
GKE は、クラスタの自動アップグレードを実行する前に、リリース チャンネルに応じて一定期間、新しいバージョンを検証し、クラスタの準備状況を確認します。
クラスタをアップグレードする前に、次のことを行うことをおすすめします。
- パッチ アップグレードやマイナー アップグレードを含むすべてのアップグレードの場合:
- 問題については GKE リリースノートを確認し、新しいマイナー バージョンとパッチ バージョンの変更ログを確認します。
- GKE の既知の問題で、クラスタ環境と新しいバージョンに関連する問題がないか確認します。
- マイナー アップグレードの場合は、次の点も確認してください。
- API の非推奨を確認します。詳細については、新しいバージョンの GKE リリースノート、Kubernetes の変更ログ、機能と API の非推奨をご覧ください。
- コントロール プレーンとノード間のバージョン スキューがサポートされていることを確認します。GKE は、コントロール プレーンの 2 つ前までのマイナー バージョンのノードの実行をサポートしています。詳細については、 GKE バージョンのスキュー ポリシーをご覧ください。
- ノードのアップグレードの場合:
- ノードで使用するノード アップグレード戦略に十分なリソースがあることを確認します。詳細については、ノードのアップグレード用のリソースを確保するをご覧ください。
アップグレードのトリガー方法を制御する
GKE は、デフォルトでクラスタを新しいバージョンに定期的に自動アップグレードします。ただし、手動アップグレードを使用すると、クラスタを必要なタイミングでアップグレードし、クラスタが実行するバージョンを制御することもできます。
以下の操作を行うことができます。
- クラスタを手動でアップグレードします。
進行中の自動または手動のノード アップグレードに対して、次の操作を行います。
- アップグレードをキャンセルします。
- アップグレードを再開します。
- アップグレードをロールバックします。
- 進行中のアップグレードを完了します。
アップグレード プロセスをより細かく制御する場合は、メンテナンス除外を構成し、必要に応じて手動アップグレードを行うことをおすすめします。手動アップグレードと、進行中のアップグレードに対して実行できるその他のアクションの詳細については、クラスタまたはノードプールの手動アップグレードをご覧ください。
クラスタのアップグレードをモニタリングする
GKE アップグレードが想定どおりに進行し、クラスタ環境のパフォーマンスと可用性が維持されるように、次のツールを使用してクラスタのアップグレードをモニタリングします。クラスタのステータスを把握するには、通知、分析情報と推奨事項、ログなどのツールを使用します。特に、サポート終了通知、アップグレード開始通知、マイナー バージョン アップグレードのオプトイン スケジュール アップグレード通知に注意することをおすすめします。アラート ポリシーを設定して、これらの通知を確実に受け取れるようにします。
現在のアップグレードについて詳しくは、次のリソースをご覧ください。
- 現在の自動アップグレード ターゲットなど、特定のクラスタのアップグレードについては、クラスタのアップグレードの可視性を高めるをご覧ください。
- 一般的な自動アップグレード ターゲットを取得するには、現在のバージョンの表をご覧ください。クラスタのマイナー バージョンへの特定のマッピングについては、バージョン アップデートのリリースノートをご覧ください。
- GKE リリース スケジュールで、マイナー バージョンがアップグレード可能になり、サポート終了になるおおよその日付をご確認ください。
- クラスタ通知を使用して、Cloud Logging または Pub/Sub によりクラスタのアップグレード イベント（スケジュール設定されたクラスタ アップグレード（プレビュー）など）に関する最新情報を入手します。
分析情報と推奨事項を使用して、次のクラスタ固有の推奨事項を取得します。
ノードのアップグレード中に既存のワークロードの中断を最小限に抑える
前のセクションで説明した一般的なベスト プラクティスに加えて、クラスタ環境とワークロードのニーズに合わせてアップグレード プロセスをさらにカスタマイズするために、高度な構成を検討することをおすすめします。
特定のワークロード プロファイルに関するその他の考慮事項
特定のタイプのワークロードとクラスタ環境では、クラスタのアップグレードに追加の準備が必要です。ワークロードが次のカテゴリの 1 つ以上に該当する場合は、次の追加の考慮事項を検討してください。
- ライブ マイグレーションされないマシンで実行されるワークロード: GKE ノード（GKE がユーザーに代わって作成する Compute Engine インスタンス）では、基盤となるインフラストラクチャのメンテナンスが定期的に必要になります。ほとんどの Compute Engine インスタンスはライブ マイグレーションできます。つまり、このメンテナンスが発生しても、実行中のワークロードが中断されることはありません。ただし、一部のマシンタイプではライブ マイグレーションを実行できないため、GKE ノードで実行されているワークロードが中断される可能性があります。重要な点として、AI/ML ワークロード用の GPU や TPU などのアクセラレータはライブ マイグレーションできません。詳細については、ライブ マイグレーションが行われない GKE ノードの停止を管理するをご覧ください。
- 容量が制約されたワークロード: ワークロードで容量が制約されたマシンタイプを使用している場合は、クラスタのアップグレードを実行する際に、追加の考慮事項が必要です。詳細については、ノードのアップグレード用のリソースを確保するをご覧ください。
- ステートフル ワークロード: ワークロードがステートフルで、正常なシャットダウンと再起動に関する特定の要件がある場合は、クラスタのアップグレードを実行する際に、追加の考慮事項が必要になります。詳細については、ワークロードが停止可能な状態であることを確認するをご覧ください。
以降のセクションで、使用可能なツールを使用してこれらのタイプのワークロードをアップグレードする方法を確認してください。
ノードのアップグレード戦略を選択する
GKE Standard モードでは、ノードプール内の個々のノードのアップグレード方法を決定するさまざまなノード アップグレード戦略が用意されています。Standard ノードプールのアップグレード戦略を選択すると、速度、ワークロードの中断、リスクの軽減、費用の最適化のバランスを取ったプロセスを選択できます。ニーズに合わせて戦略のパラメータを構成することもできます。GKE Autopilot モードでは、GKE がノードのアップグレードを管理するため、使用する特定の戦略を選択する必要はありません。詳細については、ノードのアップグレード戦略についてをご覧ください。
中断の許容範囲を設定する
Pod 停止予算（PDB）を使用すると、アップグレード中に GKE がノードを再作成するときに、ワークロードのレプリカ数が一時的に減少する可能性がある場合でも、ワークロードに十分な冗長性を維持できます。
PDB が設定されている場合、Pod の数が構成された上限以下であれば、GKE はアプリケーション内の Pod をシャットダウンしません。GKE アップグレードでは、PDB が最大 60 分間適用されます。また、ノードのドレインが PDB によってブロックされている場合、または PDB のタイムアウトに達し、PDB の違反にもかかわらず Pod が強制的に削除される場合、GKE は通知します。詳細については、ノードプールのアップグレード中の破壊的イベントをご覧ください。
正常な終了を使用してアプリケーションをシャットダウンする
正常な終了を構成すると、ワークロードがシャットダウンの準備に十分な時間を確保できます。ノードのアップグレード中、GKE はデフォルトのサージ アップグレードで最大 60 分間、Blue/Green アップグレードと自動スケーリングされる Blue/Green アップグレード（プレビュー）で最大 24 時間、正常終了設定を適用します。
正常終了の設定の詳細については、ワークロードを正常に終了するように GKE を構成するをご覧ください。
長期サポートが必要な場合に Extended チャンネルを使用する
クラスタをマイナー バージョンで長期間維持する場合は、ベスト プラクティスに従って、クラスタを Extended チャンネルに登録します。このチャネルでは、GKE はマイナー バージョンを約 24 か月間サポートします。Extended チャンネルでは、マイナー バージョンのアップグレードを制御できます。GKE は、ユーザーがアップグレードを開始しない場合にのみ、サポート終了時の自動アップグレードを実行します。詳細については、Extended チャンネルで長期サポートを利用するをご覧ください。
標準のサポート期間よりも長くマイナー バージョンを維持する必要はないが、マイナー バージョンのアップグレードを制御したい場合は、「マイナー アップグレードなし」のスコープでメンテナンスの除外を使用します。
チャンネルを最大限に活用するには、次のベスト プラクティスに従うことをおすすめします。これらのベスト プラクティスの一部では、クラスタを手動でアップグレードする、クラスタのリリース チャンネルを変更するなど、手動での操作が必要になります。サポートされているシナリオと Extended チャネルを使用すべきでない場合を確認してください。
一時的にマイナー バージョンを長期間維持する
次のマイナー バージョンで削除される非推奨の API の使用を軽減するため、14 か月の標準サポート期間よりも長くクラスタをマイナー バージョンにしておく必要がある場合は、次の操作を行います。別のリリース チャンネルから Extended チャンネルにクラスタを一時的に移動することで、次のマイナー バージョンへのアップグレードの準備を進めながら、セキュリティ パッチを引き続き受け取ることができます。次のマイナー バージョンにアップグレードする準備ができたら、クラスタを手動でアップグレードしてから、クラスタを元のリリース チャンネルに戻します。
マイナー バージョンのアップグレード（年に 1 ～ 2 回）
クラスタを新しいマイナー バージョンにアップグレードする準備が整ったときに、クラスタの機能停止を最小限に抑えながら新しい機能を利用できるようにするには、次の操作を行います。
- クラスタを Extended チャンネルに登録します。
- 年に 1 ～ 2 回、2 回連続してマイナー バージョンのアップグレードを行います。たとえば、1.33 から 1.34 にアップグレードして、さらに 1.35 にアップグレードします。
このプロセスにより、クラスタは利用可能なマイナー バージョンを維持しながら、新しいマイナー バージョンの機能を受け取ることができますが、クラスタの準備が整ったと判断した場合にのみ、マイナー バージョンのアップグレードを受け取ります。
Extended チャネルを使用すべきでない場合
Extended チャンネルを本来の目的で使用するには、手動での操作が必要です。次のシナリオは、クラスタのマイナー バージョンを積極的に管理せずに Extended チャンネルを使用した場合の結果を示しています。
何もせずに同じ頻度でマイナー アップグレードを受け取る
クラスタをマイナー バージョンで維持するため、クラスタを Extended チャンネルに登録しますが、それ以上の操作は行いません。すべてのマイナー バージョンは最終的にサポートされなくなり、GKE はサポートされていないマイナー バージョンのクラスタを自動的にアップグレードします。そのため、GKE は、サポート対象外のマイナー バージョンからサポートが終了するマイナー バージョンにクラスタをアップグレードします。平均すると、約 4 か月ごとにアップグレードが行われます。このアプローチでは、クラスタは他のリリース チャンネルと同じ頻度でマイナー バージョンのアップグレードを受け取りますが、新機能は後で受け取ることになります。
次のステップ
- GKE のさまざまなモードの詳細については、Autopilot クラスタと Standard クラスタの機能を比較するをご覧ください。