複数の環境で、Google Kubernetes Engine（GKE）クラスタ全体にわたるクラスタの自動アップグレードの順序を管理するには、ロールアウトの順序付けを使用します。たとえば、本番環境クラスタをアップグレードする前に、本番前環境クラスタで新しいバージョンの適格性を確認できます。この機能を使用するには、クラスタのアップグレード、リリース チャンネル、フリート管理を理解している必要があります。
開始するには、クラスタのアップグレードのロールアウトを順序付けるをご覧ください。
用語
このドキュメントでは、フリートやチームスコープの両方を「グループ」という用語で表します。ロールアウト シーケンスはどちらのグループ化の方法でも作成できるためです。
複数の環境にわたってアップグレードの適格性を評価する
ロールアウト シーケンスによってクラスタを自動でアップグレードするには、フリートまたはチームスコープを使用します。これらは、同じリリース チャンネルとマイナー バージョンを持つクラスタをデプロイのステージにグループ化したものです。フリートまたはチームスコープの順序を選択し、クラスタの各グループ間に必要なソークテスト時間を設定します。次に、GKE がリリース チャンネルで自動アップグレード用の新しいバージョンを選択すると、定義した順序でクラスタのグループがアップグレードされ、本番環境クラスタでアップグレードを開始する前に、ワークロードが新しいバージョンで期待どおりに実行されることを検証できます。
フリートベースのロールアウト順序
次の図は、GKE がクラスタを、フリートで編成されたロールアウト順序で自動でアップグレードする仕組みを示しています。
フリートベースの順序では、すべてのクラスタがこの順序で登録されているリリース チャンネルで、新しいアップグレード ターゲットを GKE が利用できるようにすると、GKE はこの並びの中にあるクラスタのフリートをアップグレードします。このとき、上流のフリート内のクラスタは、最大 3 つの下流のフリートに対し、その中のクラスタに新しいバージョンを適用します。ロールアウト シーケンスにおいて、アップストリームは前のグループを指し、ダウンストリームは次のグループを指します。
フリート間で構成されたソーク時間（アップグレードがアップストリーム フリートで完了してから、ダウンストリーム フリートで開始されるまでの時間）中に、アップグレードされたクラスタでワークロードが期待どおりに実行されていることを確認できます。
チームベースのロールアウト順序
フリート内のクラスタをチームまたはアプリケーションでさらに細分化した場合は、チームスコープ間でロールアウト順序を作成できます。チームスコープは、フリート クラスタのサブセットを特定のアプリケーション チームに関連付けるための Enterprise フリートレベルの構造で、アクセス制御、チームスコープのオブザーバビリティ、ロールアウト順序など、さまざまなチームベースの機能を有効にするために使用できます。
チームスコープでは、フリート内に複数のロールアウト順序を作成し、それぞれに独自のリリース チャンネル、アップグレード ターゲット、独立したソーク時間を設定できます。チームベースのロールアウト順序は、フリートベースのロールアウト順序と同じように機能します。ただし、アップグレードの適格性は、フリートからフリートではなく、各フリート内の特定のチームのクラスタ間で評価される点が異なります。これは、自分のチームのクラスタ内でアップグレードを管理するアプリケーション オペレータに特に便利です。
チームベースのロールアウトの順序付けはプレビュー版ですが、フリートベースのロールアウトの順序付けは一般提供（GA）です。
GKE がロールアウト順序でクラスタをアップグレードする仕組み
GKE がクラスタをアップグレードする場合は、まずコントロール プレーンがアップグレードされ、次にノードがアップグレードされます。ロールアウト順序では、クラスタはこのプロセスでアップグレードされますが、クラスタのグループ（フリートまたはスコープ）がアップグレードされる順序も制御できます。また、ソーク時間を指定して、あるグループから次のグループへアップグレードを進める前に GKE が一時停止する時間を選択します。
ロールアウト順序でのクラスタのアップグレードは、次の手順で行います。
- GKE が、特定のリリース チャンネル（リリースノートに「Regular チャンネルで自動アップグレードが有効になっているコントロール プレーンとノードは、このリリースでバージョン 1.21 からバージョン 1.22.15-gke.1000 にアップグレードされる」というようなメッセージが記載されている）にあるマイナー バージョンのクラスタに新しい自動アップグレード ターゲットを設定します。
- GKE が、クラスタの最初のグループで、クラスタ コントロール プレーンの新しいバージョンへのアップグレードを開始します。GKE は、クラスタのコントロール プレーンがアップグレードした後、クラスタのノードのアップグレードを開始します。ロールアウト順序に従ってクラスタをアップグレードする場合、GKE はメンテナンスの時間枠や除外を尊重します。
- コントロール プレーンのアップグレードの場合、GKE は次の操作を行います。
- 最初のグループのクラスタ コントロール プレーンのアップグレードがすべて終了するか、アップグレードの開始から 30 日が経過すると、GKE によってコントロール プレーンのアップグレードのソーク期間が開始されます。
- 最初のグループでクラスタ コントロール プレーンのアップグレードのソーク期間が完了すると、GKE によって 2 番目のグループでコントロール プレーンのアップグレードが開始されます。
- コントロール プレーンのアップグレードと並行して、GKE はノードのアップグレード用に次の手順を行います。
- 最初のグループのすべてのクラスタのノード アップグレードが完了するか、アップグレードを開始して 30 日が経過すると、GKE によってノード アップグレードのソーク期間が開始されます。
- 最初のグループのノード アップグレードのソーク期間が終わると、GKE は、すでにコントロール プレーンがアップグレードされているクラスタの 2 番目のグループでノードのアップグレードを開始します。
- ロールアウト順序内のすべてのグループのクラスタが新しいアップグレード対象にアップグレードされるまで、GKE は 2 番目のグループから 3 番目のグループにこの手順を繰り返します。
それぞれのグループでクラスタがアップグレードされたら、ソーク期間中に、ワークロードが、新しい GKE バージョンを実行しているクラスタで期待どおり実行されていることを確認します。
また、メンテナンスの時間枠や除外、非推奨の API の使用などの理由で、クラスタをアップグレードできないこともあります。詳細については、ロールアウトの順序付けが他のアップグレード機能と連動する仕組みをご覧ください。
ロールアウト順序でのアップグレードを制御する方法
クラスタのロールアウト順序でのアップグレードでは、クラスタのグループを定義された順序でアップグレードし、各グループで決められた時間ソークします。アップグレードの進行中に、必要に応じてロールアウト順序のステータスの確認やロールアウト順序の管理が可能です。次の方法でプロセスを制御することもできます。
- ロールアウト順序に入るグループについて、特定のバージョンのソークを増減する必要がある場合は、デフォルトのソーク時間をオーバーライドできます。
- 個々のクラスタのアップグレードでは、引き続き次のツールを使用できます。
- ノードプールのアップグレードのキャンセル、再開、ロールバック、完了などの操作を行うアップグレードの手動制御。
- メンテナンスの時間枠と除外を使用して、クラスタのアップグレードを許可するタイミングとできないタイミングを決める。
- ノードのアップグレード戦略を構成し、ノードで実行されるワークロードに応じてスピードとリスク許容度のバランスを取る。
詳細については、ロールアウトの順序付けが他のアップグレード機能と連動する仕組みをご覧ください。
例: コミュニティ バンクで変更をテスト環境から本番環境まで段階的にロールアウトする
たとえば、あるコミュニティ バンクのプラットフォーム管理者が、テスト、ステージング、本番という 3 つの主要なデプロイ環境（それぞれ、フリートで編成されたクラスタのグループ）を管理しているとします。ロールアウトの順序付けに必要とされるとおり、管理者は、3 つのフリートすべてにわたって各クラスタを同じリリース チャンネル（これらのフリートでは Regular チャンネル）に登録し、すべてのクラスタで同じマイナー バージョンを実行しています。
管理者は、ロールアウトの順序付けを使用して、GKE がこれらの環境のクラスタをアップグレードする順序を定義します。ロールアウトの順序を決めることで、管理者は、本番環境を新しいバージョンへアップグレードする前に、新しいバージョンの GKE のクラスタで、ワークロードが想定どおりに実行されることを確認できます。この順序は、フリートベースのロールアウト順序の図に示しています。
管理者は、こうしたフリートがアップグレードされる間のソーク時間を使用して、新しいバージョンの GKE にあるクラスタでワークロードが期待どおりに動作することを確認します。テストフリートでは、管理者が、ワークロードの動作を確認するテストに丸 2 週間を確保できるように、ソーク時間を 14 日に設定します。ステージングでは、ワークロードがすでにテストで実行された後で、それほど追加の時間を必要としないため、ソーク時間を 7 日に設定します。
管理者は、特定のバージョンへのアップグレードに対するデフォルトのソーク時間をオーバーライドすることもできます。これは、次のような状況で行えます。
- ソーク時間が終わる前に、管理者がバージョンの適格性評価を終了し、アップグレードを次のフリートに進める場合にソーク時間をゼロに設定する。
- 管理者が、一部のワークロードに問題があることに気づいたため、アップグレードを次のフリートに進める前に新しいバージョンの適格性を評価する時間が必要な場合に、ソーク時間を最大の 30 日に設定する。
管理者はメンテナンスの時間枠と除外を使用して、銀行への影響が最も少ないときに GKE がクラスタをアップグレードするようにします。GKE では、ロールアウト順序でアップグレードされるクラスタのメンテナンスの時間枠や除外が尊重されます。
- 管理者は、GKE が営業時間後にのみクラスタをアップグレードするように、クラスタのメンテナンスの時間枠を構成しています。
- また、管理者はメンテナンスの除外を使用して、クラスタのワークロードに関する問題を検出した場合に、クラスタのアップグレードを一時的に停止します。
管理者は、ノード上で実行されるワークロードに応じてスピードとリスクの許容範囲のバランスをとりながら、ノードに対してサージ アップグレードと Blue / Green アップグレードを組み合わせて使用します。
管理者がチームベースのロールアウト順序に切り替える
管理者が、フリート内のクラスタをさらにアプリケーション別にグループ化して、アプリケーション チームの管理者がクラスタのアップグレードをより細かく制御できるようにする必要があると判断した場合は、チームスコープを使用できます。チームスコープを使用すると、アプリケーション チームの管理者は、チームに割り当てられたクラスタのグループを使用して、異なるリリース チャンネルや異なるソーク時間で実行される可能性のある独立したロールアウト順序を作成できます。
たとえば、データベース チームがクラスタで Stable チャンネルと長いソーク時間を使用する一方、フロントエンド ウェブサイト チームのクラスタでは Rapid チャンネルと短いソーク時間を使用する場合、チームスコープを使用して個別のロールアウト順序を作成できます。このタイプの順序は、チームベースのロールアウト順序の図に示しています。お使いの環境でこれを行うには、手順に沿ってフリートベースとチームベースのロールアウト順序を切り替えてください。
この機能を使用するには、単一テナンシー クラスタが必要です。つまり、個々のクラスタは 1 つのチームにのみ関連付けられます。共有クラスタ（一般的なフリートチーム管理でサポート）は、ロールアウトの順序付けではサポートされていません。チームのクラスタ管理の詳細については、フリートのチーム管理をご覧ください。
ロールアウトの適格性
ロールアウトの順序付けを使用してクラスタを自動でアップグレードするには、ロールアウト順序内のすべてのグループ（フリートまたはスコープ）のすべてのクラスタが同じアップグレード ターゲットを受け取る必要があります。クラスタは同じリリース チャンネルに登録する必要があり、アップグレード ターゲットはマイナー バージョンごとに設定されるため、クラスタでは同じマイナー バージョンを実行することをおすすめします。ただし、次の例のリリースのように、複数のマイナー バージョンのクラスタが同じターゲットを受け取る場合もあります。これは、複数のマイナー バージョンを実行しているロールアウト順序で、クラスタが正常にアップグレードできることを意味します。
バージョンを順にロールアウトする中でのステータスを確認して、ステータスの詳細や、バージョンの適格性の問題によってアップグレードの続行が妨げられているかどうかの詳細を得ることができます。バージョンの不一致によっては、クラスタの手動アップグレードや、クラスタをグループから削除してアップグレードを続行するなどの操作が必要になる場合があります。ロールアウト シーケンス内のクラスタに適格なアップグレード ターゲットがない場合は、クラスタの既存のマイナー バージョンがサポート終了になるまで、GKE はクラスタを自動アップグレードしません。
ロールアウトの適格性に関するトラブルシューティングについては、ロールアウトの適格性に関するトラブルシューティングをご覧ください。
GKE リリースの例
たとえば、2022-R25 リリースでは、Regular チャンネルに登録されているクラスタに複数のマイナー バージョンに対して 1 つのアップグレード ターゲットを設定します。アップグレード ターゲットは、新しいマイナー バージョン（1.20～1.21）か、新しいパッチ バージョン（1.21.x-gke.x～1.21.14-gke.4300）のいずれかです。このリリースの Regular チャンネルでは、特定のマイナー バージョンのクラスタで次の新しいバージョンが利用可能になりました。
- 1.20 と 1.21 のクラスタは 1.21.14-gke.4300 にアップグレードされました。
- 1.22 のクラスタは 1.23.8-gke.1900 にアップグレードされました。
- 1.24 のクラスタは 1.24.5-gke.600 にアップグレードされました。
最上流のグループですべてのアップグレード ターゲットを受け取る
順序の最初のグループ（新しいバージョンの適格性を評価する上流のグループがない）にあるクラスタの場合、GKE は、アップグレード ターゲットがそれぞれ異なるかどうかにかかわらず、適格性のあるアップグレード ターゲットを持つクラスタをアップグレードします。たとえば、順序の最初のグループで一部のクラスタが 1.20 で実行されている場合、そうしたクラスタは 1.21.14-gke.4300 にアップグレードされ、1.24 が実行されているクラスタは 1.24.5-gke.600 にアップグレードされます。順序の最初のグループでは、新しいバージョンの適格性を評価する上流のグループがないため、GKE が、すべてのアップグレード ターゲットをこうしたクラスタに対して適格性があるとみなすためです。
上流のグループは 1 つのバージョンのみ適格性を評価する必要がある
下流のグループで GKE がクラスタをアップグレードできるかどうかは、上流のグループが、このグループ内のすべてのクラスタが対象となる 1 つのアップグレード ターゲットを適格性があると評価しているかどうかによって変わります。通常これは、すべてのクラスタが同じマイナー バージョンで起動されることを意味します。ただし、リリース例以降、1.20 と 1.21 のクラスタは同じアップグレード ターゲットを持つため、両方のバージョンを実行しているクラスタが同じグループで、1.21.14-gke.4300 へのアップグレードを適格性があると評価できます。
1 つのグループ内のすべてのクラスタで同じアップグレード ターゲットがない場合、このグループは次のグループに対して、あるアップグレード ターゲットを適格性があると評価できません。この場合、GKE は、下流グループのクラスタを自動でアップグレードできません。たとえば、最初のグループで、一部のクラスタが 1.21.14-gke.4300 にアップグレードされ、他のクラスタが 1.23.8-gke.1900 にアップグレードされた場合、2 番目のグループのクラスタは、1 つの適格性があるバージョンを受け取っていないため、自動ではアップグレートされません。この状況でアップグレードを進めるには、グループ内の適格性を修正するをご覧ください。
上流のグループは次のグループのクラスタと一致するバージョンの適格性を評価する必要がある
上流グループのクラスタが、次のグループ内のクラスタに適格なバージョンとは異なるバージョンを適格とした場合、GKE は下流グループのクラスタも自動でアップグレードできません。
たとえば、最初のグループのすべてのクラスタが 1.21.14-gke.4300 にアップグレードされているにもかかわらず、2 番目のグループのクラスタが 1.22（アップグレード ターゲットは 1.23.8-gke.1900）を実行している場合、2 番目のグループのクラスタは自動でアップグレードされません。最初のグループは 1.21.14-gke.4300 を適格としましたが、2 番目のグループのクラスタ（現在は 1.22）はアップグレード ターゲットが 1.23.8-gke.1900 のみであるため、GKE はこれらのクラスタを自動でアップグレードできません。この状況でアップグレードを進めるには、グループ間の適格性を修正するをご覧ください。
ロールアウトの順序付けと他のアップグレード機能が連動する仕組み
ロールアウトの順序付けは、クラスタのライフサイクルのアップグレードの側面を制御できる一連の機能の一つです。このセクションでは、この機能がクラスタのアップグレードに関連する他の利用可能な機能と連動する仕組みについて説明します。
ロールアウトの順序付けがメンテナンスの時間枠や除外と連動する仕組み
GKE では、ロールアウトの順序付けを使用してクラスタをアップグレードする場合、メンテナンスの時間枠とメンテナンスの除外が尊重されます。GKE は、クラスタのメンテナンスの時間枠内でのみクラスタのアップグレードを開始します。メンテナンスの除外は、クラスタのアップグレードを一時停止するために使用できます。メンテナンスの時間枠やメンテナンスの除外により GKE がクラスタをアップグレードできない場合は、グループ内のクラスタのアップグレードが終了しなくなることがあります。メンテナンスの時間枠やメンテナンスの除外により、30 日以内にクラスタのアップグレードを完了できない場合、すべてのクラスタのアップグレードが完了したかどうかにかかわらず、そのグループはソークフェーズに入ります。
メンテナンスの除外を一時的な手段として使用することで、グループへのロールアウトが完了して次のグループへ移行することを防ぐことができます。詳細については、グループのバージョンのロールアウトの完了を遅らせるをご覧ください。
ロールアウトの順序付けと非推奨の使用状況の検出が連動する仕組み
GKE は、特定の非推奨の API や機能の使用を検出すると、クラスタのアップグレードを一時停止します。ロールアウト順序の中のグループ内にあるクラスタの自動アップグレードも一時停止されます。詳細については、GKE で Kubernetes の非推奨が機能する仕組みをご覧ください。
ロールアウトの順序付けとノードのアップグレード方式が連動する仕組み
ノードのアップグレードでは、ロールアウト順序に従ってアップグレードされる際、構成されているノード アップグレード方式が使用されます。ロールアウトの順序付けがないクラスタのアップグレードと同様、GKE は Autopilot ノードにサージ アップグレードを使用します。詳細については、ノードの自動アップグレードをご覧ください。
ノードのアップグレードが 30 日以内に完了しない場合、すべてのクラスタのアップグレードが完了したかどうかにかかわらず、そのグループはソークフェーズに入ります。これは、ノード アップグレード戦略によって Standard クラスタのノード アップグレードの完了に時間がかかる場合（特に大規模なノードプールの場合）に発生することがあります。また、メンテナンスの時間枠の長さがノードのアップグレードを完了させるのに十分でない場合は、状況が悪化する可能性もあります。詳細については、メンテナンスの時間枠を構成する際の考慮事項をご覧ください。
ロールアウトの順序付けとリリース チャンネルが連動する仕組み
ロールアウトの順序付けを使用するには、リリース チャンネルが必要です。ロールアウト順序に含まれるグループのどのクラスタも、同じリリース チャンネルに存在する必要があります。
1 つのロールアウト順序全体で複数のアップグレードを受け取る
以前のアップグレード ターゲットへのクラスタのアップグレードがまだロールアウト順序の中で進行している間に、新しいバージョンがリリース チャンネル上のアップグレード ターゲットになった場合、下流のグループでは以前のアップグレードを引き続き受け取りながら、上流のグループでは新しいバージョンのロールアウトを開始できます。たとえば、ロールアウト順序内の 3 番目のグループが 1.24.2-gke.100 をロールアウトしている場合、最初のグループは並行して 1.24.3-gke.500 をロールアウトできます。
ロールアウトの順序付けを選択する際の考慮事項
新しいバージョンを別の環境にロールアウトする前に、1 つの環境で新しいバージョンの適格性を評価してクラスタのアップグレードを管理する場合は、ロールアウトの順序付けの使用を検討してください。
ただし、次のいずれかに当てはまる場合は、環境にとって適切な選択肢にならないことがあります。
- 同じ本番環境に、同じリリース チャンネル上になくマイナー バージョンでもないクラスタがある。
- ロールアウト順序は最大 3 つのクラスタ グループしか作成できないため、デプロイの 3 つのステージだけではマッピングできないアップグレードを自動化する必要がある。複数のロールアウト順序の中にあるグループをつなげて、4 つ以上のグループを含むロールアウト順序を作成することはできません。
- フリート管理を使用できない。
- 1 つのグループ内のクラスタに異なる自動アップグレードのターゲット バージョンが作成される原因になるような、手動アップグレードを頻繁に行う。
チームベースのロールアウト順序を作成するには、フリート ホスト プロジェクトで GKE Enterprise を有効にすることも必要です。
制限事項
ロールアウトの順序付けを使用してクラスタを正常にアップグレードするには、以下の制限事項に従う必要があります。
- チームベースのロールアウトの順序付けを使用している場合は、1 つのチームスコープにのみクラスタを登録します。クラスタが複数のチームスコープに登録されている場合、GKE はチームベースのロールアウト順序でクラスタを自動でアップグレードできません。
- 同じフリート内の複数のチームスコープを持つチームベースのロールアウト順序の作成はサポートされていません。
- ロールアウト順序は、ループ（下流のグループが上流のグループでもある）や分岐（1 つのグループに下流のグループが複数ある）を作らず、直線的に作成します。
- チームのスコープ間のロールアウト順序、またはフリート間のロールアウト順序を作成します。同じシーケンスにフリートとチームスコープの両方が混在する順序は作成できません。
- ロールアウト順序内のクラスタは、すべて同じリリース チャンネルに登録され、同じマイナー バージョンが実行されるようにします。
既知の問題
- グループに異なるロケーションのクラスタが含まれている場合、新しいバージョンは段階的にロールアウトされるため、一部のクラスタで一時的にクラスタのアップグレードが使用可能になることがあります。これはクラスタの最初のグループで発生する可能性が高く、1 週間以内に解決します。
- ロールアウト順序に空のグループがある場合、それがバージョンの適格性評価に与える影響は、次の条件によって変わります。
- 空のグループに上流のグループがない場合、空のグループではバージョンの適格性を評価できないため、クラスタのアップグレードは下流のグループに進みます。
- 空のグループに上流のグループがある場合、保留中のすべてのクラスタ アップグレードは
COMPLETEステータスになり、下流のグループに反映されます。
- GKE がパッチとマイナー アップグレードを追跡する方法によって、スコープのステータスを確認するときに、タイプとバージョンが同じであるものの、ステータスが異なる 2 つのアップグレードが表示される場合があります。