ロールアウト シーケンスを使用すると、複数の環境で Google Kubernetes Engine（GKE）クラスタ全体にわたるクラスタの自動アップグレードの順序を管理できます。たとえば、本番環境クラスタをアップグレードする前に、本番前環境クラスタで新しいバージョンの適格性を確認できます。GKE には、カスタム ステージを使用するロールアウトの順序付け（プレビュー）のバージョンも用意されています。これにより、クラスタのアップグレードをよりきめ細かく制御できます。
このドキュメントでは、次の内容を理解していることを前提としています。
ロールアウト シーケンスを構成するには、クラスタのアップグレードのロールアウトを順序付けるをご覧ください。概要
GKE ロールアウト シーケンスを使用すると、環境全体にわたるクラスタ アップグレードの特定の順序を定義できます。たとえば、まず開発環境のクラスタをアップグレードし、次にテスト環境、最後に本番環境のクラスタをアップグレードします。この段階的な戦略にはベイク時間が組み込まれているため、アップグレードが最も重要なシステムに到達する前に、潜在的な問題を発見して軽減できます。
ロールアウト シーケンスは、フリートのコンセプトに基づいて構築されています。フリートは、環境（テストなど）にマッピングされる GKE クラスタの論理グループです。この機能を使用するには、フリートで構成されるシーケンスを定義し、各グループ間のソーク時間を設定します。GKE が新しいバージョンを選択すると、定義された順序でクラスタがアップグレードされ、バージョンが本番環境に完全にデプロイされる前にワークロードを検証できます。
フリートは軽量なメンバーシップをサポートしています。これにより、フリートレベルの構成と機能をすべて有効にせずに、ロールアウト シーケンス用にクラスタを論理的にグループ化できます。軽量メンバーシップは、フリートレベルの Namespace の同一性など、フリートの完全な管理の他の影響を受けずにロールアウト シーケンスを使用する場合に適しています。詳細については、軽量メンバーシップをご覧ください。
ロールアウトの順序付け戦略を選択する
GKE には、ロールアウト シーケンスの 2 つのバージョンがあります。どちらのバージョンも、プログレッシブなフリートベースのアップグレードという同じコア原則に基づいて構築されていますが、柔軟性のレベルが異なります。このセクションでは、ユースケースに最適なバージョンを判断するうえで役立つ情報を提供します。
フリートベースのロールアウト順序（一般提供）: このバージョンは、ほとんどの本番環境ユースケースに推奨される戦略です。フリートベースのロールアウト シーケンスは、環境（テスト、ステージング、本番環境など）全体でアップグレードを段階的にロールアウトするための安定したサポート対象の方法を提供し、フリートの線形シーケンスを使用します。
カスタム ステージを使用したロールアウトの順序付け（プレビュー）: このバージョンは、フリートベースのモデルを進化させたもので、より詳細な制御と柔軟性を提供します。カスタム ステージを使用すると、ラベルを使用してフリート内の特定のステージを定義できます。そのため、より広範なロールアウトの前に本番環境クラスタの小さなサブセットに新しいバージョンをデプロイするなど、より複雑なロールアウト戦略に適しています。柔軟性を高めたい場合や、最新のロールアウト シーケンス機能のプレビュー版を試したい場合は、このオプションを選択します。
フリートベースのロールアウト順序
ロールアウト シーケンスによってクラスタを自動でアップグレードするには、同じリリース チャンネルとマイナー バージョンを持つクラスタをデプロイのステージにグループ化したフリートを使用します。フリートのシーケンスと、クラスタの各グループ間に必要なソーク時間を定義します。次に、GKE がリリース チャンネルで自動アップグレード用の新しいバージョンを選択すると、定義した順序でクラスタのグループがアップグレードされ、本番環境クラスタでアップグレードを開始する前に、ワークロードが新しいバージョンで期待どおりに実行されることを検証できます。
次の図は、GKE がクラスタを、フリートで編成されたロールアウト順序で自動でアップグレードする仕組みを示しています。
フリートベースの順序では、すべてのクラスタがこの順序で登録されているリリース チャンネルで、新しいアップグレード ターゲットを GKE が利用できるようにすると、GKE はこの順序でクラスタのフリートをアップグレードします。このとき、アップストリームのフリート内のクラスタは、最大 5 つのダウンストリームのフリートに対し、その中のクラスタに新しいバージョンを適用します。ロールアウト シーケンスにおいて、アップストリームは前のグループを指し、ダウンストリームは次のグループを指します。
フリート間で構成されたソーク時間中に、アップグレードされたクラスタでワークロードが期待どおりに実行されていることを確認できます。
カスタム ステージを使用したロールアウト シーケンス
カスタム ステージでロールアウト シーケンスを使用する場合は、フリート アップグレードの順序を定義し、ソーク時間を設定します。また、次の操作も行うことができます。
- ラベルを使用してフリート内のクラスタの特定のサブセットをターゲットにできる、粒度の細かいステージを含むシーケンスを定義します。これは、段階的ロールアウトなどの戦略に適しています。
- 新しい
RolloutSequenceAPI オブジェクトとRolloutAPI オブジェクトを使用して、制御とオブザーバビリティを強化します。
この方法では、クラスタのアップグレードを最も柔軟かつ詳細に制御できます。フリート内のクラスタの特定のサブセットをターゲットにするには、label-selector を使用して、特定の Kubernetes ラベルを持つクラスタのみをターゲットにします。
次の図は、GKE がカスタム ステージを使用するロールアウト順序でクラスタを自動的にアップグレードする仕組みを示しています。ステージは、prod フリートの canary という名前の label-selector を持つクラスタをターゲットにします。
このシーケンスのすべてのクラスタが登録されているリリース チャンネルで新しいアップグレード ターゲットが利用可能になると、GKE は最初にテストフリートのクラスタをアップグレードし、次にステージング フリートのクラスタをアップグレードします。次に、本番環境フリートで、GKE は label-selector に一致するクラスタを優先します。prod-cluster-1 に canary: true のラベルが付けられているため、GKE はこのクラスタを次にアップグレードします。このステージにはラベル セレクタがないため、GKE はプロセスの最後に、本番環境フリート（メインステージ）の残りのすべてのクラスタをアップグレードします。
ステージ間で構成されたソーク時間中に、アップグレードされたクラスタでワークロードが期待どおりに実行されていることを確認できます。上記の例では、本番環境フリートに 1 つのカスタム ステージを示していますが、任意のフリートに複数のステージを追加することも、複数のステージを含む 1 つのフリートのみを使用することもできます。
カスタム ステージを使用したロールアウト シーケンスの詳細については、カスタム ステージを使用したロールアウト シーケンスについてをご覧ください。このドキュメントの残りの部分は、フリートベースのロールアウト シーケンスにのみ関連します。
GKE がロールアウト順序でクラスタをアップグレードする仕組み
GKE がクラスタをアップグレードする場合は、まずコントロール プレーンがアップグレードされ、次にノードがアップグレードされます。ロールアウト順序では、クラスタはこのプロセスでアップグレードされますが、クラスタのグループ（フリート）がアップグレードされる順序も制御できます。また、あるグループから次のグループへアップグレードを進める前に GKE が一時停止する時間を定義するソーク時間も指定します。
ロールアウト順序でのクラスタのアップグレードは、次の手順で行います。
- GKE は、特定のリリース チャンネルのマイナー バージョンのクラスタに新しい自動アップグレードのターゲットを設定します。リリースノートには、「このリリースでは、Regular チャンネルで自動アップグレードが有効になっているコントロール プレーンとノードがバージョン 1.29 からバージョン 1.30.14-gke.1150000 にアップグレードされます」のようなメッセージが表示されます。
GKE が、クラスタの最初のグループで、クラスタ コントロール プレーンの新しいバージョンへのアップグレードを開始します。GKE は、クラスタのコントロール プレーンがアップグレードした後、クラスタのノードのアップグレードを開始します。ロールアウト順序に従ってクラスタをアップグレードする場合、GKE はメンテナンスの時間枠や除外を尊重します。
GKE は、コントロール プレーンのアップグレードで次の手順を行います。
- 最初のグループのクラスタ コントロール プレーンのアップグレードがすべて終了すると、GKE によってコントロール プレーンのアップグレードのソーク期間が開始されます。コントロール プレーンのアップグレードの開始から 30 日以上経過した場合も、GKE はソーク期間を開始します。
最初のグループのクラスタ コントロール プレーンのアップグレードのソーク期間が完了すると、GKE は 2 番目のグループのコントロール プレーンを新しいバージョンにアップグレードします。ただし、次の点にご注意ください。
- 場合によっては、GKE は 2 番目のグループのクラスタ コントロール プレーンをアップグレードする前に、最初のグループのクラスタ コントロール プレーンを複数回アップグレードすることがあります。このような状況が発生した場合、GKE は次の属性も持つ最新バージョンを選択します。
- バージョンは最初のグループによって認定されます。
- このバージョンは、2 番目のグループのクラスタのコントロール プレーン バージョンより 1 つ後のマイナー バージョンまでです。
- GKE は、最初のグループで認定された自動アップグレードのターゲットよりも新しいバージョンを持つ 2 番目のグループのクラスタのコントロール プレーンをアップグレードしません。
- 場合によっては、GKE は 2 番目のグループのクラスタ コントロール プレーンをアップグレードする前に、最初のグループのクラスタ コントロール プレーンを複数回アップグレードすることがあります。このような状況が発生した場合、GKE は次の属性も持つ最新バージョンを選択します。
コントロール プレーンのアップグレードと並行して、GKE はノードのアップグレード用に次の手順を行います。
- 最初のグループのすべてのクラスタのノード アップグレードが完了すると、GKE によってノード アップグレードのソーク期間が開始されます。ノード アップグレードの開始から 30 日以上経過した場合も、GKE はソーク期間を開始します。
- 最初のグループのノード アップグレードのソーク期間が完了すると、GKE は 2 番目のグループのノードを新しいバージョンにアップグレードします。ただし、次の点に注意してください。
- 場合によっては、GKE は 2 番目のグループのクラスタノードをアップグレードする前に、最初のグループのクラスタノードを複数回アップグレードすることがあります。このような状況が発生した場合、GKE は次の属性も持つ最新バージョンを選択します。
- バージョンは最初のグループによって認定されます。
- バージョンは、2 番目のグループのクラスタ コントロール プレーン バージョンよりも新しいバージョンではありません。
- GKE は、最初のグループで認定された自動アップグレード ターゲットよりも新しいバージョンを持つ、2 番目のグループのクラスタのノードをアップグレードしません。
- 場合によっては、GKE は 2 番目のグループのクラスタノードをアップグレードする前に、最初のグループのクラスタノードを複数回アップグレードすることがあります。このような状況が発生した場合、GKE は次の属性も持つ最新バージョンを選択します。
ロールアウト順序内のすべてのグループのクラスタが新しいアップグレード対象にアップグレードされるまで、GKE は 2 番目のグループから 3 番目のグループにこの手順を繰り返します。
それぞれのグループでクラスタがアップグレードされたら、ソーク期間中に、新しい GKE バージョンを実行しているクラスタでワークロードが期待どおりに動作することを確認します。
また、メンテナンスの時間枠や除外、非推奨の API の使用などの理由で、クラスタをアップグレードできないこともあります。
ロールアウト順序でのアップグレードを制御する方法
クラスタのロールアウト順序でのアップグレードでは、クラスタのグループを定義された順序でアップグレードし、各グループで決められた時間ソークします。アップグレードの進行中に、必要に応じてステータスを確認したり、ロールアウト順序を管理したりできます。次の方法でプロセスを制御することもできます。
- ロールアウト順序に入るグループについて、特定のバージョンのソークを増減する必要がある場合は、デフォルトのソーク時間をオーバーライドできます。
- 個々のクラスタのアップグレードでは、引き続き次のツールを使用できます。
- ノードプールのアップグレードのキャンセル、再開、ロールバック、完了などの操作を行うアップグレードの手動制御。
- メンテナンスの時間枠と除外を使用して、クラスタのアップグレードを許可するタイミングとできないタイミングを決定します。
- ノードのアップグレード戦略を構成し、ノードで実行されるワークロードに応じてスピードとリスク許容度のバランスを取る。
例: コミュニティ バンクで変更をテスト環境から本番環境まで段階的にロールアウトする
たとえば、あるコミュニティ バンクのプラットフォーム管理者が、テスト、ステージング、本番という 3 つの主要なデプロイ環境を管理しているとします。各環境には、フリートに編成されたクラスタのグループがあります。ロールアウトの順序付けに必要とされるとおり、管理者は、3 つのフリートすべてにわたって各クラスタを同じリリース チャンネル（これらのフリートでは Regular チャンネル）に登録し、すべてのクラスタで同じマイナー バージョンを実行しています。
管理者は、ロールアウトの順序付けを使用して、GKE がこれらの環境のクラスタをアップグレードする順序を定義します。ロールアウトの順序を決めることで、管理者は、本番環境を新しいバージョンへアップグレードする前に、新しいバージョンの GKE のクラスタで、ワークロードが想定どおりに実行されることを確認できます。この順序は、フリートベースのロールアウト順序の図に示しています。
管理者は、フリート間のソーク時間を使用して、新しいバージョンの GKE でワークロードが期待どおりに実行されることを確認します。テストフリートでは、管理者が、ワークロードの動作を確認するテストに丸 2 週間を確保できるように、ソーク時間を 14 日に設定します。ステージングでは、ワークロードがすでにテストで実行された後で、それほど追加の時間を必要としないため、ソーク時間を 7 日に設定します。
管理者は、特定のバージョンへのアップグレードに対するデフォルトのソーク時間をオーバーライドすることもできます。これは、次のような状況で行えます。
- ソーク時間が終わる前に、管理者がバージョンの適格性評価を終了し、アップグレードを次のフリートに進める場合にソーク時間をゼロに設定する。
- 管理者が、一部のワークロードに問題があることに気づいたため、アップグレードを次のフリートに進める前に新しいバージョンの適格性を評価する時間が必要な場合に、ソーク時間を最大の 30 日に設定する。
管理者はメンテナンスの時間枠と除外を使用して、銀行への影響が最も少ないときに GKE がクラスタをアップグレードできるようにします。GKE では、ロールアウト順序でアップグレードされるクラスタのメンテナンスの時間枠や除外が尊重されます。
- 管理者は、GKE が営業時間後にのみクラスタをアップグレードするように、クラスタのメンテナンスの時間枠を構成しています。
- また、管理者はメンテナンスの除外を使用して、クラスタのワークロードに関する問題を検出した場合に、クラスタのアップグレードを一時的に停止します。
管理者は、ノード上で実行されるワークロードに応じてスピードとリスクの許容範囲のバランスをとりながら、ノードに対してサージ アップグレードと Blue / Green アップグレードを組み合わせて使用します。
フリートベースのロールアウトの適格性
ロールアウトの順序付けを使用してクラスタを自動でアップグレードするには、ロールアウト順序内のすべてのフリートのすべてのクラスタが同じアップグレード ターゲットを受け取る必要があります。クラスタは同じリリース チャンネルに登録する必要があり、アップグレード ターゲットはマイナー バージョンごとに設定されるため、クラスタでは同じマイナー バージョンを実行することをおすすめします。ただし、次の例のリリースのように、複数のマイナー バージョンのクラスタが同じターゲットを受け取る場合もあります。これは、複数のマイナー バージョンを実行しているロールアウト順序で、クラスタが正常にアップグレードできることを意味します。
バージョンを順にロールアウトする中でのステータスを確認して、ステータスの詳細や、バージョンの適格性の問題によってアップグレードの続行が妨げられているかどうかの詳細を得ることができます。バージョンの不一致によっては、クラスタを手動アップグレードする、クラスタをグループから削除してアップグレードを続行するなどの操作が必要になる場合があります。ロールアウト シーケンス内のクラスタに適格なアップグレード ターゲットがない場合は、クラスタの既存のマイナー バージョンがサポート終了になるまで、GKE はクラスタを自動アップグレードしません。
ロールアウトの適格性に関するトラブルシューティングについては、ロールアウトの適格性に関するトラブルシューティングをご覧ください。
GKE リリースの例
たとえば、2025-R45 リリースでは、Regular チャンネルに登録されているクラスタに複数のマイナー バージョンに対して 1 つのアップグレード ターゲットを設定します。アップグレード ターゲットは、新しいマイナー バージョン（1.30 ～ 1.31）か、新しいパッチ バージョン（1.31.x-gke.x ～ 1.31.13-gke.1023000）のいずれかです。このリリースの Regular チャンネルでは、特定のマイナー バージョンのクラスタで次の新しいバージョンが利用可能になりました。
- 1.30 のクラスタは 1.31.13-gke.1023000 にアップグレードされました。
- 1.31 のクラスタは 1.32.9-gke.1108000 にアップグレードされました。
- 1.32 のクラスタは 1.33.5-gke.1162000 にアップグレードされました。
最上流のグループですべてのアップグレード ターゲットを受け取る
順序の最初のグループ（新しいバージョンの適格性を評価する上流のグループがない）にあるクラスタの場合、GKE は、アップグレード ターゲットがそれぞれ異なるかどうかにかかわらず、適格性のあるアップグレード ターゲットを持つクラスタをアップグレードします。たとえば、順序の最初のグループで一部のクラスタが 1.30 で実行されている場合、そうしたクラスタは 1.31.13-gke.1023000 にアップグレードされ、1.32 が実行されているクラスタは 1.33.5-gke.1162000 にアップグレードされます。順序の最初のグループでは、新しいバージョンの適格性を評価する上流のグループがないため、GKE が、すべてのアップグレード ターゲットをこうしたクラスタに対して適格性があるとみなすためです。
上流のグループは 1 つのバージョンのみ適格性を評価する必要がある
ダウンストリーム グループ内のクラスタがアップグレードを開始するには、アップストリーム グループが、ダウンストリーム グループ内のすべてのクラスタが対象となる単一の共通アップグレード ターゲットを適格性があると評価している必要があります。アップストリーム グループに、2 つの異なるバージョンに正常にアップグレードされたクラスタがある場合（アップストリーム グループがシーケンスの最初のグループの場合など）、アップストリーム グループは 2 つのバージョンのうちの低い方をダウンストリーム グループの共通アップグレード ターゲットとして認定します。たとえば、アップストリーム グループに 1.31.13-gke.1023000 にアップグレードされたクラスタと 1.33.5-gke.1162000 にアップグレードされたクラスタがある場合、グループは 1.31.13-gke.1023000 をダウンストリーム グループの共通アップグレード ターゲットとして認定します。
アップグレードのターゲットより新しいバージョンを実行しているクラスタは、アップグレードを妨げません
ダウンストリーム グループに、アップストリーム グループによって認定されたアップグレード ターゲットよりも新しいバージョンを実行しているクラスタがある場合、GKE はアップグレード ターゲットの対象となるクラスタをアップグレードし、すでに新しいバージョンにあるクラスタは無視します。ダウンストリーム グループ内の少なくとも 1 つのクラスタがアップグレード ターゲットの対象である限り、ロールアウト シーケンスの進行は妨げられません。
たとえば、アップストリーム グループが 1.32 へのアップグレードの対象となり、ダウンストリーム グループに 1.31 と 1.33 を実行しているクラスタがある場合、GKE は 1.31 を実行しているクラスタを 1.32 にアップグレードし、1.33 を実行しているクラスタを無視します。
上流のグループは次のグループのクラスタと一致するバージョンの適格性を評価する必要がある
上流グループのクラスタが、次のグループ内のクラスタに適格なバージョンとは異なるバージョンを適格とした場合、GKE は下流グループのクラスタも自動でアップグレードできません。
たとえば、最初のグループのすべてのクラスタが 1.31.13-gke.1023000 にアップグレードされているにもかかわらず、2 番目のグループのクラスタが 1.32.9-gke.1108000 などの新しいバージョンを実行している場合、2 番目のグループのクラスタは自動でアップグレードされません。最初のグループは 1.31.13-gke.1023000 を適格としましたが、2 番目のグループのクラスタ（現在は 1.32）はアップグレード ターゲットが 1.33.5-gke.1162000 のみであるため、GKE はこれらのクラスタを自動でアップグレードできません。この状況でアップグレードを進めるには、グループ間の適格性を修正するをご覧ください。
アップストリーム グループがダウンストリーム グループの複数のアップグレード ターゲットを認定した
GKE がダウンストリーム グループのクラスタをアップグレードする前にアップストリーム グループのクラスタを複数回アップグレードした場合、GKE はダウンストリーム グループのクラスタを、アップストリーム グループによって認定された最新バージョン（ダウンストリーム グループのクラスタが対象とする）にアップグレードします。コントロール プレーンのアップグレードの場合、このバージョンは、ダウンストリーム グループのクラスタのコントロール プレーン バージョンより 1 つ後のマイナー バージョンまでです。ノードのアップグレードの場合、このバージョンはダウンストリーム グループのクラスタのコントロール プレーン バージョンと同じにできますが、それより新しいバージョンにはできません。
たとえば、本番環境クラスタを含むダウンストリーム グループのアップグレードを一時的に防止するようにメンテナンスの除外を構成している場合、このシナリオが該当します。ただし、本番環境前クラスタを含むアップストリーム グループでは、アップグレードを防ぐためにメンテナンスの除外も使用されていませんでした。そのため、アップストリーム グループは複数回アップグレードされ、複数のアップグレード ターゲットの候補が認定されましたが、ダウンストリーム グループはアップグレードされませんでした。
30 日以内に完了しなかったアップグレードは、シーケンスのブロックを解除するために強制的にソークされます。
ロールアウト シーケンスでクラスタのアップグレードが確実に完了するように、コントロール プレーンまたはノードのアップグレードが最大アップグレード時間（30 日）内にすべてのクラスタで完了しない場合、GKE はグループのソーク期間を開始します。グループ内の残りのクラスタのアップグレードは、ソーク期間中も続行できます。詳細については、ロールアウト シーケンスのステータス情報テーブルの FORCED_SOAKING の行をご覧ください。
フリートベースのロールアウトの順序付けと他のアップグレード機能が連動する仕組み
ロールアウトの順序付けは、クラスタのライフサイクルのアップグレードの側面を制御できる一連の機能の一つです。このセクションでは、この機能がクラスタのアップグレードに関連する他の利用可能な機能と連動する仕組みについて説明します。
フリートベースのロールアウトの順序付けがメンテナンスの時間枠や除外と連動する仕組み
GKE では、ロールアウトの順序付けを使用してクラスタをアップグレードする場合、メンテナンスの時間枠とメンテナンスの除外が尊重されます。GKE は、クラスタのメンテナンスの時間枠内でのみクラスタのアップグレードを開始します。メンテナンスの除外は、クラスタのアップグレードを一時停止するために使用できます。メンテナンスの時間枠やメンテナンスの除外により GKE がクラスタをアップグレードできない場合は、グループ内のクラスタのアップグレードが終了しなくなることがあります。メンテナンスの時間枠やメンテナンスの除外により、30 日以内にクラスタのアップグレードを完了できない場合、すべてのクラスタのアップグレードが完了したかどうかにかかわらず、そのグループはソークフェーズに入ります。
メンテナンスの除外を一時的な手段として使用することで、グループへのロールアウトが完了して次のグループへ移行することを防ぐことができます。詳細については、グループのバージョンのロールアウトの完了を遅らせるをご覧ください。
フリートベースのロールアウトの順序付けと非推奨の使用状況の検出が連動する仕組み
GKE は、特定の非推奨の API や機能の使用を検出すると、クラスタのアップグレードを一時停止します。ロールアウト順序の中のグループ内にあるクラスタの自動アップグレードも一時停止されます。詳細については、GKE で Kubernetes の非推奨が機能する仕組みをご覧ください。
ロールアウトの順序付けとノードのアップグレード方式が連動する仕組み
ノードのアップグレードでは、ロールアウト順序に従ってアップグレードされる際、構成されているノード アップグレード方式が使用されます。ロールアウトの順序付けがないクラスタのアップグレードと同様、GKE は Autopilot ノードにサージ アップグレードを使用します。詳細については、ノードの自動アップグレードをご覧ください。
ノードのアップグレードが 30 日以内に完了しない場合、すべてのクラスタのアップグレードが完了したかどうかにかかわらず、そのグループはソークフェーズに入ります。この動作は、ノード アップグレード戦略によって Standard クラスタのノード アップグレードの完了に時間がかかる場合（特に大規模なノードプールの場合）に発生することがあります。また、メンテナンスの時間枠の長さがノードのアップグレードを完了させるのに十分でない場合は、状況が悪化する可能性もあります。
ロールアウトの順序付けとリリース チャンネルが連動する仕組み
ロールアウトの順序付けを使用するには、リリース チャンネルが必要です。ロールアウト順序に含まれるグループのどのクラスタも、同じリリース チャンネルに存在する必要があります。
1 つのロールアウト順序全体で複数のアップグレードを受け取る
以前のアップグレード ターゲットへのクラスタのアップグレードがまだロールアウト順序の中で進行している間に、新しいバージョンがリリース チャンネル上のアップグレード ターゲットになった場合、下流のグループでは以前のアップグレードを引き続き受け取りながら、上流のグループでは新しいバージョンのロールアウトを開始できます。たとえば、ロールアウト順序内の 3 番目のグループが 1.31.12-gke.1265000 をロールアウトしている場合、最初のグループは並行して 1.31.13-gke.1008000 をロールアウトできます。
フリートベースのロールアウトの順序付けを選択する際の考慮事項
新しいバージョンを別の環境にロールアウトする前に、1 つの環境で新しいバージョンの適格性を評価してクラスタのアップグレードを管理する場合は、ロールアウトの順序付けの使用を検討してください。
ただし、次のいずれかに当てはまる場合は、環境にとって適切な選択肢にならないことがあります。
- 同じ本番環境内にリリース チャンネルやマイナー バージョンが異なるクラスタがある。
- ロールアウト順序は最大 5 つのクラスタ グループしか作成できないため、デプロイの 5 つのステージだけではマッピングできないアップグレードを自動化する必要がある。複数のロールアウト順序内のグループをリンクして、6 つ以上のグループを含むロールアウト順序を作成することはできません。フリートベースのシーケンスには、最大 5 つのフリートを含めることができます。
- 1 つのグループ内のクラスタに異なる自動アップグレードのターゲット バージョンが作成される原因になるような手動アップグレードを頻繁に行う。
フリートベースのロールアウト順序の制限事項
ロールアウトの順序付けを使用してクラスタを正常にアップグレードするには、以下の制限事項に従う必要があります。
- ロールアウト シーケンス内のすべてのクラスタが同じリリース チャンネルに登録されていることを確認します。また、1 つのアップグレード ターゲットを認定するには、すべてのクラスタで同じマイナー バージョンを実行することをおすすめします。詳しくは、ロールアウトの適格性をご覧ください。
- ロールアウト順序は、ループ（下流のグループが上流のグループでもある）や分岐（1 つのグループに下流のグループが複数ある）を作らず、直線的に作成します。
- 同じ組織内にクラスタ間のロールアウト順序を作成します。複数の組織にまたがるクラスタを含む順序を作成することはできません。
フリートベースのロールアウト シーケンスに関する既知の問題
- グループに異なるロケーションのクラスタが含まれている場合、新しいバージョンは段階的にロールアウトされるため、一部のクラスタで一時的にクラスタのアップグレードが使用可能になることがあります。この動作はクラスタの最初のグループで発生する可能性が高く、1 週間以内に解決します。
- ロールアウト順序に空のグループがある場合、それがバージョンの適格性評価に与える影響は、次の条件によって変わります。
- 空のグループに上流のグループがない場合、空のグループではバージョンの適格性を評価できないため、クラスタのアップグレードは下流のグループに進みます。
- 空のグループに上流のグループがある場合、保留中のすべてのクラスタ アップグレードは
COMPLETEステータスになり、下流のグループに反映されます。