ロールアウト シーケンスを使用すると、複数の環境で Google Kubernetes Engine（GKE）クラスタ全体にわたるクラスタの自動アップグレードの順序を管理できます。たとえば、本番環境クラスタをアップグレードする前に、本番前環境クラスタで新しいバージョンの適格性を確認できます。GKE には、この機能の以前のバージョンであるフリートベースのロールアウト シーケンスも用意されています。この機能は機能が制限されており、新しい環境にはおすすめしません。
このドキュメントでは、次の内容を理解していることを前提としています。
ロールアウト シーケンスを構成するには、カスタム ステージを使用してクラスタのアップグレードのロールアウトを順序付けるをご覧ください。概要
GKE ロールアウト シーケンスを使用すると、環境全体にわたるクラスタ アップグレードの特定の順序を定義できます。たとえば、まず開発環境のクラスタをアップグレードし、次にテスト環境、最後に本番環境のクラスタをアップグレードします。この段階的な戦略にはベイク時間が組み込まれているため、アップグレードが最も重要なシステムに到達する前に、潜在的な問題を発見して軽減できます。
ロールアウト シーケンスは、フリートの概念に基づいて構築されています。フリートは、環境（テストなど）にマッピングされた GKE クラスタの論理グループです。この機能を使用するには、フリートで構成されるシーケンスを定義し、各グループ間のソーク時間を設定します。GKE が新しいバージョンを選択すると、定義された順序でクラスタがアップグレードされ、バージョンが本番環境に完全にデプロイされる前にワークロードを検証できます。
フリートは軽量なメンバーシップをサポートしています。これにより、フリートレベルの構成と機能をすべて有効にせずに、ロールアウト シーケンス用にクラスタを論理的にグループ化できます。軽量メンバーシップは、フリートレベルの Namespace の同一性など、フリートの完全な管理の他の影響を受けずにロールアウト シーケンスを使用する場合に適しています。詳細については、軽量メンバーシップをご覧ください。
ロールアウトの順序付け戦略を選択する
GKE には、ロールアウト シーケンスの 2 つのバージョンがあります。どちらのバージョンも、プログレッシブなフリートベースのアップグレードという同じ基本原則に基づいて構築されていますが、新しい環境ではカスタム ステージでロールアウト シーケンスを使用することをおすすめします。
- カスタム ステージを使用したロールアウト シーケンス（新しい環境に推奨）: このバージョンはフリートベースのモデルの進化版で、よりきめ細かい制御と柔軟性を提供しますが、 Cloud de Confiance コンソール サポートがありません。カスタム ステージを使用すると、ラベルを使用してフリート内の特定のステージを定義できます。そのため、より広範なロールアウトの前に本番環境クラスタの小さなサブセットに新しいバージョンをデプロイするなど、より複雑なロールアウト戦略に適しています。また、特定のバージョンへのロールアウトの開始、シーケンスでロールアウトするアップグレードの種類の選択、ロールアウトの一時停止やキャンセルなど、ロールアウトをより詳細に制御できます。ロールアウト シーケンスを初めて作成する場合は、このオプションを選択します。
- フリートベースのロールアウト シーケンス: Cloud de Confiance コンソールで使用できる唯一のバージョンの機能ですが、機能が制限されています。ロールアウト シーケンスを初めて作成する場合は、このバージョンはおすすめしません。
このドキュメントの残りの部分は、カスタム ステージでのロールアウト シーケンスにのみ関連します。
カスタム ステージを使用したロールアウト シーケンス
カスタム ステージでロールアウト シーケンスを使用する場合は、フリート アップグレードの順序を定義し、ソーク時間を設定します。また、次の操作も行うことができます。
- ラベルを使用してフリート内のクラスタの特定のサブセットをターゲットにできる、粒度の細かいステージを含むシーケンスを定義します。これは、段階的ロールアウトなどの戦略に適しています。
- 新しい
RolloutSequenceAPI オブジェクトとRolloutAPI オブジェクトを使用して、制御とオブザーバビリティを強化します。
この方法では、クラスタのアップグレードを最も柔軟にきめ細かく制御できます。フリート内のクラスタの特定のサブセットをターゲットにするには、label-selector を使用して、特定の Kubernetes ラベルを持つクラスタのみをターゲットにします。
次の図は、GKE がカスタム ステージを使用するロールアウト順序でクラスタを自動的にアップグレードする仕組みを示しています。ステージは、prod フリートの canary という名前の label-selector を持つクラスタをターゲットにします。
GKE が新しいバージョンをロールアウトすると、GKE は最初にテストフリートのクラスタをアップグレードし、次にステージング フリートのクラスタをアップグレードします。次に、本番環境フリートで、GKE は label-selector に一致するクラスタを優先します。prod-cluster-1 に canary:
true のラベルが付けられているため、GKE はこのクラスタを次にアップグレードします。このステージにはラベルセレクタがないため、GKE はプロセスの最後に、本番環境フリート（メインステージ）内の残りのすべてのクラスタをアップグレードします。
ステージ間で構成されたソーク時間中に、アップグレードされたクラスタでワークロードが期待どおりに実行されていることを確認できます。上記の例では、本番環境フリートに 1 つのカスタム ステージを示していますが、任意のフリートに複数のステージを追加することも、複数のステージを含む 1 つのフリートのみを使用することもできます。
主なコンセプト
- ソーク時間: ステージ内のすべてのクラスタがアップグレードされた後に発生する構成可能な待機期間。このソーク時間により、1 つの環境で新しいバージョンを検証し、アップグレードが次の環境に進む前に潜在的な問題を検出できます。シーケンスの各ステージで、最大 30 日間のソーク時間を設定できます。本番前ステージでのソーク時間が長くなると、検証に費やせる時間が増えます。
RolloutSequence: このオブジェクトは、アップグレード シーケンスの定義に使用するプライマリ リソースです。RolloutSequenceには、順序付けられた一連のステージが含まれています。これにより、アップグレードが次のステージに進む前に、前のステージのクラスタが完全にアップグレードされ、ソーク期間が完了していることを確認します。各RolloutSequenceには、ロールアウトされた新しいバージョンごとに 1 つのRolloutがあります。Rollout: このオブジェクトを使用すると、シーケンスを介して単一バージョンのアップグレードの進行状況をモニタリングできます。Rolloutを使用して、ロールアウトのステータスを表示し、進行状況を追跡し、アップグレードの対象外のクラスタがあるかどうかとその理由を確認できます。各Rolloutは、バージョンのロールアウト順序を表す特定のRolloutSequenceに関連付けられます。- 専用のホスト プロジェクト: 専用のCloud de Confiance by S3NS プロジェクトを使用して
RolloutSequenceオブジェクトをホストすることをおすすめします。シーケンスを専用のプロジェクトに配置すると、ロールアウト シーケンスの中立的な中央制御ポイントが提供されます。これは、CI/CD パイプラインの管理に関するベスト プラクティスと同様です。
専用ホスト プロジェクトで RolloutSequence リソースを作成して管理します。
- ステージ: ステージはロールアウト シーケンスのステップです。各ステージには、一緒にアップグレードされるクラスタのグループが含まれています。
- フリート: フリートはクラスタをグループ化する主な方法です。ロールアウト シーケンスのステージは、1 つのフリートのみを参照できます。
- ラベル セレクタ: ロールアウト シーケンスは 1 つ以上のステージで構成されます。各ステージには 1 つのフリートのクラスタが含まれます。クラスタのラベル セレクタを使用して、フリートを複数のステージに分割できます。このアプローチでは、本番環境クラスタの小さなサブセットを最初にアップグレードする段階的なロールアウトなどの戦略が可能です。
GKE がロールアウト順序でクラスタをアップグレードする仕組み
GKE がクラスタをアップグレードする場合は、まずコントロール プレーンがアップグレードされ、次にノードがアップグレードされます。ロールアウト順序では、クラスタはこのプロセスでアップグレードされますが、クラスタのグループ（フリート）がアップグレードされる順序も制御できます。また、あるグループから次のグループへアップグレードを進める前に GKE が一時停止する時間を定義するソーク時間も指定します。
ロールアウト順序でのクラスタのアップグレードは、次の手順で行います。
- GKE は、ロールアウト シーケンスで新しいロールアウトを開始します。デフォルトでは、GKE が特定のリリース チャンネルのマイナー バージョンのクラスタに新しい自動アップグレード ターゲットを設定すると、ロールアウトが開始されます。カスタム ステージを使用したロールアウト シーケンスでは、ロールアウト シーケンス全体で、選択した特定のバージョンに新しいロールアウトをトリガーすることもできます。
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 が新しいバージョンのロールアウトを開始する方法
デフォルトでは、GKE は新しい自動アップグレード ターゲットを設定するときに新しいロールアウトを作成します。GKE がロールアウト用に選択するバージョンは、シーケンス内のクラスタのマイナー バージョンとリリース チャンネルによって異なります。たとえば、クラスタが Regular チャンネルで GKE バージョン 1.35 を実行しており、GKE が自動アップグレードのターゲットを 1.35.5-gke.1000000 に設定すると、GKE は新しい Rollout を作成します。
ただし、GKE でロールアウトするバージョンを選択することもできます。
特定のバージョンのロールアウト
たとえば、セキュリティの脆弱性を迅速に修正する場合や、GKE クラスタの重大な問題を修正する場合は、特定のバージョンへのロールアウトを開始することもできます。このアクションにより Rollout オブジェクトが作成され、GKE が自動アップグレード ターゲットを設定したときと同じように、ロールアウト シーケンス全体でロールアウトが開始されます。新しいバージョンをロールアウトするには、特定のバージョンをロールアウトするをご覧ください。
新しいバージョンをクラスタにできるだけ早くロールアウトする必要がある場合は、個々のクラスタに対してクラスタの手動アップグレードを行うこともできます。クラスタの手動アップグレードはクラスタレベルで実行されます。
ロールアウト シーケンスで GKE が実行するアップグレードのタイプを選択する
デフォルトでは、GKE はすべてのタイプのクラスタ アップグレードをロールアウト シーケンスにロールアウトします。これには、コントロール プレーンとノードのパッチ バージョンとマイナー バージョンの両方のアップグレードが含まれます。
アップグレードには主に 4 つの種類があります。
- コントロール プレーンのパッチ バージョンのアップグレード
- ノードのパッチ バージョンのアップグレード
- コントロール プレーンのマイナー バージョンのアップグレード
- ノードのマイナー バージョンのアップグレード
ロールアウト順序でクラスタ アップグレードのスコープを制限して、特定のタイプのアップグレードのみを実行できます。たとえば、ノードのアップグレードではなく、コントロール プレーンのアップグレードのみを GKE でロールアウトする場合は、ロールアウト シーケンスでこれを指定できます。
ロールアウト シーケンスのクラスタ アップグレードのスコープを制限すると、GKE は、ロールアウト シーケンス内のクラスタに対して、必要な必須の自動アップグレードを除き、そのタイプの自動アップグレードを実行しません。詳細については、必須の自動アップグレードのロールアウトをご覧ください。クラスタ アップグレードのスコープを制限しても、制限したタイプの進行中のロールアウトはキャンセルされません。GKE がそのタイプのロールアウトを今後作成できなくなるだけです。
GKE はクラスタのノードをコントロール プレーンより新しいバージョンにアップグレードしないため、コントロール プレーンのアップグレードの範囲を制限すると、ノードのアップグレードも制限できます。
ロールアウト シーケンスで自動アップグレードの範囲を制限するには、ロールアウト シーケンスで GKE が実行するアップグレードの種類を選択するをご覧ください。
ロールアウト シーケンスのスコープを制限する仕組みは、メンテナンスの除外と似ていますが、メンテナンスの除外は、クラスタ内の個々のクラスタまたはノードプールに対して設定されます。
必須の自動アップグレードのロールアウト
クラスタがロールアウト シーケンスに登録されているかどうかにかかわらず、GKE はセキュリティと互換性を確保するための自動クラスタ アップグレードを実行します。ロールアウト シーケンス内のクラスタのコントロール プレーンが 90 日間アップグレードされていない場合、またはクラスタでサポートが終了したマイナー バージョンが実行されている場合、GKE は自動アップグレードを実行するための必須ロールアウトを作成します。これらのロールアウトにより、クラスタのパフォーマンス、可用性、セキュリティが維持されます。GKE は、ロールアウトの範囲の制限、メンテナンス除外、その他の遅延理由に関係なく、これらのシナリオのロールアウトを作成します。
これらのタイプのロールアウトを一時停止またはキャンセルすることはできません。GKE は、ロールアウト シーケンスの登録に関係なく、これらのタイプのクラスタ アップグレードを実行します。
これらのポリシーの詳細については、次のセクションをご覧ください。
ロールアウトの適格性
カスタム ステージを使用するシーケンスでバージョンをロールアウトするには、クラスタがリリース チャンネルのアップグレード ターゲットの対象である必要があります。新しい 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 が特定の種類のアップグレードのみを実行するように制限できます。
- クラスタレベルまたはノードプール レベル: メンテナンスの除外
- ロールアウト シーケンス レベル: GKE がロールアウト シーケンスで実行するアップグレードのタイプを選択する
ただし、クラスタ アップグレードの範囲を制限するこれらの方法では、必須の自動アップグレードを防ぐことはできません。メンテナンスの時間枠やメンテナンスの除外により GKE がクラスタをアップグレードできない場合は、ステージ内のクラスタのアップグレードが終了しなくなることがあります。メンテナンスの時間枠やメンテナンスの除外により、30 日以内にクラスタのアップグレードを完了できない場合、すべてのクラスタのアップグレードが完了したかどうかにかかわらず、ステージはそのソークフェーズに入ります。
ノードのアップグレード戦略: ロールアウトの順序付けは、構成されたノードのアップグレード戦略（Blue/Green アップグレードなど）に影響しません。ロールアウトの順序付けがないクラスタのアップグレードと同様に、GKE は Autopilot ノードにサージ アップグレードを使用します。詳細については、ノードの自動アップグレードをご覧ください。
ノードのアップグレードが 30 日以内に完了しない場合、すべてのクラスタのアップグレードが完了したかどうかにかかわらず、そのグループはソークフェーズに入ります。この動作は、ノード アップグレード戦略によって Standard クラスタのノード アップグレードの完了に時間がかかる場合（特に大規模なノードプールの場合）に発生することがあります。また、メンテナンスの時間枠の長さがノードのアップグレードを完了させるのに十分でない場合は、状況が悪化する可能性もあります。
リリース チャンネル: ロールアウト シーケンス内のすべてのクラスタを同じリリース チャンネルに登録することをおすすめします。
非推奨の使用状況の検出: GKE の非推奨の使用状況の検出は引き続き想定どおりに機能し、非推奨の API を使用するクラスタでアップグレードが一時停止される可能性があります。
手動アップグレード: シーケンスの最初のステージでクラスタを手動でアップグレードしても、そのバージョンが自動的に認定されたり、ロールアウトがトリガーされて続行されたりすることはありません。自動ロールアウト プロセスは、リリース チャンネルに設定された公式の自動アップグレードの対象によって駆動されます。手動アップグレードではクラスタが更新されますが、そのバージョンが自動アップグレードの対象として指定された後にのみ、シーケンスが開始されます。
クラスタ通知: GKE は、他の利用可能なクラスタ通知に加えて、ロールアウト シーケンスの通知を提供します。詳細については、ロールアウト シーケンスの通知をご覧ください。
1 つのロールアウト順序全体で複数のアップグレードを受け取る
リリース チャンネルは、クラスタのアップグレード ターゲットを選択します。以前のターゲットへのアップグレードがまだ進行中のときに新しいバージョンが利用可能になった場合、後のステージで以前のアップグレードを引き続き受け取っている場合でも、最初のステージで新しいバージョンのロールアウトを開始できます。たとえば、ロールアウト順序内の 3 番目のグループがバージョン 1.31.12-gke.1265000 をロールアウトしている場合、最初のグループは並行してバージョン 1.31.13-gke.1008000 をロールアウトできます。
ロールアウト シーケンスを選択する際の考慮事項
新しいバージョンを別の環境にロールアウトする前に、1 つの環境で新しいバージョンの適格性を評価してクラスタのアップグレードを管理する場合は、ロールアウトの順序付けの使用を検討してください。
ただし、次のいずれかに当てはまる場合は、環境にとって適切な選択肢にならないことがあります。
- 同じ本番環境に、同じリリース チャンネル上になくマイナー バージョンでもないクラスタがある。
- 1 つのグループ内のクラスタに異なる自動アップグレードのターゲット バージョンが作成される原因になるような手動アップグレードを頻繁に行う。
ロールアウト シーケンスの通知
GKE はクラスタ通知を送信します。この通知には、クラスタレベルでのクラスタ アップグレードに関する重要な情報が含まれています。また、GKE は、カスタム ステージを含むロールアウト シーケンスと、そのロールアウト シーケンスで実行されるロールアウトに関する通知を提供します。たとえば、ロールアウト ステージの開始、完了、ブロック時に GKE から通知が送信されます。また、ロールアウト シーケンスが正しく構成されていない場合は、GKE から通知が送信されます。詳細については、クラスタ通知ドキュメントと、RolloutEvent と RolloutSequenceEvent の各セクションをご覧ください。
ロールアウトを管理する
GKE がロールアウト シーケンス内のクラスタ全体に新しいバージョンをロールアウトするときに、次の操作を使用してプロセスを制御し、クラスタとワークロードが変更にどのように対応するかを評価できます。また、新しいロールアウトを作成して特定のバージョンをロールアウトすることもできます。
アップグレードの進行中に、ステータスを確認できます。アップグレードの進行状況に応じて、次のサブセクションで説明するアクションを使用できます。
ロールアウトを一時停止する
進行中のロールアウトは一時停止できます。たとえば、クラスタとロールアウトされる新しいバージョンに潜在的な問題があることに気づいた場合は、ロールアウトを一時的に一時停止できます。GKE はこのバージョンへの新しいアップグレード オペレーションを開始しないため、必要に応じて問題を調査できます。GKE は進行中のアップグレード オペレーションを停止しませんが、後続のステージを含め、新しいオペレーションを開始しません。
ロールアウトを一時停止するには、ロールアウトを一時停止するをご覧ください。
ロールアウトを一時停止した後、再開またはキャンセルできます。ロールアウトは最長 90 日間一時停止できます。90 日が経過すると、GKE はロールアウトをキャンセルします。
ロールアウトを一時停止しても、後続のロールアウトの開始は妨げられません。ただし、これらのロールアウトが一時停止されたロールアウト ステージを上回ることはありません。たとえば、GKE がすでに 1.34.8-gke.1000000 を第 1 段階と第 2 段階にロールアウトし、第 3 段階でロールアウトを一時停止した場合、GKE は 1.35.5-gke.1163000 への新しいロールアウトを開始し、最初の 2 つの段階でクラスタをアップグレードできます。ただし、1.34.8-gke.1000000 のロールアウトが第 3 段階で完了するか、キャンセルされるまで、GKE は第 3 段階で 1.35.5-gke.1163000 へのアップグレードを開始しません。
ロールアウト シーケンスで複数のロールアウトが進行中の場合に、それらをすべて一時停止するには、各ロールアウトを個別に一時停止する必要があります。GKE が追加のロールアウトを開始しないようにするには、ロールアウト シーケンスで GKE が実行するアップグレードのタイプを選択します。
ロールアウトの再開
90 日未満一時停止した一時停止中のリリースは、潜在的な問題を調査し、アップグレードを進める準備が整ったら再開できます。一時停止したロールアウトを再開できるのは、同じタイプ（コントロール プレーンのロールアウトまたはノードのロールアウト）の別のロールアウトが同じステージで同時に実行されていない場合のみです。技術的またはビジネス上の理由で GKE によって自動的に一時停止されたロールアウトを再開することもできますが、再開する前に注意することをおすすめします。
ロールアウトを再開すると、GKE は新しいアップグレード オペレーションを開始して、ロールアウト シーケンスのステージ全体で新しいバージョンのロールアウトを続行します。
ロールアウトを再開するには、ロールアウトを再開するをご覧ください。
ロールアウトのキャンセル
ロールアウト（アクティブなロールアウトや一時停止されたロールアウトを含む）をキャンセルできます。ロールアウトをキャンセルしても、GKE は同じバージョンへの新しいロールアウトを自動的に作成しません。ただし、ロールアウトをキャンセルしても、GKE が後で新しいバージョンをロールアウトすることを防ぐことはできません。GKE が以降のバージョンもロールアウトしないようにするには、進行中のロールアウトをすべてキャンセルし、ロールアウト順序でクラスタ アップグレードのスコープを制限します。
ロールアウトをキャンセルするには、ロールアウトをキャンセルするをご覧ください。
キャンセルされたバージョンと同じバージョンをリリースする必要がある場合は、特定のバージョンをリリースします。
ロールアウト ステージを完了する
たとえば、そのステージでのテストが完了したため、バージョンのロールアウトをロールアウト シーケンスの次のステージに進めることができると判断した場合は、ステージを完了してロールアウトを手動で進めることができます。ステージを完了すると、GKE がまだアップグレードしていないクラスタは、そのロールアウトの一部としてアップグレードされません。ステージを完了すると、残りの浸漬時間もスキップされます。この操作により、ロールアウト シーケンス レベルでソーク時間を変更する必要もなくなります。
ロールアウト ステージを完了するには、ロールアウト ステージを完了するをご覧ください。
ロールアウト シーケンスを変更してロールアウトを管理する
ロールアウト シーケンス全体に影響するアクションを実行して、ロールアウトを管理することもできます。ただし、ロールアウトの一時停止など、前のセクションで説明したアクションを先に実行することを検討してください。ロールアウト シーケンスを変更すると、進行中のロールアウトがキャンセルされるだけでなく、シーケンス内の今後のロールアウトの動作にも影響する可能性があります。1 つのロールアウトのみを変更する場合は、シーケンス全体を変更するのではなく、提供されているツールを使用して 1 つのロールアウトを管理します。
ただし、1 つの新しいバージョンのロールアウトだけでなく、すべてのロールアウトでロールアウト シーケンスの機能を変更する場合は、次のセクションのロールアウト シーケンスの管理をご覧ください。
個々のクラスタ アップグレードを制御してロールアウトを管理する
個々のクラスタのアップグレードでは、次のツールを使用してアップグレードを管理できます。
- ノードプールのアップグレードのキャンセル、再開、ロールバック、完了などの操作を行うアップグレードの手動制御。
- メンテナンスの時間枠と除外を使用して、クラスタのアップグレードを許可するタイミングとできないタイミングを決定します。
- ノードのアップグレード戦略を構成し、ノードで実行されるワークロードに応じてスピードとリスク許容度のバランスを取る。
詳細については、ロールアウトの順序付けが他のアップグレード機能と連動する仕組みをご覧ください。
ロールアウト シーケンスの管理
ロールアウト シーケンスを管理するには、次のような基本的な操作を行うことができます。
- ロールアウト シーケンスを一覧表示する
- ロールアウト シーケンスについて説明する
また、ロールアウト シーケンスの変更や、ロールアウト シーケンス内のクラスタの無視などのアクションを実行することもできます。これらのアクションについては、次のサブセクションで説明します。
ロールアウト シーケンス全体ではなく、1 つのバージョンのロールアウトを管理する方法については、前のセクションのロールアウトを管理するをご覧ください。
ロールアウト シーケンスでクラスタを無視する
デフォルトでは、ロールアウト シーケンスのフリートに属するクラスタは、ロールアウト シーケンスの一部としてアップグレードされます。クラスタを特定のステージに追加することも、フリート内のラベルのないクラスタをまとめてアップグレードすることもできます。
ただし、ロールアウト シーケンスに含めたくないクラスタがある場合は、GKE が新しいバージョンをロールアウトするときにクラスタを無視するようにラベル付けできます。たとえば、特定のクラスタをアップグレードする前に追加の時間が必要な場合は、これが必要になることがあります。ロールアウト順序で 1 つ以上のクラスタを無視できます。
ロールアウト シーケンス内のクラスタを無視すると、GKE は新しいバージョンをロールアウトするときにそのクラスタを考慮せず、そのクラスタの自動アップグレードを実行しません。ただし、サポート終了時の自動アップグレードや90 日間アップグレードされていないコントロール プレーンの自動アップグレードなどの必須の自動アップグレードは除きます。
ロールアウト シーケンスでクラスタを無視するには、ロールアウト シーケンスでクラスタを無視するをご覧ください。
ロールアウト シーケンスを変更する
既存のロールアウト シーケンスでロールアウトを進行する方法を変更する場合は、次のいずれかの方法でシーケンスを変更できます。
- ロールアウト シーケンスを変更するには、シーケンスを定義した YAML 構成ファイルを編集します。
- シーケンス内のクラスタを変更します。
ロールアウト シーケンスを変更すると、次のようになります。
- ロールアウト シーケンスでステージを追加、削除、順序変更、編集（ステージのプロジェクト ID やラベルセレクタの変更など）すると、GKE はアクティブなロールアウトをすべてキャンセルします。
- ステージのソーク時間を変更しても、GKE はアクティブなロールアウトをキャンセルしません。
ロールアウト シーケンスを変更するには、ロールアウト シーケンスを変更するをご覧ください。
クラスタを順番に変更すると、次のようになります。
- フリートからクラスタを削除して、ロールアウト シーケンスからクラスタを削除しても、アクティブなロールアウトは続行されます。GKE は、シーケンスに登録されていないクラスタの一般的な手順に基づいて、クラスタを自動的にアップグレードできます。
- ロールアウト シーケンスでクラスタをフリートに追加すると、GKE は、追加したステージをまだ通過していないアクティブなロールアウトの一部として、このクラスタをアップグレードします。ただし、ロールアウトのステージが完了している場合、GKE はそのロールアウトでクラスタをアップグレードしません。
ロールアウト シーケンス構成を編集せずにクラスタを別のステージに移動すると、移動先のステージが完了しているかどうかに応じて、次のようになります。
- ロールアウトがすでに完了しているステージにクラスタを移動した場合、GKE はそのロールアウトでクラスタをアップグレードしません。
- ロールアウトでアップグレード済みのクラスタを、後で未完了のステージに移動すると、GKE はクラスタを無視し、ロールアウトの進行を中断しません。
シーケンス内のクラスタを変更するには、 Cloud de Confiance by S3NS でクラスタをフリートに登録するをご覧ください。
制限事項
カスタム ステージでロールアウト シーケンスを使用してクラスタをアップグレードする場合、次の制限が適用されます。
- Cloud de Confiance コンソールを使用して、カスタム ステージを含むロールアウト シーケンスを作成または表示することはできません。
- ロールアウト シーケンスがフリートを参照する場合は、フリート全体を含める必要があります。この制約は、
label-selectorを使用してフリートからクラスタのサブセットのみをターゲットとするステージを定義する場合（段階的デプロイなど）、同じフリートの残りのすべてのクラスタを含む後続の「キャッチオール」ステージも定義する必要があることを意味します。このキャッチオール ステージは同じフリートをターゲットにしますが、label-selectorは含まれていません。これにより、シーケンスの前のステージで選択されなかったすべてのクラスタが自動的に含まれます。 - ロールアウト中にシーケンスを変更すると（特に、参加クラスタに影響する変更）、GKE は既存のロールアウトをすべて直ちにキャンセルします。シーケンスのソーク時間のみを変更した場合、GKE はロールアウトをキャンセルしません。
- ステージは最大 1 つのフリートを参照できます。1 つのステージに複数のフリートを設定することはできません。
- 1 つのフリートは、1 つのロールアウト シーケンスでのみ参照できます。2 つのロールアウト シーケンスで同じフリートを参照することはできません。
- 高速パッチ自動アップグレードを使用するロールアウト シーケンスでクラスタをアップグレードすることはできません。
- 最大 15 個のステージを含むロールアウト シーケンスを作成できます。
- フリートには最大 250 個のクラスタを含めることができます。軽量メンバーシップを使用するクラスタの場合、フリート内の最大 2,000 個のクラスタの割り当ての増加をリクエストできます。詳細については、割り当てと上限をご覧ください。
- すべてのステージで、シーケンスあたりの最大ソーク時間を最大 90 日間に設定できます。
既知の問題
このセクションでは、カスタム ステージを使用したロールアウト シーケンスの既知の問題について説明します。
- ロールアウト シーケンスのステージにクラスタが含まれていない場合、そのステージはスキップされますが、そのステージに定義されたソーク時間は、ロールアウトが次のステージに進む前に経過します。