カナリア デプロイ戦略を使用する

このドキュメントでは、カナリア デプロイ戦略を構成および使用する方法について説明します。

カナリア デプロイとは

カナリア デプロイとは、すでにデプロイされているバージョンと新しいバージョンの間でトラフィックを分割するアプリケーションの段階的なロールアウトです。完全にロールアウトする前にユーザーのサブセットにロールアウトします。

サポート対象のターゲット タイプ

Cloud Deploy のカナリア デプロイは、次のすべてのターゲット タイプをサポートしています。

• Google Kubernetes Engine
• Cloud Run（サービスのみ。ジョブは対象外。）
• GKE Enterprise

Canary 環境は、マルチターゲットでも機能します。

カナリア デプロイ戦略を使用する理由

カナリア デプロイを使用すると、アプリケーションを部分的にリリースできます。これにより、新しいバージョンのアプリケーションをすべてのユーザーに提供する前に、その信頼性を確認できます。

たとえば、GKE または GKE Enterprise にデプロイする場合は、新しいバージョンのアプリケーションを限定された数の Pod にデプロイします。古いバージョンは引き続き実行されますが、より多くのトラフィックが新しい Pod に送信されます。

Cloud Run にデプロイする場合、Cloud Run 自体が、構成した割合に応じて古いリビジョンと新しいリビジョン間でトラフィックを分割します。

カナリアの種類

Cloud Deploy では、次のタイプのカナリア デプロイを構成できます。

• 自動

  自動カナリア デプロイでは、段階的なデプロイを表す一連の割合で Cloud Deploy を構成します。Cloud Deploy は、古いバージョンと新しいバージョンの間でトラフィックの割合を分割するために、追加のオペレーションを実行します。

• カスタム自動

  カスタム自動カナリアの場合、次の情報を指定できます。

  • フェーズ名
  • 目標の割合
  • フェーズに使用する Skaffold プロファイル
  • 確認ジョブを含めるかどうか
  • デプロイ前ジョブ、デプロイ後ジョブ、またはその両方を含めるかどうか

  ただし、トラフィック バランシング情報を指定する必要はありません。Cloud Deploy が必要なリソースを作成します。

• カスタム

  カスタム カナリアでは、以下のような各カナリア フェーズを個別に構成します。

  • フェーズ名
  • 目標の割合
  • フェーズに使用する Skaffold プロファイル
  • 確認ジョブを含めるかどうか
  • デプロイ前ジョブ、デプロイ後ジョブ、またはその両方を含めるかどうか

  さらに、完全なカスタム カナリアの場合、こちらで説明されているように、すべてのトラフィック バランシング構成を指定します。

カナリア デプロイのフェーズ

カナリア デプロイのリリースを作成すると、カナリアの増分ごとにフェーズが作成され、100% の最終的な stable フェーズが作成されます。

たとえば、25%、50%、75% の増分のカナリアを構成した場合、ロールアウトには次のフェーズがあります。

• canary-25
• canary-50
• canary-75
• stable

ロールアウト フェーズ、ジョブ、ジョブ実行の詳細については、ロールアウトを管理するをご覧ください。

自動カナリアまたはカスタム自動カナリアの動作

カナリア デプロイをサポートするために、Cloud Deploy には Kubernetes マニフェストまたは Cloud Run サービス構成のレンダリング時に特別な処理手順が含まれています。

カナリア デプロイのフェーズ間の違いを確認するには、リリース インスペクタでフェーズごとのレンダリングされたマニフェストの変更を確認します。これは、ロールアウトが開始される前でも行えます。また、並行デプロイを使用している場合は、各子のレンダリングされたマニフェストを検査することもできます。

カナリア デプロイを構成する

このセクションでは、カナリア デプロイ用のデリバリー パイプラインとターゲットを構成する方法について説明します。

ここで説明する手順には、カナリア構成に固有のもののみが含まれています。デプロイ パイプラインの構成と実行に関する一般的な手順については、アプリケーションをデプロイするをご覧ください。

必要な権限があることを確認してください

Cloud Deploy の使用に必要な他の Identity and Access Management 権限に加えて、カナリア デプロイに必要な追加アクションを実行するには、次の権限が必要です。

• clouddeploy.rollouts.advance
• clouddeploy.rollouts.ignoreJob
• clouddeploy.rollouts.cancel
• clouddeploy.rollouts.retryJob
• clouddeploy.jobRuns.get
• clouddeploy.jobRuns.list
• clouddeploy.jobRuns.terminate

これらの権限を含む使用可能なロールの詳細については、IAM のロールと権限をご覧ください。

skaffold.yaml を準備する

標準のデプロイと同様に、カナリアには skaffold.yaml ファイルが必要です。このファイルには、マニフェストとサービス定義のレンダリングとデプロイ方法を定義します。

カナリア デプロイ用に作成する skaffold.yaml には、標準デプロイに必要なもの以外に特別な要件はありません。

マニフェストまたはサービス定義を準備する

標準のデプロイと同様に、カナリアには Kubernetes マニフェストまたは Cloud Run サービス定義が必要です。

自動カナリアを構成する

次の手順は、Cloud Run、GKE、GKE Enterprise のサービスベースのネットワーキング ターゲット向けです。GKE または GKE Enterprise で Kubernetes Gateway API を使用している場合は、こちらのドキュメントをご覧ください。

自動カナリアは、デリバリー パイプラインの定義で構成します。

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              podSelectorLabel: "LABEL"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

カスタム カナリアを設定する

Cloud Deploy が提供する自動化に完全に依存する代わりに、カナリアを手動で構成することもできます。カスタム カナリア構成では、デリバリー パイプラインの定義で次のものを指定します。

• ロールアウト フェーズの名前

  完全に自動化されたカナリアでは、Cloud Deploy がフェーズに名前を付けます（canary-25、canary-75、stable など）。ただし、カスタム カナリアでは、このカナリア ステージのすべてのフェーズで一意であり、リソース名の制限を満たす限り、各フェーズに任意の名前を付けることができます。ただし、最終フェーズ（100%）の名前は stable にする必要があります。

• 各フェーズの割合の目標

  各フェーズで割合を個別に指定します。

• フェーズに使用する Skaffold プロファイル

  フェーズごとに個別の Skaffold プロファイルを使用するか、同じプロファイルを使用するか、または組み合わせて使用できます。プロファイルは、それぞれ異なる Kubernetes マニフェストや Cloud Run サービス定義を使用できます。特定のフェーズに複数のプロファイルを使用することもできます。Cloud Deploy はこれらを組み合わせます。

• そのフェーズの確認ジョブがあるかどうか

  確認を有効にする場合は、確認用に skaffold.yaml も構成する必要があるので注意してください。

• フェーズのデプロイ前ジョブまたはデプロイ後ジョブがあるかどうか

  デプロイ前ジョブまたはデプロイ後ジョブを有効にする場合は、それらのジョブの skaffold.yaml を構成する必要があります。

カスタム カナリアでは、すべてのターゲット タイプがサポートされています。

カスタム カナリアの構成要素

次の YAML は、完全にカスタムのカナリアのデプロイのフェーズ構成を示しています。

strategy:
  canary:
    # Custom configuration for each canary phase
    customCanaryDeployment:
      phaseConfigs:
      - phaseId: "PHASE1_NAME"
        percentage: PERCENTAGE1
        profiles: [ "PROFILE_NAME" ]
        verify: true | false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"
      - …
      - phaseId: "stable"
        percentage: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        verify: true|false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"

この YAML の内容は以下のとおりです。

• PHASE1_NAME

  フェーズの名前です。各フェーズ名は一意である必要があります。

• [ "PROFILE_NAME" ]

  フェーズに使用するプロファイルの名前です。フェーズごとに同じプロファイル、フェーズごとに異なるプロファイル、または任意の組み合わせで使用することもできます。また、複数のプロファイルを指定することもできます。Cloud Deploy では、指定したすべてのプロファイルと、ステージ全体で使用されるプロファイルまたはマニフェストを使用します。

• stable

  最終フェーズの名前は stable にする必要があります。

• PERCENTAGE1

  最初のフェーズにデプロイする割合です。各フェーズは一意の割合値を持つ必要があり、その値は全体の割合である必要があります（たとえば、10.5 ではありません）。フェーズは昇順である必要があります。

• verify: true|false

  このフェーズの確認ジョブを含めるかどうかを Cloud Deploy に指示します。確認を使用する各フェーズで、Skaffold は、そのフェーズのレンダリングとデプロイに指定された確認と同じプロファイルを使用します。

• PREDEPLOY_ACTION

  デプロイ前に実行するカスタム アクションを定義するために skaffold.yaml で使用した ACTION_NAME と同じです。

• POSTDEPLOY_ACTION

  デプロイ後に実行するカスタム アクションを定義するために skaffold.yaml で使用した ACTION_NAME と同じです。

最終フェーズの割合は 100 にする必要があります。フェーズは、この ​customCanaryDeployment スタンザで構成した順序に従って実行されますが、割合の値が昇順でない場合は、デリバリー パイプラインを登録するコマンドはエラーで失敗します。

カスタム カナリアの構成には runtimeConfig スタンザが含まれていないことに注意してください。runtimeConfig を含めると、カスタム自動カナリアと見なされます。

カスタム自動カナリアを設定する

カスタム自動カナリアはカスタム カナリアに類似しています。カスタム フェーズ名、割合値、Skaffold プロファイル、検証ジョブ、デプロイ前ジョブ、デプロイ後ジョブで個別のカナリア フェーズを指定し、ジョブを検証するためです。しかし、カスタム カナリアでは、トラフィック割り当てを定義する構成を指定しません。これは Cloud Deploy により自動的に行われます。ただし、各ステージで使用される Skaffold プロファイルを指定します。

カスタム自動カナリアを構成するには、ここに示すように runtimeConfig スタンザを含め、ここに示すように customCanaryDeployment スタンザを含めます。

Kubernetes Gateway API サービス メッシュを使用してカナリア デプロイを構成する

Cloud Deploy のカナリア デプロイを使用して、アプリケーションを Kubernetes サービスベースのネットワーキングにデプロイすることができますが、代替は、Kubernetes の Gateway API サービス メッシュを使用することです。 このセクションでは、その方法について説明します。

Gateway API は、Istio またはサポートされている実装で使用できます。

1. Gateway API リソースを設定します。

   • Istio の使用

   • GKE Gateway コントローラ

   これらは一例にすぎません。

2. リリースの作成時に Cloud Deploy に提供した Kubernetes マニフェストに、次の内容を含めます。

   • Gateway リソースを参照する HTTPRoute

   • A. Deployment

   • サービス

3. デリバリー パイプラインと、カナリア デプロイするターゲットを構成します。

   • ターゲットの構成は、他のターゲットと同じです。

   • 特定のターゲットの進行シーケンスの配信パイプライン構成には、Kubernetes Gateway API HTTPRoute 構成と Deployment と Service を参照する gatewayServiceMesh スタンザが含まれています。

     strategy:
      canary:
        runtimeConfig:
          kubernetes:
            gatewayServiceMesh:
              httpRoute: "ROUTE"
              service: "SERVICE"
              deployment: "DEPLOYMENT"
              routeUpdateWaitTime: "WAIT_TIME"
              podSelectorLabel: "LABEL"
        canaryDeployment:
          percentages:
          - 50
     

     ここで...

     • ROUTE は、目的のルーティング動作を定義する httpRoute 構成です。

     • SERVICE は、Cloud Deploy が GKE と GKE Enterprise へのカナリア デプロイに必要とする Service の構成です。

     • DEPLOYMENT は、Cloud Deploy が GKE と GKE Enterprise へのカナリア デプロイに必要とする Deployment の構成です。

     • WAIT_TIME は、リクエストのドロップを回避するために HTTPRoute リソースへの変更の伝播が完了するまで Cloud Deploy が待機する時間です。例: routeUpdateWaitTime: 60s。

       Istio を使用せずに Gateway API を使用してカナリアを実行し、Gateway API が Google Cloud ロードバランサに接続されている場合は、カナリア インスタンスをスケールダウンすると、少量のトラフィックが失われる可能性があります。この動作が発生した場合は、この設定を構成できます。

     • LABEL は Pod セレクタラベルです。これは、マニフェストで定義されている Kubernetes Service と Deployment のラベルセレクタと一致する必要があります。PIN の作成は省略することもできます。デフォルトは app です。

カナリア デプロイ戦略で並列デプロイを使用する

カナリア デプロイは、並列デプロイを使用して実行できます。つまり、段階的にデプロイするターゲットは、2 つ以上の子ターゲットで構成できます。たとえば、同時に、別々のリージョンのクラスタに段階的にデプロイできます。

並列カナリアと単一ターゲット カナリアの違い

• 単一ターゲット カナリアのデプロイと同様に、GKE ターゲットにデプロイする場合は、マニフェストに Kubernetes Deployment 構成と Kubernetes Service 構成が必要です。

• 単一ターゲット カナリアのデプロイと同様に、デリバリー パイプラインの構成には、該当するステージのステージ定義内に strategy.canary スタンザを含める必要があります。

• また、マルチターゲットを構成し、そのマルチターゲット参照を子ターゲットに構成する必要があります。

• リリースを作成すると、コントローラのロールアウトと子ロールアウトが作成されます。

  両方のタイプのロールアウト（コントローラと子）には、構成されているカナリア率ごとに個別のフェーズstableとカナリア 100% のフェーズがあります。

• 子ロールアウトを進めることはできません。

  コントローラのロールアウトのみを進められます。コントローラのロールアウトを次のステージに進めると、子のロールアウトも Cloud Deploy によって次に進められます。

• コントローラのロールアウトで、失敗したジョブを再試行することはできません。

  ジョブを再試行できるのは、子ロールアウトでのみです。

• コントローラのロールアウトで失敗したジョブを無視することはできません。

  失敗したジョブを無視できるのは、子ロールアウトのみです。

• コントローラのロールアウトをキャンセルすることはできますが、子ロールアウトをキャンセルすることはできません。

• ジョブ実行を終了できるのは、コントローラのロールアウトではなく、子ロールアウトでのみです。

カナリアで並列ロールアウトが失敗した場合の対処方法

子ロールアウトが失敗すると、子ロールアウトの状況に応じて、コントローラのロールアウトが異なる状態に移行することがあります。

• 1 つ以上の子ロールアウトが失敗しても、1 つ以上の子ロールアウトが IN_PROGRESS のままである場合、コントローラのロールアウトは IN_PROGRESS のままになります。

• 1 つ以上の子ロールアウトが失敗したが、少なくとも 1 つの子ロールアウトが成功した場合、現在のフェーズ後にフェーズが残っている場合、コントローラのロールアウトは HALTED です。

  これが stable フェーズの場合、コントローラのロールアウトは FAILED です。

  HALTED を使用すると、失敗した子ロールアウト内で失敗したジョブを無視、再試行、または コントローラのロールアウトをキャンセルし、子ロールアウトに対してそれ以上の操作を禁止します。

• 子ロールアウトの失敗によりコントローラのロールアウトが HALTED 状態にあり、子ロールアウトで失敗したジョブを無視すると、コントローラのロールアウトは IN_PROGRESS 状態に戻ります。

HTTPRoute を別のクラスタにデプロイする

Gateway API サービス メッシュを使用してカナリアを構成している場合は、HTTPRoute をデプロイするターゲット以外の代替クラスタを指定できます。

これを行うには、カナリア戦略構成で routeDestinations スタンザを使用して HTTPRoute の宛先クラスタまたはクラスタを特定し、ブール値設定を使用して Service を同じターゲット外のクラスタに伝播します。ターゲット構成に associatedEntities スタンザを作成して、クラスタを識別します。

1. ターゲットに associatedEntities を構成します。

   各エンティティは、Cloud Deploy が HTTPRoute と、必要に応じて Kubernetes Service をデプロイするクラスタです。ターゲット定義に associatedEntities スタンザを含めます。

   associatedEntities:
     [KEY]:
       gkeClusters:
       - cluster: [PATH]
         internalIp: [true|false]
         proxyUrl:
   

   ここで

   • KEY は、この関連エンティティのグループの任意の名前です。この名前は、カナリア構成の routeDestinations のエンティティを参照するために使用します。

   • PATH は、HTTPRoute（必要に応じて Service）がデプロイされる GKE クラスタを識別するリソースパスです。

   • internalIp は、クラスタに内部 IP とパブリック IP の両方が構成されている場合に、内部 IP（プライベート IP）を使用するかどうかを示します。デフォルトは false です。

   internalIp の有無にかかわらず、任意の数のクラスタを含めることができます。

2. カナリア構成ファイルで routeDestinations を構成します。

   各ルートの宛先は associatedEntities スタンザを参照し、Service を代替クラスタにもデプロイするかどうかを示します。カナリア構成の gatewayServiceMesh スタンザ内に次のコードを追加します。

   routeDestinations:
     destinationIds: ["KEY"]
     propagateService: [true|false]
   

   ここで

   • KEY は、ターゲットの associatedEntities で構成した名前です。この名前を使用して、カナリア構成の routeDestinations のエンティティを参照します。

     値 @self を指定して、関連付けられたデスティネーションに加えて、HTTPRoute をターゲット クラスタにデプロイすることもできます。

   • propagateService は、HTTPRoute に加えて、関連するクラスタに Service をデプロイするかどうかを示します。デフォルト値は false です。

構成されたカナリアを実行する

カナリア デプロイを実行するには:

1. 構成したデリバリー パイプラインとターゲットを登録します。

   gcloud deploy apply --file=PIPELINE
   

   配信パイプラインには、選択したランタイムの自動またはカスタムのカナリア構成が含まれています。

   このコマンドは、ターゲットが同じファイルで定義されているか、すでに登録されていることを前提としています。登録されていない場合は、ターゲットも登録してください。

2. リリースを作成する:

   gcloud deploy releases create RELEASE_NAME \
                                 --delivery-pipeline=PIPELINE_NAME \
                                 --region=REGION
   

   PIPELINE_NAME で識別されるデリバリー パイプラインには、このドキュメントで説明する自動カナリアまたはカスタム カナリアの構成が含まれています。

3. カナリアを進める:

   gcloud CLI

   gcloud deploy rollouts advance ROLLOUT_NAME \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --region=REGION
   

   ここで

   ROLLOUT_NAME は、次のフェーズに進める現在のロールアウトの名前です。

   RELEASE_NAME は、このロールアウトが含まれるリリースの名前です。

   PIPELINE_NAME は、このリリースのデプロイを管理するために使用するデリバリー パイプラインの名前です。

   REGION は、リリースが作成されたリージョンの名前です（例: us-central1）。必須入力項目です。

   gcloud deploy rollouts advance コマンドの詳細については、Google Cloud SDK リファレンスをご覧ください。

   Google Cloud コンソール

   1. [デリバリー パイプライン] ページを開く

   2. デリバリー パイプラインのリストに表示されているパイプラインをクリックします。

      デリバリー パイプラインの詳細ページには、デリバリー パイプラインの進行状況がグラフィカルに表示されます。

   3. [ロールアウト] タブの [デリバリー パイプラインの詳細] で、ロールアウトの名前をクリックします。

      そのロールアウトのロールアウトの詳細ページが表示されます。

      

      この例では、ロールアウトに canary-50 フェーズと stable フェーズがあります。ロールアウトには、より多くのフェーズまたは異なるフェーズが含まれる場合があります。

   4. [ロールアウトを進める] をクリックします。

      ロールアウトを次のフェーズに進めます。

スキップされるフェーズ

カナリアをデプロイするときに、アプリケーションがそのランタイムにデプロイされていない場合、Cloud Deploy はカナリア フェーズをスキップして安定フェーズを実行します。これが起こる理由については、初回にフェーズがスキップされるをご覧ください。

次のステップ

• カナリア デプロイのクイックスタートを試す。

• カナリア ロールアウトのライフサイクルを管理する方法をご覧ください。

• 並列デプロイの詳細を確認する。