このドキュメントでは、プラットフォーム管理者が 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 は、たとえば、本番環境の残りの部分をアップグレードする前に、本番環境でカナリア環境をアップグレードできます。
新しい環境にはおすすめしませんが、以前のバージョンの機能であるフリートベースのロールアウト シーケンスを使用することもできます。このバージョンの機能は、Google Cloud コンソールでサポートされている唯一のバージョンですが、機能はより限定的です。
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 Disruption Budget（PDB）を使用すると、アップグレード中に GKE がノードを再作成するときに、ワークロードのレプリカ数が一時的に減少する可能性がある場合でも、ワークロードに十分な冗長性を維持できます。
PDB が設定されている場合、Pod の数が構成された上限以下の場合、GKE はアプリケーションの Pod をシャットダウンしません。GKE アップグレードでは、PDB が最大 60 分間適用されます。また、GKE は、ノードのドレインが PDB によってブロックされている場合、または PDB タイムアウトに達し、PDB 違反にもかかわらず Pod が強制的に削除される場合に通知します。詳細については、ノードプールのアップグレード中の中断イベントをご覧ください。
グレースフル ターミネーションを使用してアプリケーションをシャットダウンする
正常な終了を構成すると、ワークロードがシャットダウンの準備に十分な時間を確保できます。ノードのアップグレード中、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 クラスタの機能を比較するをご覧ください。