クラスタのアップグレードに関するベスト プラクティス

このページでは、Google Kubernetes Engine（GKE）クラスタを常に最新の状態にしておくためのガイドラインと、要件に合わせて環境の可用性と信頼性を高めるアップグレード戦略を作成する際の推奨事項について説明します。これにより、ワークロードの中断を最小限に抑えながら、クラスタを常に最新の状態にし、安定性とセキュリティを維持できます。

また、フリートで編成された本番環境全体でクラスタの自動アップグレードを管理するには、ロールアウト シーケンスによるクラスタのアップグレードについてをご覧ください。

複数の環境を設定する

ソフトウェアの更新を提供するワークフローの一環として、複数の環境を使用することをおすすめします。複数の環境を用意し、本番環境とは別の環境でソフトウェアとインフラストラクチャの更新をテストすることで、リスクや不要なダウンタイムを最小限に抑えることができます。少なくとも、本番環境以外に本番前環境またはテスト環境が必要です。

次の推奨環境を検討してください。

環境 説明
本番 ミッション クリティカルなビジネス アプリケーションのエンドユーザーにライブ トラフィックを提供します。
ステージング 本番環境にデプロイする前に、以前の環境に行ったすべての変更が意図したとおりに機能していることを確認します。
テスト 本番環境で使用する GKE リリースのパフォーマンス ベンチマーク、テスト、QA を行います。この環境では、本番環境で実行する前に、コントロール プレーンとノードのアップグレードをテストできます。
開発 本番環境で実行されているバージョンと同じバージョンで開発を行います。この環境では、本番環境にデプロイする修正と増分変更を作成します。
Canary 新しい Kubernetes リリース、GKE の機能、API をテストするセカンダリ開発環境として使用します。これらのリリースが昇格し、自動アップグレードのターゲットになってから市場投入までの時間を短縮できます。

リリース チャンネルにクラスタを登録する

Kubernetes は、セキュリティ更新の提供、既知の問題の修正、新機能の導入を行うため、アップデートを頻繁にリリースしています。GKE のリリース チャンネルを使用すると、クラスタにデプロイされるバージョンの安定性と機能セットのバランスを取ることができます。リリース チャンネルに新しいクラスタを登録すると、Google によりクラスタとノードプールのバージョンとアップグレード サイクルが自動的に管理されます。

GKE と Kubernetes の最新のアップデートでクラスタを常に最新の状態にしておくために推奨される環境と、クラスタを登録するリリース チャンネルは次のとおりです。

環境 リリース チャンネル 説明
本番環境 Stable または Regular 本番環境のワークロードには安定性とバージョンの成熟度が必要なため、Stable または Regular チャンネルを使用します。
ステージング 本番環境と同じ アップグレードされる本番環境のバージョンをテストするため、本番環境と同じリリース チャンネルを使用します。
テスト
開発
カナリア Rapid 新しい GKE 機能または API をテストして、最新の Kubernetes リリースのテストや最新機能の実装を行うには、Rapid チャンネルを使用します。Rapid チャンネルのバージョンが本番環境で使用するチャンネルに昇格した場合、製品化までの時間を短縮できます。
なし Extended 標準サポートの終了日を過ぎてもセキュリティ パッチを受け取り、クラスタを長期間マイナー バージョンで維持する場合は、Extended チャンネルを使用します。詳しくは、長期サポートが必要な場合に Extended チャンネルを使用するをご覧ください。

クラスタのコントロール プレーンは、クラスタがリリース チャンネルに登録されているかどうかにかかわらず、定期的にアップグレードされます。

継続的なアップグレード戦略を作成する

クラスタをリリース チャンネルに登録すると、そのクラスタは、チャンネルの品質と安定性の基準を満たしたバージョンに定期的にアップグレードされます。これらのアップデートには、セキュリティとバグの修正に加え、各チャンネルでの調査を重ねて適用されています。

  • パッチは、Stable チャンネルに移動する前に、Rapid チャンネルと Regular チャンネルに配置され、すべてのチャンネルのコントロール プレーンとノードに段階的に push されます。
  • Kubernetes OSS ポリシーに準拠するため、コントロール プレーンが先にアップグレードされ、その後、ノードがアップグレードされます。kubelet は、kube-apiserver と同じか、それよりも前のバージョンでなければなりません。
  • GKE は、その重大度と重要度に基づいて、パッチをチャンネルに自動的にロールアウトします。
  • Stable チャンネルは、重要なパッチのみを受け取ります。

新しい GKE バージョンに関する最新情報を受け取る

新しいバージョンに関する情報は、メインの GKE リリースノート ページと RSS フィードに公開されています。各リリース チャンネルには、簡素化された専用のリリースノート ページ（例: Stable チャンネルのリリースノート）があり、そのチャンネルの推奨 GKE バージョンに関する情報が提供されています。

アップグレードが発生する前に GKE のアップグレードに関する更新情報を積極的に受け取るには、Pub/Sub を使用してアップグレードの通知に登録します。

新しいバージョンが利用可能になったら、バージョンがクラスタの自動アップグレード ターゲットになるまでにアップグレードを計画する必要があります。このアプローチでは、利用可能な自動アップグレードのターゲットが、クラスタをすでに手動でアップグレードしたバージョンより前または同じバージョンの場合、GKE はクラスタを自動アップグレードしないため、必要に応じて制御と予測性が向上します。特定のクラスタの自動アップグレード ターゲットを取得するには、クラスタのアップグレードに関する情報の取得（プレビュー）をご覧ください。

新しいパッチとマイナー バージョンをテストして検証する

リリースしたチャンネルに関係なく、どのリリースも内部テストに合格しています。ただし、アップストリームの Kubernetes と GKE からアップデートとパッチが頻繁に提供されるため、リリースが Kubernetes のマイナー バージョン アップグレードなどの本番環境にロールアウトされる前に、テスト環境やステージング環境で新しいリリースをテストすることを強くおすすめします。

各リリース チャンネルには、クラスタ作成用のデフォルト バージョンや自動アップグレード ターゲットなど、複数の利用可能なバージョンがあります。

  • 自動アップグレードの対象になる 1 週間前に、新しいパッチリリースが利用可能になります。
  • 新しい Kubernetes マイナー リリースは、自動アップグレードのターゲットになる 4 週間前に利用可能になります。

GKE は、クラスタを新しいバージョンに自動的にアップグレードします。アップグレード プロセスをより細かく制御する必要がある場合は、前もって利用可能なバージョンにアップグレードすることをおすすめします。GKE は、手動でアップグレードされたクラスタを同じ自動アップグレード ターゲットに自動アップグレードしません。

アップグレードの自動化と効率化には、次のようなアプローチが効果的です。

  • 利用可能なバージョンを本番前環境で使用する。
  • クラスタにアップグレード通知を設定し、テストと認定に利用可能な新しいバージョンをチームに伝える。
  • 本番環境をリリース チャンネルに登録し、本番前環境ですでにテスト済みのバージョンを使用する。
  • 本番環境クラスタで使用可能な新しいバージョンを段階的にロールアウトする。たとえば、複数の本番環境クラスタで段階的なアップグレードを行う場合、クラスタの一部を利用可能なバージョンにアップグレードして、残りは既存のバージョンのままにしておきます。次に、一部のクラスタのみをアップグレードします。すべてのクラスタがアップグレードされるまで、この処理を繰り返します。

次の表は、リリース イベントと推奨される対応をまとめたものです。

イベント 推奨される対応
新しいバージョン X がチャンネルで利用可能になった。 テストクラスタを手動でアップグレードし、新しいバージョンのテストと認定を行います。
バージョン X は、クラスタのマイナー バージョンの自動アップグレード ターゲットになります。 GKE が自動アップグレード ターゲットへの自動アップグレードを開始します。フリートの前に本番環境をアップグレードすることを検討してください。
GKE がクラスタの自動アップグレードを開始した。 クラスタで自動アップグレードを許可するか、メンテナンスの時間枠の除外を使用してアップグレードを延期します。

パッチリリースのアップグレード戦略

次のようなシナリオを使用して、パッチリリースの推奨戦略を説明します。

  • すべてのクラスタが Stable チャンネルに登録される。
  • 新たに利用可能なバージョンは、まずステージング クラスタにロールアウトされる。
  • 本番環境クラスタは、新しい自動アップグレード ターゲットに自動的にアップグレードされます。
  • GKE で利用可能な新しいバージョンを定期的にモニタリングする。
時間 イベント 必要な対策
T - 1 週間 新しいパッチ バージョンがリリースされます。 ステージング環境をアップグレードします。
T パッチ バージョンが自動アップグレードのターゲットになります。 予測の精度を高めるため、本番環境のコントロール プレーンを早めにアップグレードすることを検討してください。
T GKE が自動アップグレードのターゲットへのコントロール プレーンのアップグレードを開始します。 予測の精度を高めるため、本番環境のノードプールを事前にアップグレードすることを検討してください。
T + 1 週間 GKE がクラスタ ノードプールを自動アップグレード ターゲットにアップグレードします。 GKE は、クラスタを自動アップグレードして、手動でアップグレードされたクラスタをスキップします。

新しいマイナー リリースのアップグレード戦略

新しいマイナー リリースに推奨のアップグレード戦略は次のとおりです。

時間 イベント 必要な対策
T - 3 週間 新しいマイナー バージョンが利用可能になります。 テスト用のコントロール プレーンをアップグレードします。
T - 2 週間
  1. コントロール プレーンのアップグレードが正常に成功したら、本番環境のコントロール プレーンを早めにアップグレードすることを検討してください。
  2. テスト用のノードプールをアップグレードします。
T - 1 週間 アップグレードが正常に完了したら、本番環境のノードプールを早めにアップグレードすることを検討してください。
T マイナー バージョンが自動アップグレードのターゲットになります。
T GKE がクラスタ コントロール プレーンの自動アップグレード ターゲットへのアップグレードを開始します。 本番環境へのロールアウト前にさらにテストや回避策が必要な場合は、除外ウィンドウを作成します。
T + 1 週間 GKE がクラスタ ノードプールを自動アップグレード ターゲットにアップグレードします。 GKE は、クラスタを自動アップグレードして、手動でアップグレードされたクラスタをスキップします。

アップグレード中の既存のワークロードの中断を低減する

セキュリティ パッチとバグ修正を使用してクラスタを最新の状態に保つことは、クラスタの健全性とビジネスの継続性を維持するために重要です。定期的な更新により、ワークロードが脆弱性や障害から保護されます。

メンテナンスの時間枠と除外をスケジュールする

アップグレードの予測可能性を高め、アップグレードをオフピーク時に調整するため、メンテナンスの時間枠を作成して、コントロール プレーンとノードの両方の自動アップグレードを制御します。GKE ではメンテナンスの時間枠が適用されます。つまり、アップグレード プロセスが指定されたメンテナンスの時間枠を超えて実行されると、GKE はオペレーションを一時停止し、次のメンテナンスの時間枠で再開しようとします。

GKE は、数日間のロールアウト スケジュールに沿って、新しいバージョンを利用可能にするとともに、異なるリージョンのクラスタ コントロール プレーンとノードを自動アップグレードします。通常、ロールアウトの期間は 4 日以上になります。それには、問題の観察とモニタリングのためのバッファ時間も含まれます。マルチクラスタ環境では、クラスタごとに分かれたメンテナンスの時間枠を使用して、クラスタ間でロールアウトを順序付けできます。たとえば、クラスタごとに異なるメンテナンスの時間枠を設定して、異なるリージョンのクラスタがメンテナンスを受けるタイミングを制御できます。

中断を低減する別の方法として、特に需要の高い時間帯をメンテナンスから除外する方法があります。メンテナンスの除外を適用して、これらの期間中に自動メンテナンスが発生しないようにします。メンテナンスの除外は新規または既存のクラスタに設定できます。除外機能はアップグレード戦略と併用することもできます。 たとえば、アップグレードが原因でテスト環境やステージング環境が失敗する場合は、本番環境クラスタへのアップグレードを延期することもできます。

中断の許容範囲を設定する

Kubernetes のレプリカというコンセプトについては、聞きなじみがあるのではないでしょうか。レプリカは、ワークロードの冗長性を確保することによって、パフォーマンスとレスポンスを向上させる役割を果たします。レプリカを設定すると、ある特定の時点で実行される Pod レプリカの数が制御されるようになります。しかしメンテナンス中には、Kubernetes は基になるノード VM を削除するため、レプリカの数が減ることがあります。メンテナンス中でも、ワークロードにアプリケーションの十分な数のレプリカを確保するには、Pod 停止予算（PDB）を使用します。

Pod 停止予算では、Pod の終了で現在のレプリカ数が目的の値を下回る場合でも、終了できる Pod の数（または割合）を定義できます。このプロセスでは、移行した Pod が完全に動作するのを待たずに、ノードのドレインを高速化できます。代わりに、ドレインは PDB 構成に従いノードから Pod を退避させ、欠落している Pod を他の利用可能なノード上にデプロイできるようにします。PDB を設定した場合、Pod の数が構成された上限を超えなければ、GKE はアプリケーション内の Pod をシャットダウンしません。GKE は PDB を最大 60 分間追跡します。

ノードプールのアップグレードを制御する

GKE でノードのアップグレード戦略を選択して、お使いのノードプールにおけるノードのアップグレード方法を決定できます。デフォルトでは、サージ アップグレードが使用されます。サージ アップグレードを使用すると、GKE ノードプールのアップグレード プロセスでノードプール内のすべての VM が再作成されます。新しい VM はローリング アップデート方式で新しいバージョン（アップグレードされたイメージ）を使用して作成されます。そのため、古いノードで実行されているすべての Pod をシャットダウンし、新しいノードに移行する必要があります。ワークロードは十分な冗長性（レプリカ）で実行できます。Kubernetes を使用して、必要に応じて Pod の移動や再起動を行うことができます。ただし、レプリカの数が一時的に減少すると業務を中断しなければならない可能性があり、Kubernetes が再び目的の状態（必要なレプリカの最小数）になるまで、ワークロードのパフォーマンスが低下することがあります。サージ アップグレードを使用すると、このような中断を回避できます。

サージ アップグレードを有効にしたアップグレードの場合、GKE はまずアップグレードに必要なリソース（マシン）を保護し、アップグレード済みの新しいノードを作成します。さらに、古いノードのみをドレインして、最後にシャットダウンします。こうして、アップグレード プロセス全体で想定の容量が維持されます。

アップグレード プロセスに時間がかかるような大規模なクラスタでは、一度に複数のノードを同時にアップグレードすることで、アップグレード完了時間を短縮できます。maxSurge=20 と maxUnavailable=0 でサージ アップグレードを使用し、既存の容量を使用せずに一度に 20 個のノードをアップグレードするように GKE に指示します。

長期サポートが必要な場合に Extended チャンネルを使用する

クラスタをマイナー バージョンで長期間維持する場合は、ベスト プラクティスに従って、クラスタを Extended チャンネルに登録します。このチャネルでは、GKE はマイナー バージョンを約 24 か月間サポートします。詳しくは、Extended チャンネルで長期サポートを利用するをご覧ください。

チャンネルを最大限に活用するには、次のベスト プラクティスに従うことをおすすめします。これらのベスト プラクティスの一部では、クラスタを手動でアップグレードする、クラスタのリリース チャンネルを変更するなど、手動での操作が必要になります。サポートされているシナリオと Extended チャネルを使用すべきでない場合を確認してください。

一時的にマイナー バージョンを長期間維持する

次のマイナー バージョンで削除される非推奨の API の使用を軽減するため、14 か月の標準サポート期間よりも長くクラスタをマイナー バージョンにしておく必要がある場合は、次の操作を行います。別のリリース チャンネルから Extended チャンネルにクラスタを一時的に移動することで、次のマイナー バージョンへのアップグレードの準備を進めながら、セキュリティ パッチを引き続き受け取ることができます。次のマイナー バージョンにアップグレードする準備ができたら、クラスタを手動でアップグレードしてから、クラスタを元のリリース チャンネルに戻します。

マイナー バージョンのアップグレード（年に 1～2 回）

クラスタを新しいマイナー バージョンにアップグレードする準備が整ったときに、クラスタの機能停止を最小限に抑えながら新しい機能を利用できるようにするには、次の操作を行います。

  • クラスタを Extended チャンネルに登録します。
  • 年に 1～2 回、2 回連続してマイナー バージョンのアップグレードを行います。たとえば、1.30 から 1.31 にアップグレードして、さらに 1.32 にアップグレードします。

このプロセスにより、クラスタは利用可能なマイナー バージョンを維持しながら、新しいマイナー バージョンの機能を受け取ることができますが、クラスタの準備が整ったと判断した場合にのみ、マイナー バージョンのアップグレードを受け取ります。

Extended チャネルを使用すべきでない場合

Extended チャンネルを本来の目的で使用するには、手動での操作が必要です。次のシナリオは、クラスタのマイナー バージョンを積極的に管理せずに Extended チャンネルを使用した場合の結果を示しています。

何もせずに同じ頻度でマイナー アップグレードを受け取る

クラスタをマイナー バージョンで維持するため、クラスタを Extended チャンネルに登録しますが、それ以上の操作は行いません。すべてのマイナー バージョンは最終的にサポートされなくなり、GKE はサポートされていないマイナー バージョンのクラスタを自動的にアップグレードします。そのため、GKE は、サポート対象外のマイナー バージョンからサポートが終了するマイナー バージョンにクラスタをアップグレードします。平均すると、約 4 か月ごとにアップグレードが行われます。クラスタは他のリリース チャンネルと同じ頻度でマイナー バージョンのアップグレードを受け取りますが、新機能は後で受け取ることになります。

チェックリストの概要

次の表に、GKE クラスタを最新状態に保つためにアップグレード戦略で推奨されるタスクを示します。

ベスト プラクティス タスク
複数の環境を設定する
リリース チャンネルにクラスタを登録する
継続的なアップグレード戦略を作成する
既存のワークロードの中断を低減する

次のステップ