カスタム ステージを使用したロールアウトの順序付けについて

複数の環境で、Google Kubernetes Engine(GKE)クラスタ全体にわたるクラスタの自動アップグレードの順序を管理するには、ロールアウトの順序付けを使用します。たとえば、本番環境クラスタをアップグレードする前に、生産開始前クラスタで新しいバージョンの適格性を確認できます。GKE には、この機能の以前のバージョンであるフリートベースのロールアウト シーケンスも用意されています。この機能は機能が制限されているため、新しい環境にはおすすめしません。

このドキュメントでは、次の内容を理解していることを前提としています。

ロールアウト シーケンスを構成するには、カスタム ステージを使用してクラスタのアップグレードのロールアウトを順序付けるをご覧ください。

概要

GKE のロールアウト シーケンスを使用すると、環境全体でクラスタのアップグレードに特定の順序を定義できます。たとえば、最初に開発環境のクラスタをアップグレードし、次にテスト環境、最後に本番環境をアップグレードできます。この段階的な戦略では、組み込みのベイク時間が提供されるため、アップグレードが最も重要なシステムに到達する前に、潜在的な問題を検出して軽減できます。

ロールアウト シーケンスは、フリートのコンセプトに基づいて構築されています。フリートは、環境(テストなど)にマッピングされた GKE クラスタの論理グループです。この機能を使用するには、フリートで構成されるシーケンスを定義し、各グループ間のソーク時間を設定します。GKE が新しいバージョンを選択すると、クラスタは定義された順序でアップグレードされます。これにより、バージョンが本番環境に完全にデプロイされる前にワークロードを検証できます。

フリートは軽量なメンバーシップをサポートしています。これにより、フリートレベルの構成と機能をすべて有効にせずに、ロールアウトの順序付けのためにクラスタを論理的にグループ化できます。フリートレベルの名前空間の同一性など、完全なフリート管理の他の影響を受けずにロールアウト シーケンスを使用する場合は、軽量メンバーシップが適しています。詳細については、軽量メンバーシップをご覧ください。

ロールアウトの順序付け戦略を選択する

GKE には、2 つのバージョンのロールアウト シーケンスが用意されています。どちらのバージョンも、フリートベースの段階的なアップグレードという同じ基本原則に基づいて構築されていますが、新しい環境ではカスタム ステージを使用したロールアウト シーケンスを使用することをおすすめします。

  • カスタム ステージを使用したロールアウト シーケンス(新しい環境に推奨): このバージョンは、フリートベースのモデルを進化させたもので、よりきめ細かい制御と柔軟性を実現しますが、包括的な Google Cloud コンソール サポートはありません。カスタム ステージでは、ラベルを使用してフリート内の特定のステージを定義できます。これは、より広範なロールアウトの前に、本番環境クラスタの小さなサブセットに新しいバージョンをデプロイするなど、より複雑なロールアウト戦略に適しています。また、特定のバージョンへのロールアウトの開始、シーケンスでロールアウトするアップグレードの種類の選択、ロールアウトの一時停止やキャンセルなど、ロールアウトをより細かく制御できます。ロールアウト シーケンスを初めて作成する場合は、このオプションを選択します。
  • フリートベースのロールアウト シーケンス: このバージョンの機能は、 Google Cloud コンソールでより包括的にサポートされていますが、機能が制限されているため、ロールアウト シーケンスを初めて作成する場合はおすすめしません。

このドキュメントの残りの部分は、カスタム ステージを使用したロールアウトのシーケンスにのみ適用されます。

カスタム ステージを使用したロールアウト シーケンス

カスタム ステージでロールアウト シーケンスを使用する場合は、フリートのアップグレードの順序を定義し、ソーク時間を設定します。また、次の操作も行うことができます。

  • ラベルを使用してフリート内のクラスタの特定のサブセットをターゲットにできる、きめ細かいステージを含むシーケンスを定義します。これにより、段階的なロールアウトなどの戦略に適しています。
  • 新しい RolloutSequence API オブジェクトと Rollout API オブジェクトにより、制御性とオブザーバビリティが向上します。

この方法では、クラスタのアップグレードを最も柔軟かつきめ細かく制御できます。フリート内のクラスタの特定のサブセットをターゲットにするには、label-selector を使用して、特定の Kubernetes ラベルを持つクラスタのみをターゲットにします。

次の図は、GKE がカスタム ステージを使用するロールアウト順序でクラスタを自動的にアップグレードする仕組みを示しています。このステージは、prod フリート内の canary という名前の label-selector を持つクラスタをターゲットにします。

GKE のカスタム ステージを使用したロールアウト シーケンス。
図: カスタム ステージを含むロールアウト シーケンス

GKE が新しいバージョンをロールアウトすると、GKE は最初にテストフリートのクラスタをアップグレードし、次にステージング フリートのクラスタをアップグレードします。次に、Production フリートで、GKE は label-selector に一致するクラスタを優先します。prod-cluster-1 には canary: true というラベルが付いているため、GKE は次にこのクラスタをアップグレードします。このステージにはラベルセレクタがないため、GKE はプロセスの最後に、本番環境フリート(メインステージ)の残りのすべてのクラスタをアップグレードします。

ステージ間で構成されたソーク時間中に、アップグレードされたクラスタでワークロードが期待どおりに実行されていることを確認できます。上記の例では、Production フリートに 1 つのカスタム ステージが示されていますが、任意のフリートに複数のステージを追加することも、複数のステージで 1 つのフリートのみを使用することもできます。

主なコンセプト

  • ソーク時間: ステージ内のすべてのクラスタがアップグレードされた後に発生する、構成可能な待機期間。このソーク時間により、1 つの環境で新しいバージョンを検証し、アップグレードが次の環境に進む前に潜在的な問題を検出できます。シーケンスの各ステージに最大 30 日間のソーク時間を構成できます。生産開始前ステージのソーク時間を長くすると、検証に時間をかけることができます。
  • RolloutSequence: このオブジェクトは、アップグレード シーケンスの定義に使用するプライマリ リソースです。RolloutSequence には、順序付けられた一連のステージが含まれています。これにより、アップグレードが次のステージに進む前に、前のステージのクラスタが完全にアップグレードされ、ソーク期間が完了していることが確認されます。各 RolloutSequence には、ロールアウトされた新しいバージョンごとに 1 つの Rollout があります。
  • Rollout: このオブジェクトを使用すると、シーケンス全体で 1 つのバージョン アップグレードの進行状況をモニタリングできます。Rollout を使用すると、ロールアウトのステータスを確認し、進行状況を追跡できます。また、アップグレードの対象外のクラスタがあるかどうか、およびその理由を確認できます。各 Rollout は、バージョンがロールアウトされるシーケンスを表す特定の RolloutSequence に関連付けられます。
  • 専用ホスト プロジェクト: RolloutSequence オブジェクトをホストするには、専用のGoogle Cloud プロジェクトを使用することをおすすめします。シーケンスを専用のプロジェクトに配置すると、ロールアウト シーケンスを中立的かつ一元的に制御できます。これは、CI / CD パイプラインの管理におけるベスト プラクティスと同様です。
ベスト プラクティス:

専用のホスト プロジェクトで RolloutSequence リソースを作成して管理します。

  • ステージ: ステージは、ロールアウト シーケンスのステップです。各ステージには、一緒にアップグレードされるクラスタのグループが含まれます。
  • フリート: フリートは、クラスタをグループ化する主な方法です。ロールアウト シーケンスのステージでは、1 つ以上のフリートを参照できます。1 つのロールアウト シーケンスに、複数のGoogle Cloud 組織でホストされているフリートを含めることができます。
  • ラベルセレクタ: ロールアウト シーケンスは 1 つ以上のステージで構成されます。各ステージには 1 つのフリートのクラスタが含まれます。クラスタでラベルセレクタを使用すると、フリートを複数のステージに分割できます。このアプローチでは、本番環境クラスタの小さなサブセットを最初にアップグレードする段階的なロールアウトなどの戦略が可能になります。

GKE がロールアウト順序でクラスタをアップグレードする仕組み

GKE がクラスタをアップグレードする場合は、まずコントロール プレーンがアップグレードされ、次にノードがアップグレードされます。ロールアウト順序では、クラスタはこのプロセスでアップグレードされますが、クラスタのグループ(フリート)がアップグレードされる順序も制御できます。また、あるグループから次のグループへアップグレードを進める前に GKE が一時停止する時間を定義するソーク時間も指定します。

ロールアウト順序でのクラスタのアップグレードは、次の手順で行います。

  1. GKE は、ロールアウト シーケンスで新しいロールアウトを開始します。デフォルトでは、GKE が特定のリリース チャンネルのマイナー バージョンのクラスタに新しい自動アップグレード ターゲットを設定すると、ロールアウトが開始されます。カスタム ステージを使用したロールアウト シーケンスの場合、選択した特定のバージョンへのロールアウト シーケンス全体で新しいロールアウトをトリガーすることもできます。
  2. GKE が、クラスタの最初のグループで、クラスタ コントロール プレーンの新しいバージョンへのアップグレードを開始します。GKE は、クラスタのコントロール プレーンがアップグレードした後、クラスタのノードのアップグレードを開始します。ロールアウト順序に従ってクラスタをアップグレードする場合、GKE はメンテナンスの時間枠や除外を尊重します。

  3. GKE は、コントロール プレーンのアップグレードで次の手順を行います。

    1. 最初のグループのクラスタ コントロール プレーンのアップグレードがすべて終了すると、GKE によってコントロール プレーンのアップグレードのソーク期間が開始されます。コントロール プレーンのアップグレードの開始から 30 日以上経過した場合も、GKE はソーク期間を開始します。
    2. 最初のグループのクラスタ コントロール プレーンのアップグレードのソーク期間が完了すると、GKE は 2 番目のグループのコントロール プレーンを新しいバージョンにアップグレードします。ただし、次の点に注意してください。

      • 場合によっては、GKE が、2 番目のグループのクラスタ コントロール プレーンをアップグレードする前に、最初のグループのクラスタ コントロール プレーンを複数回アップグレードすることがあります。この状況が発生すると、GKE は次の属性を持つ最新バージョンを選択します。
        • このバージョンは、最初のグループによって認定されています。
        • このバージョンは、2 番目のグループのクラスタのコントロール プレーン バージョンより 1 つ後のマイナー バージョンまでです。
      • GKE は、最初のグループで認定されたバージョンよりも新しいバージョンを持つ 2 番目のグループのクラスタのコントロール プレーンをアップグレードしません。
  4. コントロール プレーンのアップグレードと並行して、GKE はノードのアップグレード用に次の手順を行います。

    1. 最初のグループのすべてのクラスタのノード アップグレードが完了すると、GKE によってノード アップグレードのソーク期間が開始されます。ノード アップグレードの開始から 30 日以上経過した場合も、GKE はソーク期間を開始します。
    2. 最初のグループのノード アップグレードのソーク期間が完了すると、GKE は 2 番目のグループのノードを新しいバージョンにアップグレードします。ただし、次の点に注意してください。
      • 場合によっては、GKE が 2 番目のグループのクラスタノードをアップグレードする前に、最初のグループのクラスタノードを複数回アップグレードすることがあります。この場合、GKE は次の属性を持つ最新バージョンを選択します。
        • このバージョンは、最初のグループによって認定されています。
        • バージョンが、2 番目のグループのクラスタ コントロール プレーン バージョンよりも新しいバージョンではない。
      • GKE は、最初のグループで認定されたバージョンよりも新しいバージョンを持つ、2 番目のグループのクラスタのノードをアップグレードしません。
  5. ロールアウト順序内のすべてのグループのクラスタが新しいバージョンにアップグレードされるまで、GKE は 2 番目のグループから 3 番目のグループにこの手順を繰り返します。

それぞれのグループでクラスタがアップグレードされたら、ソーク時間中に、ワークロードが、新しい GKE バージョンを実行しているクラスタで期待どおり動作することを確認します。

また、メンテナンスの時間枠や除外、非推奨の API の使用などの理由で、クラスタをアップグレードできないこともあります。

ロールアウト順序でのアップグレードを制御する方法

クラスタのロールアウト順序でのアップグレードでは、クラスタのグループを定義された順序でアップグレードし、各グループで決められた時間ソークします。このプロセスの制御の詳細については、以下をご覧ください。

例: コミュニティ バンクで変更をテスト環境から本番環境まで段階的にロールアウトする

あるコミュニティ バンクのプラットフォーム管理者が、テスト、ステージング、本番という 3 つの主要なデプロイ環境を管理しているとします。本番環境クラスタは複数のリージョンに分散されており、重要度はさまざまです。アップグレードを効果的に管理するために、管理者は各環境のクラスタをフリートにグループ化します。ロールアウトの順序付けに必要とされるとおり、3 つのフリートすべてにわたって各クラスタが同じリリース チャンネル(この場合は Regular チャンネル)に登録され、すべてのクラスタで同じマイナー バージョンが実行されています。

管理者の主な目標は、新しい GKE バージョンが銀行の重要な本番環境に到達する前に、徹底的に検証されるようにすることです。また、トラフィックの少ないリージョンからクラスタを段階的にアップグレードし、トラフィックの多いリージョン、最も重要なリージョンの順にアップグレードすることを希望しています。これを実現するために、カスタム ステージを使用したロールアウトの順序付けを使用して、リージョンに応じて本番環境クラスタにラベルを付けるなど、段階的なアップグレード戦略を定義します。このアプローチにより、完全なロールアウトの前に、本番環境トラフィックの小さなサブセットで新しいバージョンを検証できます。

この計画を実装するために、管理者は Production フリートのクラスタに次のラベルを適用します。

  • us-west1(トラフィックが少ない)のクラスタには prod-region: us-west1 というラベルが付けられます。
  • europe-west1(トラフィックが多い)のクラスタには prod-region: europe-west1 というラベルが付けられます。
  • us-east1(最も重要なトラフィック)のクラスタにはラベルが付けられていません。シーケンス内のフリートの最終ステージは、残りのすべてのクラスタの「キャッチオール」として機能する必要があります。したがって、管理者はこれらの残りのクラスタにラベルを追加する必要はありません。

次に、CI / CD 構成の管理に使用される専用のホスト プロジェクトで、RolloutSequence オブジェクトを定義します。この新しいシーケンスには、次の 5 つの段階があります。

  1. テスト: このステージには、testing フリート内のすべてのクラスタが含まれます。管理者は、徹底的な検証を可能にするために、3 日間のソーク時間を設定します。
  2. ステージング: このステージには、staging フリート内のすべてのクラスタが含まれます。ソーク時間は 3 日間です。
  3. リージョン us-west1 のプロダクション: このステージはプロダクションフリートをターゲットにしますが、label-selector を使用して prod-region: us-west1 ラベルを持つクラスタのみを含めます。この段階では、管理者は 3 日間のソーク時間で本番環境クラスタの小さなサブセットの問題をモニタリングできます。
  4. リージョン europe-west1 のプロダクション: このステージには、prod-region: europe-west1 ラベルを持つ production フリートのクラスタが含まれます。管理者は、より徹底的な検証を行うために、4 日間の長いソーク時間を設定します。
  5. リージョン 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 がクラスタをアップグレードできない場合は、ステージ内のクラスタのアップグレードが終了しなくなることがあります。メンテナンスの時間枠やメンテナンスの除外により、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 つのステージでクラスタをアップグレードできます。ただし、GKE は、第 3 ステージで 1.34.8-gke.1000000 のロールアウトが完了するか、キャンセルされるまで、第 3 ステージで 1.35.5-gke.1163000 へのアップグレードを開始しません。

ロールアウト シーケンスで複数のロールアウトが進行中で、それらをすべて一時停止する場合は、各ロールアウトを個別に一時停止する必要があります。GKE が追加のロールアウトを開始しないようにするには、GKE がロールアウト シーケンスで実行するアップグレードの種類を選択します。

ロールアウトの再開

潜在的な問題を調査し、アップグレードを続行する準備が整ったら、一時停止してから 90 日未満の一時停止中のロールアウトを再開できます。一時停止したロールアウトを再開できるのは、同じステージで同じタイプ(コントロール プレーンのロールアウトまたはノードのロールアウト)の別のロールアウトが同時に実行されていない場合のみです。技術的またはビジネス上の理由で GKE によって自動的に一時停止されたロールアウトを再開することもできますが、再開する前に注意することをおすすめします。

ロールアウトを再開すると、GKE は新しいアップグレード オペレーションを開始し、ロールアウト シーケンスのステージ全体で新しいバージョンのロールアウトを続行します。

ロールアウトを再開するには、ロールアウトを再開するをご覧ください。

ロールアウトのキャンセル

ロールアウトは、アクティブなロールアウトや一時停止されたロールアウトを含め、キャンセルできます。ロールアウトをキャンセルしても、GKE は同じバージョンへの新しいロールアウトを自動的に作成しません。ただし、ロールアウトをキャンセルしても、GKE がそれ以降のバージョンをロールアウトすることは防止されません。GKE がそれ以降のバージョンをロールアウトしないようにするには、進行中のすべてのロールアウトをキャンセルし、ロールアウト シーケンスでクラスタ アップグレードのスコープを制限します。

ロールアウトをキャンセルするには、ロールアウトをキャンセルするをご覧ください。

キャンセルされたバージョンと同じバージョンをロールアウトする必要がある場合は、特定のバージョンをロールアウトします。

ロールアウト ステージを完了する

たとえば、そのステージでのテストが完了したため、バージョンのロールアウトをロールアウト シーケンスの次のステージに進めることができると確信している場合は、ステージを完了することでロールアウトを手動で進めることができます。ステージを完了すると、GKE がまだアップグレードしていないクラスタは、そのロールアウトの一部としてアップグレードされません。ステージを完了すると、残りのソーク時間もスキップされます。この操作により、ロールアウト シーケンス レベルでソーク時間を変更する必要もなくなります。

ロールアウト ステージを完了するには、ロールアウト ステージを完了するをご覧ください。

ロールアウト シーケンスを変更してロールアウトを管理する

ロールアウト シーケンス全体に影響するアクションを実行して、ロールアウトを管理することもできます。ただし、その前に、ロールアウトの一時停止など、前のセクションで説明したアクションを行うことを検討してください。ロールアウト シーケンスを変更すると、シーケンス内の今後のロールアウトの動作に影響するだけでなく、進行中のロールアウトがキャンセルされる可能性があります。1 つのロールアウトのみを変更する場合は、シーケンス全体を変更するのではなく、提供されているツールを使用して 1 つのロールアウトを管理します。

ただし、1 つの新しいバージョンのロールアウトだけでなく、すべてのロールアウトでロールアウト シーケンスの機能を変更する場合は、次のセクションのロールアウト シーケンスの管理をご覧ください。

個々のクラスタのアップグレードを制御してロールアウトを管理する

個々のクラスタのアップグレードでは、次のツールを使用してアップグレードを管理できます。

  • ノードプールのアップグレードのキャンセル、再開、ロールバック、完了などの操作を行うアップグレードの手動制御。
  • メンテナンスの時間枠と除外を使用して、クラスタのアップグレードを許可するタイミングとできないタイミングを決める。
  • ノードのアップグレード戦略を構成し、ノードで実行されるワークロードに応じてスピードとリスク許容度のバランスを取る。

詳細については、ロールアウトの順序付けが他のアップグレード機能と連動する仕組みをご覧ください。

ロールアウト シーケンスの管理

ロールアウト シーケンスを管理するには、次のような基本的な操作を行います。

  • ロールアウト シーケンスを一覧表示する
  • ロールアウト シーケンスを記述する

また、ロールアウト シーケンスの変更や、ロールアウト シーケンス内のクラスタの無視などのアクションを実行することもできます。これらのアクションについては、以降のサブセクションで説明します。

ロールアウト シーケンス全体ではなく、1 つのバージョンのロールアウトを管理する方法については、前のセクションのロールアウトの管理をご覧ください。

ロールアウト シーケンスでクラスタを無視する

デフォルトでは、ロールアウト シーケンスのフリートに属するクラスタは、ロールアウト シーケンスの一部としてアップグレードされます。クラスタを特定のステージに追加できます。また、フリート内にあり、ラベルが付けられていないクラスタは、まとめてアップグレードされます。

ただし、ロールアウト シーケンスに含めないクラスタがある場合は、ラベルを付けることで、GKE が新しいバージョンをロールアウトするときにそのクラスタを無視するようにできます。たとえば、特定のクラスタをアップグレードする前に追加の時間が必要な場合、この操作が必要になることがあります。ロールアウト シーケンスで 1 つ以上のクラスタを無視できます。

ロールアウト シーケンスでクラスタを無視すると、GKE は新しいバージョンのロールアウト時にそのクラスタを考慮せず、クラスタの自動アップグレードを実行しません。ただし、サポート終了時の自動アップグレードや、90 日間アップグレードされていないコントロール プレーンの自動アップグレードなどの必須の自動アップグレードは除きます。

ロールアウト シーケンスでクラスタを無視するには、ロールアウト シーケンスでクラスタを無視するをご覧ください。

ロールアウト シーケンスの変更

既存のロールアウト シーケンスでロールアウトの進行方法を変更する場合は、次の 2 つの方法のいずれかでシーケンスを変更できます。

  • シーケンスを定義した YAML 構成ファイルを編集して、ロールアウト シーケンスを変更します。
  • シーケンス内のクラスタを変更します。

ロールアウト シーケンスを変更すると、次のようになります。

  • ロールアウト シーケンスでステージの追加、ステージの削除、ステージの順序の変更、ステージの編集(ステージのプロジェクト ID やラベルセレクタの変更など)を行うと、GKE はすべてのアクティブなロールアウトをキャンセルします。
  • ステージのソーク時間を変更しても、GKE はアクティブなロールアウトをキャンセルしません。

ロールアウト シーケンスを変更するには、ロールアウト シーケンスを変更するをご覧ください。

クラスタを順番に変更すると、次のようになります。

  • フリートからクラスタを削除してロールアウト シーケンスからクラスタを削除しても、アクティブなロールアウトは続行されます。GKE は、シーケンスに登録されていないクラスタの一般的な手順に基づいて、クラスタを自動的にアップグレードできます。
  • ロールアウト シーケンスでクラスタをフリートに追加すると、GKE は、追加したステージをまだ通過していないアクティブなロールアウトの一部として、このクラスタをアップグレードします。ただし、ロールアウトのステージが完了している場合、GKE はそのロールアウトでクラスタをアップグレードしません。
  • ロールアウト シーケンス構成を編集せずにクラスタを別のステージに移動すると、クラスタを移動するステージが完了しているかどうかに応じて、次のようになります。

    • ロールアウトがすでに完了しているステージにクラスタを移動しても、GKE はそのロールアウトでクラスタをアップグレードしません。
    • ロールアウトですでにアップグレードされたクラスタを、未完了の後のステージに移動すると、GKE はそのクラスタを無視し、ロールアウトの進行を中断しません。

シーケンス内のクラスタを変更するには、 Google Cloud のクラスタをフリートに登録するをご覧ください。

制限事項

カスタム ステージでロールアウト シーケンスを使用してクラスタをアップグレードする場合は、次の制限が適用されます。

  • Google Cloud コンソールを使用して、カスタム ステージを含むロールアウト シーケンスを作成または変更することはできません。ただし、コンソールを使用してロールアウトをモニタリングできます(プレビュー)。
  • ロールアウト シーケンスがフリートを参照する場合は、フリート全体を含める必要があります。この制約は、label-selector を使用してフリートのクラスタのサブセットのみをターゲットとするステージを定義する場合(段階的なデプロイなど)、同じフリートの残りのすべてのクラスタを含む後続の「キャッチオール」ステージも定義する必要があることを意味します。このキャッチオール ステージは同じフリートをターゲットにしますが、label-selector は含まれません。これにより、シーケンスの前のステージで選択されなかったすべてのクラスタが自動的に含まれます。
  • ロールアウト中にシーケンスを変更すると、特に参加しているクラスタに影響する変更を行うと、GKE は既存のすべてのロールアウトを直ちにキャンセルします。シーケンスのソーク時間のみを変更した場合、GKE はロールアウトをキャンセルしません。
  • ステージは最大 1 つのフリートを参照できます。1 つのステージに複数のフリートを配置することはできません。
  • 1 つのフリートは、1 つのロールアウト シーケンスでのみ参照できます。2 つのロールアウト シーケンスで同じフリートを参照することはできません。
  • 高速パッチ自動アップグレードを使用するロールアウト シーケンスでクラスタをアップグレードすることはできません。
  • 最大 15 ステージのロールアウト シーケンスを作成できます。
  • フリートには最大 250 個のクラスタを含めることができます。軽量メンバーシップを持つクラスタの場合、フリート内の最大 2,000 個のクラスタの割り当ての増加をリクエストできます。詳細については、割り当てと上限をご覧ください。
  • すべてのステージで、シーケンスあたりの最大ソーク時間を最大 90 日に構成できます。

既知の問題

このセクションでは、カスタム ステージを使用したロールアウト シーケンスの既知の問題について説明します。

  • ロールアウト シーケンスのステージにクラスタが含まれていない場合、そのステージはスキップされますが、そのステージに定義されたソーク時間は、ロールアウトが次のステージに進む前に経過します。

次のステップ