ロールアウト シーケンスを使用すると、複数の環境で Google Kubernetes Engine（GKE）クラスタ全体にわたるクラスタの自動アップグレードの順序を管理できます。たとえば、本番環境クラスタをアップグレードする前に、本番前環境クラスタで新しいバージョンの適格性を確認できます。GKE は、カスタム ステージのないより線形なモデルを使用するロールアウトの順序付けの一般提供バージョンも提供しています。
このドキュメントでは、次の内容を理解していることを前提としています。
ロールアウト シーケンスを構成するには、クラスタのアップグレードのロールアウトを順序付けるをご覧ください。概要
GKE ロールアウト シーケンスを使用すると、環境全体にわたるクラスタ アップグレードの特定の順序を定義できます。たとえば、まず開発環境のクラスタをアップグレードし、次にテスト環境、最後に本番環境のクラスタをアップグレードします。この段階的な戦略にはベイク時間が組み込まれているため、アップグレードが最も重要なシステムに到達する前に、潜在的な問題を発見して軽減できます。
ロールアウト シーケンスは、フリートのコンセプトに基づいて構築されています。フリートは、環境（テストなど）にマッピングされる GKE クラスタの論理グループです。この機能を使用するには、フリートで構成されるシーケンスを定義し、各グループ間のソーク時間を設定します。GKE が新しいバージョンを選択すると、定義された順序でクラスタがアップグレードされ、バージョンが本番環境に完全にデプロイされる前にワークロードを検証できます。
フリートは軽量なメンバーシップをサポートしています。これにより、フリートレベルの構成と機能をすべて有効にせずに、ロールアウト シーケンス用にクラスタを論理的にグループ化できます。軽量メンバーシップは、フリートレベルの Namespace の同一性など、フリートの完全な管理の他の影響を受けずにロールアウト シーケンスを使用する場合に適しています。詳細については、軽量メンバーシップをご覧ください。
ロールアウトの順序付け戦略を選択する
GKE には、ロールアウト シーケンスの 2 つのバージョンがあります。どちらのバージョンも、プログレッシブなフリートベースのアップグレードという同じコア原則に基づいて構築されていますが、柔軟性のレベルが異なります。このセクションでは、ユースケースに最適なバージョンを判断するうえで役立つ情報を提供します。
フリートベースのロールアウト シーケンス（GA）: このバージョンは一般提供されており、ほとんどの本番環境ユースケースで推奨される戦略です。フリートベースのロールアウト シーケンスは、環境（テスト、ステージング、本番環境など）全体でアップグレードを段階的にロールアウトするための安定したサポート対象の方法を提供し、フリートの線形シーケンスを使用します。
カスタム ステージを使用したロールアウトの順序付け（プレビュー）: このバージョンは、フリートベースのモデルの進化版であり、より詳細な制御と柔軟性を提供します。カスタム ステージを使用すると、ラベルを使用してフリート内の特定のステージを定義できます。これは、より広範なロールアウトの前に、本番環境クラスタの小さなサブセットに新しいバージョンをデプロイするなど、より複雑なロールアウト戦略に適しています。柔軟性を高めたい場合や、最新のロールアウト シーケンス機能のプレビュー版を試したい場合は、このオプションを選択します。
このドキュメントの残りの部分は、カスタム ステージでのロールアウト シーケンスにのみ関連します。
カスタム ステージを使用したロールアウト シーケンス
カスタム ステージでロールアウト シーケンスを使用する場合は、フリート アップグレードの順序を定義し、ソーク時間を設定します。また、次の操作も行うことができます。
- ラベルを使用してフリート内のクラスタの特定のサブセットをターゲットにできる、粒度の細かいステージを含むシーケンスを定義します。これは、段階的ロールアウトなどの戦略に適しています。
- 新しい
RolloutSequenceAPI オブジェクトとRolloutAPI オブジェクトを使用して、制御とオブザーバビリティを強化します。
この方法では、クラスタのアップグレードを最も柔軟かつ詳細に制御できます。フリート内のクラスタの特定のサブセットをターゲットにするには、label-selector を使用して、特定の Kubernetes ラベルを持つクラスタのみをターゲットにします。
次の図は、GKE がカスタム ステージを使用するロールアウト順序でクラスタを自動的にアップグレードする仕組みを示しています。ステージは、prod フリートの canary という名前の label-selector を持つクラスタをターゲットにします。
このシーケンスのすべてのクラスタが登録されているリリース チャンネルで新しいアップグレード ターゲットが利用可能になると、GKE は最初にテストフリートのクラスタをアップグレードし、次にステージング フリートのクラスタをアップグレードします。次に、本番環境フリートで、GKE は label-selector に一致するクラスタを優先します。prod-cluster-1 に canary: true のラベルが付けられているため、GKE はこのクラスタを次にアップグレードします。このステージにはラベル セレクタがないため、GKE はプロセスの最後に、本番環境フリート（メインステージ）の残りのすべてのクラスタをアップグレードします。
ステージ間で構成されたソーク時間中に、アップグレードされたクラスタでワークロードが期待どおりに実行されていることを確認できます。上記の例では、本番環境フリートに 1 つのカスタム ステージを示していますが、任意のフリートに複数のステージを追加することも、複数のステージを含む 1 つのフリートのみを使用することもできます。
主なコンセプト
- ソーク時間: この期間は、ステージ内のすべてのクラスタがアップグレードされた後に発生する構成可能な待機期間です。このベイク時間により、1 つの環境で新しいバージョンを検証し、アップグレードが次の環境に進む前に潜在的な問題を検出できます。シーケンスの各ステージで、最大 30 日間のソーク時間を構成できます。プレリリース ステージでのソーク時間を長くすると、検証に時間をかけられます。
RolloutSequence: アップグレード シーケンスの定義に使用するプライマリ リソースです。RolloutSequenceには順序付けられた一連のステージが含まれています。これにより、アップグレードが次のステージに進む前に、前のステージのクラスタが完全にアップグレードされ、ソーク期間が完了していることを確認します。Rollout: このオブジェクトを使用すると、シーケンスを介して単一バージョンのアップグレードの進行状況をモニタリングできます。Rolloutを使用すると、ロールアウトのステータスの表示、進行状況の追跡、アップグレードの対象外となるクラスタとその理由を確認できます。- 専用のホスト プロジェクト:
RolloutSequenceオブジェクトをホストするには、専用の Google Cloudプロジェクトを使用することをおすすめします。シーケンスを専用のプロジェクトに配置すると、ロールアウト シーケンスの中立的な中央制御ポイントが提供されます。これは、CI/CD パイプラインの管理に関するベスト プラクティスと同様です。
専用のホスト プロジェクトで RolloutSequence リソースを作成して管理します。
- ステージ: ステージはロールアウト シーケンスのステップです。各ステージには、一緒にアップグレードされるクラスタのグループが含まれています。
- フリート: フリートはクラスタをグループ化する主な方法です。ロールアウト シーケンスのステージは、1 つのフリートのみを参照できます。
- ラベル セレクタ: ロールアウト シーケンスは 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 バージョンが銀行の重要な本番環境に到達する前に、徹底的に精査されるようにすることです。また、トラフィックの少ないリージョンから順にクラスタをアップグレードし、トラフィックの多いリージョンに移動してから、最も重要なリージョンに移動することもできます。このため、カスタム ステージでロールアウトの順序付けを使用して、リージョンに従って本番環境クラスタにラベルを付ける段階的なアップグレード戦略を定義します。このアプローチにより、新しいバージョンを全面的にロールアウトする前に、本番環境トラフィックの小さなサブセットで検証できます。
このプランを実装するために、管理者は本番環境フリートのクラスタに次のラベルを適用します。
us-west1（トラフィックが少ない）のクラスタにはprod-region: us-west1のラベルが付けられます。europe-west1（トラフィックが多い）のクラスタにはprod-region: europe-west1のラベルが付けられます。us-east1（最も重要なトラフィック）のクラスタにはラベルが付けられていません。シーケンス内のフリートの最終ステージは、残りのすべてのクラスタの「キャッチオール」として機能する必要があります。したがって、管理者は残りのクラスタにラベルを追加する必要はありません。
次に、CI/CD 構成の管理に使用される専用のホスト プロジェクトで、RolloutSequence オブジェクトを定義します。この新しいシーケンスには、次の 5 つの異なるステージがあります。
- テスト: このステージには、
testingフリート内のすべてのクラスタが含まれます。管理者は、徹底的な検証を行うために、3 日間のソーク時間を設定します。 - ステージング: このステージには、
stagingフリート内のすべてのクラスタが含まれ、3 日間のソーク時間があります。 - リージョン
us-west1の本番環境: このステージは本番環境フリートをターゲットにしていますが、label-selectorを使用してprod-region: us-west1ラベルが付いたクラスタのみを含めます。このステージでは、管理者は 3 日間のソーク時間で、本番環境クラスタの小さなサブセットで問題をモニタリングできます。 - リージョン
europe-west1の本番環境: このステージには、prod-region: europe-west1ラベルが付いているproductionフリートのクラスタが含まれます。管理者は、より徹底的な検証を行うために、ソーク時間を 4 日に設定します。 - リージョン
us-east1の本番環境: この最終段階には、productionフリートの残りのクラスタ（つまり、us-east1のすべてのクラスタ）が含まれます。
このアプローチにより、管理者は本番環境のアップグレードをきめ細かく制御できます。潜在的な問題を本番環境全体に影響を与える前に検出することで、アップグレード プロセスの安全性と信頼性が大幅に向上します。
定期的なパッチ アップグレード中に、銀行の自動テストがステージング環境で予想よりもはるかに早く完了しました。管理者は、新しいバージョンが安定していることを確認し、このタイプの定期的な更新では、ステージング フリートのアップグレード後の 3 日間のソーク時間が長すぎると判断します。
このロールアウトを加速するため、管理者は RolloutSequence 定義を変更し、本番環境フリートの us-west1 ステージのソーク期間を短縮します。この RolloutSequence 定義の変更により、現在および将来のすべてのロールアウトのデフォルトのソーク時間が更新されるため、管理者は、この特定のパッチのロールアウトが完了したら、ソーク時間を元の 3 日間に戻すことをメモします。このアプローチにより、今後のマイナー バージョン アップグレードで、標準のより慎重なソーク時間が確保されます。
管理者は、銀行への影響が最も少ないときに GKE がクラスタをアップグレードするように、メンテナンスの時間枠と除外を使用します。GKE では、ロールアウト順序でアップグレードされるクラスタのメンテナンスの時間枠や除外が尊重されます。
- 管理者は、GKE が営業時間後にのみクラスタをアップグレードするように、クラスタのメンテナンスの時間枠を構成しています。
- また、管理者はメンテナンスの除外を使用して、クラスタのワークロードに関する問題を検出した場合に、クラスタのアップグレードを一時的に停止します。
管理者は、ノード上で実行されるワークロードに応じてスピードとリスクの許容範囲のバランスをとりながら、ノードに対してサージ アップグレードと Blue / Green アップグレードを組み合わせて使用します。
ロールアウトの適格性
カスタム ステージを使用してシーケンスでバージョンをロールアウトするには、クラスタがリリース チャンネルのアップグレード ターゲットの対象である必要があります。新しい GKE バージョンが利用可能になると、シーケンス内のクラスタが新しいバージョンの対象となる場合、システムは Rollout オブジェクトを作成します。すべてのクラスタを同じリリース チャンネルに登録することをおすすめしますが、登録されていない場合、GKE はシーケンス内の最も保守的なチャンネルからバージョンを選択します。たとえば、クラスタが Stable チャンネルと Regular チャンネルで混在している場合、GKE は Stable チャンネルのバージョンを選択します。
Rollout は、RolloutSequence で定義されたステージを進行します。特定のステージ内では、コントロール プレーンのロールアウトとノードプールのロールアウトを並行して実行できます。この進行を管理する重要なルールは、ステージが特定のバージョンの SOAKING 状態にある間は、新しいバージョンの新しい Rollout を開始できないことです。この方法により、次のアップグレードが開始される前にバージョンが完全に検証されます。Rollout オブジェクトをモニタリングすることで、各クラスタの進行状況と適格性を確認できます。クラスタが不適格になるバージョンの不一致が見つかった場合は、シーケンスを続行するために、クラスタの手動アップグレードなどの操作が必要になることがあります。クラスタがロールアウトの対象でない場合、GKE は現在のバージョンがサポート終了になるまで、クラスタを自動的にアップグレードしません。
アップグレードのターゲットより新しいバージョンを実行しているクラスタは、アップグレードを妨げません
シーケンスのステージに、ロールアウトのターゲット バージョンよりも新しいバージョンを実行しているクラスタが含まれている場合、GKE はターゲット バージョンの対象となるクラスタをアップグレードし、すでに新しいバージョンにあるクラスタは無視します。この動作は、ロールアウト シーケンスが次のステージに進むのを妨げません。
たとえば、ステージのロールアウトのターゲット バージョンが 1.32 で、そのステージに 1.31 と 1.33 の両方を実行しているクラスタがある場合、GKE はバージョン 1.31 のクラスタを 1.32 にアップグレードし、すでにバージョン 1.33 のクラスタは無視します。
前のステージが次のステージの複数のアップグレード ターゲットを認定した
シーケンスの前のステージで複数の新しいバージョンのロールアウトが完了しても、次のステージが一時停止（メンテナンス除外など）されているか、以前のアップグレードをまだ処理している可能性があります。この場合、後続のステージで新しいアップグレードを受け入れる準備が整うと、GKE はステージを認定された最新バージョンにアップグレードします。コントロール プレーンのアップグレードの場合、このバージョンは、後続ステージのクラスタのコントロール プレーン バージョンより 1 つ後のマイナー バージョンまでです。ノードのアップグレードの場合、このバージョンは後続ステージのクラスタのコントロール プレーン バージョンと同じにできますが、それより新しいバージョンにはできません。
たとえば、本番環境クラスタのアップグレードを一時的に防止するようにメンテナンスの除外を構成している場合、このシナリオが該当します。本番環境前クラスタに同じメンテナンスの除外が設定されていない場合、これらのクラスタは複数回アップグレードされ、複数の新しいバージョンが対象となりますが、本番環境ステージはアップグレードされません。
30 日後の強制ソーク処理
ロールアウト シーケンスでクラスタのアップグレードが確実に完了するように、コントロール プレーンまたはノードのアップグレードが最大アップグレード時間（30 日）内にすべてのクラスタで完了しない場合、GKE はグループのソーク期間を開始します。グループ内の残りのクラスタのアップグレードは、ソーク期間中も続行できます。
ロールアウトの順序付けと他のアップグレード機能が連動する仕組み
ロールアウトの順序付けは、他の GKE アップグレード機能と連携して動作します。
- メンテナンスの時間枠と除外: メンテナンスの時間枠と除外を使用して、クラスタでアップグレードを実行できるタイミングと実行できないタイミングを制御できます。GKE は、クラスタのメンテナンスの時間枠内でのみクラスタのアップグレードを開始します。メンテナンスの除外を使用すると、クラスタのアップグレードを一時的に停止できます。メンテナンスの時間枠やメンテナンスの除外により GKE がクラスタをアップグレードできない場合は、ステージ内のクラスタのアップグレードが終了しなくなることがあります。メンテナンスの時間枠やメンテナンスの除外により、30 日以内にクラスタのアップグレードを完了できない場合、すべてのクラスタのアップグレードが完了したかどうかにかかわらず、ステージはそのソークフェーズに入ります。コントロール プレーンとノードプールのロールアウトは、特定のステージ内で並行して実行できます。
ノードのアップグレード戦略: ロールアウトの順序付けは、構成されたノードのアップグレード戦略（Blue/Green アップグレードなど）に影響しません。ロールアウトの順序付けがないクラスタのアップグレードと同様に、GKE は Autopilot ノードにサージ アップグレードを使用します。詳細については、ノードの自動アップグレードをご覧ください。
ノードのアップグレードが 30 日以内に完了しない場合、すべてのクラスタのアップグレードが完了したかどうかにかかわらず、そのグループはソークフェーズに入ります。この動作は、ノード アップグレード戦略によって Standard クラスタのノード アップグレードの完了に時間がかかる場合（特に大規模なノードプールの場合）に発生することがあります。また、メンテナンスの時間枠の長さがノードのアップグレードを完了させるのに十分でない場合は、状況が悪化する可能性もあります。
リリース チャンネル: ロールアウト シーケンス内のすべてのクラスタを同じリリース チャンネルに登録することをおすすめします。
非推奨の使用状況の検出: GKE の非推奨の使用状況の検出は引き続き想定どおりに機能し、非推奨の API を使用するクラスタのアップグレードを一時停止する可能性があります。
手動アップグレード: シーケンスの最初のステージでクラスタを手動でアップグレードしても、そのバージョンが認定されたり、ロールアウトがトリガーされて続行されたりすることはありません。自動ロールアウト プロセスは、リリース チャンネルに設定された公式の自動アップグレードの対象によって駆動されます。手動アップグレードではクラスタが更新されますが、そのバージョンが自動アップグレードの対象として指定された後にのみ、シーケンスが開始されます。
1 つのロールアウト順序全体で複数のアップグレードを受け取る
リリース チャンネルは、クラスタのアップグレード ターゲットを選択します。以前のターゲットへのアップグレードがまだ進行中の間に新しいバージョンが利用可能になった場合、後のステージで以前のアップグレードを引き続き受け取っている場合でも、最初のステージで新しいバージョンのロールアウトを開始できます。たとえば、ロールアウト順序内の 3 番目のグループがバージョン 1.31.12-gke.1265000 をロールアウトしている場合、最初のグループは並行してバージョン 1.31.13-gke.1008000 をロールアウトできます。
ロールアウト シーケンスを選択する際の考慮事項
新しいバージョンを別の環境にロールアウトする前に、1 つの環境で新しいバージョンの適格性を評価してクラスタのアップグレードを管理する場合は、ロールアウトの順序付けの使用を検討してください。
ただし、次のいずれかに当てはまる場合は、環境にとって適切な選択肢にならないことがあります。
- 同じ本番環境に、同じリリース チャンネル上になくマイナー バージョンでもないクラスタがある。
- 1 つのグループ内のクラスタに異なる自動アップグレードのターゲット バージョンが作成される原因になるような手動アップグレードを頻繁に行う。
制限事項
カスタム ステージでロールアウト シーケンスを使用してクラスタをアップグレードする場合は、次の制限が適用されます。
- Google Cloud コンソールを使用して、カスタム ステージを含むロールアウト シーケンスを作成または表示することはできません。
- ロールアウト シーケンスでフリートを参照する場合は、フリート全体を含める必要があります。この制約は、
label-selectorを使用してフリートからクラスタのサブセットのみをターゲットとするステージを定義する場合（段階的デプロイなど）、同じフリートの残りのすべてのクラスタを含む後続の「キャッチオール」ステージも定義する必要があることを意味します。このキャッチオール ステージは同じフリートをターゲットにしますが、label-selectorは含まれていません。これにより、シーケンスの前のステージで選択されなかったすべてのクラスタが自動的に含まれます。 - ロールアウト中にシーケンスを変更すると（特に、参加クラスタに影響する変更）、GKE は既存のすべてのロールアウトを直ちにキャンセルします。シーケンスのソーク時間のみを変更した場合、GKE はロールアウトをキャンセルしません。
- 特定のバージョンのアクティブなロールアウトを手動で加速することはできません。ロールアウト シーケンス定義でソーク期間を変更すると、変更後に作成される現在および将来のすべてのロールアウトのデフォルトのソーク時間が更新されます。
- GKE は、サポートが終了したクラスタをサポート対象のバージョンに自動的にアップグレードします。このアップグレードは、定義されたロールアウト シーケンスに従わない場合があります。
- ステージは最大 1 つのフリートを参照できます。1 つのステージに複数のフリートを設定することはできません。
- 1 つのフリートは、1 つのロールアウト シーケンスでのみ参照できます。2 つのロールアウト シーケンスで同じフリートを参照することはできません。
既知の問題
このセクションでは、カスタム ステージを使用したロールアウト シーケンスの既知の問題について説明します。
- ロールアウト シーケンスのステージにクラスタが含まれていない場合、そのステージはスキップされますが、そのステージに定義されたソーク時間は、ロールアウトが次のステージに進む前に経過します。