Gateway API ネットワーキングを使用した GKE と GKE Enterprise へのカナリア デプロイ

このドキュメントでは、カナリア デプロイを構成して使用し、Cloud Deploy と Kubernetes Gateway API サービス メッシュを使用してアプリケーションを GKE または GKE Enterprise にデプロイする方法について説明します。

カナリア デプロイは、アプリケーションの新しいバージョンの段階的なロールアウトです。アプリケーションのパフォーマンスをモニタリングしながら、新しいバージョンに送信されるトラフィックの割合を徐々に増やします。これにより、潜在的な問題を早期に検出し、ユーザーへの影響を最小限に抑えることができます。

Gateway API を使用した GKE と GKE Enterprise のカナリア デプロイの仕組み

1. Deployment と Service の参照に加えて、Service を参照する backendRefs ルールを含む HTTPRoute リソースを指定します。

2. Cloud Deploy は、元の Deployment の名前に -canary を加えた名前の新しい Deployment と、元の Service の名前に -canary を加えた名前の新しい Service を作成します。

   Secret、ConfigMap、HorizontalPodAutoscaler もコピーされ、-canary で名前が変更されます。

3. カナリア フェーズごとに、Cloud Deploy は HTTPRoute を変更し、元の Deployment の Pod とカナリア デプロイの Pod の間の重みを、そのフェーズの割合に基づいて更新します。

   HTTPRoute リソースへの変更の伝播には遅延が生じる可能性があるため、構成に routeUpdateWaitTime プロパティを含めることで、システムがこの伝播に要する一定の時間待機するようにできます。

4. stable フェーズでは、-canary Deployment がゼロにスケールダウンされ、元の Deployment が新しいリリースの Deployment を使用するように更新されます。

   また、HTTPRoute は指定した元の状態に戻ります。

   Cloud Deploy は、stable フェーズまで元の Deployment または Service を変更しません。

Cloud Deploy を使用すると、単一ステージまたは複数ステージで GKE と GKE Enterprise へのカナリア デプロイを構成できます。

ここでの手順には、カナリア構成に固有の内容のみが含まれています。ドキュメントの Google Kubernetes Engine クラスタにデプロイするには、デプロイ パイプラインを構成して実行するための一般的な手順が記載されています。

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

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 ファイルは、Kubernetes マニフェストのレンダリングとデプロイの方法を定義します。GKE/GKE Enterprise へのカナリア デプロイでは、マニフェストを正しく指し、必要なビルド アーティファクトを定義していることを確認します。skaffold.yaml 自体には、標準デプロイに必要な構成以外に、カナリア固有の特別な構成は必要ありません。Skaffold プロファイルを使用して、カスタム カナリア フェーズのさまざまなマニフェスト バリエーションを管理できます。

Kubernetes マニフェストを準備する

Kubernetes マニフェストには、Deployment リソースと Service リソースの両方を含める必要があります。Service は、Deployment によって管理される Pod のラベルと一致する selector を定義する必要があります。Cloud Deploy が検索するデフォルトのラベルは app ですが、これはパイプラインで構成できます。

Deployment と Service に加えて、マニフェストには、トラフィック分割用に構成され、Service と関連する Gateway を参照する HTTPRoute リソースを含める必要があります。

自動カナリアを構成する

Kubernetes Gateway API（Istio またはサポートされている実装）を使用して、メッシュ/ゲートウェイで管理され、Cloud Deploy でオーケストレートされる、正確な割合ベースのトラフィック分割を行います。

1. Gateway API リソースを設定する: Gateway と基盤となるサービス メッシュ（Istio など）が、Istio）または Gateway コントローラがクラスタに正しく構成されている。

   • 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 です。

カスタム自動カナリアを構成する

これにより、カスタム フェーズ定義（名前、割合、プロファイル、検証、フック）と、GKE または GKE Enterprise の Cloud Deploy の自動トラフィック管理が組み合わされます。フェーズはユーザーが定義しますが、Cloud Deploy は、割合と選択した runtimeConfig に基づいて基盤となるリソース操作を処理します。

これを構成するには、strategy.canary ブロック内に serviceNetworking を含む runtimeConfig セクションと customCanaryDeployment セクション（phaseConfigs を定義）の両方を含めます。Cloud Deploy は、指定された Skaffold プロファイルを使用してレンダリングを行いますが、runtimeConfig とフェーズの割合に従ってトラフィックを自動的に調整します。

serialPipeline:
  stages:
  - targetId: gke-prod
    profiles: []
    strategy:
      canary:
        # Include runtimeConfig for automatic traffic management
        runtimeConfig:
          kubernetes:
            gatewayServiceMesh:
              httpRoute: "my-route"
              service: "my-app"
              deployment: "my-deployment"  
        # Include customCanaryDeployment for phase customization
        customCanaryDeployment:
          phaseConfigs:
          - phaseId: "warmup"
            percentage: 10
            profiles: ["profile-a"] # Profile used for rendering this phase
            verify: true
          - phaseId: "scaling"
            percentage: 50
            profiles: ["profile-b"] # Different profile for this phase
            verify: true
          - phaseId: "stable"
            percentage: 100
            profiles: ["profile-b"] # Can reuse profiles
            verify: true

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

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

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

注: 関連エンティティを構成できるのは、Kubernetes Gateway API サービス メッシュを使用している場合のみです。

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

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

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

   ここで

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

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

   • dnsEndpoint は、複数のエンドポイントが構成されている場合に、クラスタの DNS エンドポイントを使用するかどうかを示します。デフォルトは false です。

   • internalIp は、複数のエンドポイントが構成されている場合に、クラスタの内部 IP（プライベート IP）を使用するかどうかを示します。デフォルトは false です。

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

2. カナリア構成で routeDestinations を構成します。

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

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

   ここで

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

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

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

GKE または GKE Enterprise のカナリアを実行する

1. パイプラインとターゲットを登録する: デリバリー パイプラインと GKE または GKE Enterprise ターゲット構成ファイルを適用します。

   
   gcloud deploy apply --file=delivery-pipeline.yaml --region=REGION
   gcloud deploy apply --file=gke-targets.yaml --region=REGION
   

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

2. リリースを作成する: イメージ名を指定してデプロイを開始します。

   
   gcloud deploy releases create RELEASE_NAME \
                                   --delivery-pipeline=PIPELINE_NAME \
                                   --region=REGION
     # e.g., --images=my-cloudrun-service=gcr.io/my-project/my-app:v1.1
     # Add --skaffold-file or --source if not using default Skaffold config discovery
   

   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 はカナリア フェーズをスキップして安定フェーズを実行します。この理由については、初回にフェーズがスキップされるをご覧ください。

次のステップ

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

• カナリアのロールアウトのライフサイクルを管理する方法を確認する。

• 詳しくは、並列デプロイをご覧ください。

• Cloud Deploy のデプロイ戦略の詳細を確認する。