このページは Cloud Translation API によって翻訳されました。

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

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

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

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

Deployment と Service の参照に加えて、Service を参照する backendRefs ルールを含む HTTPRoute リソースを指定します。
Cloud Deploy は、元の Deployment の名前に -canary を加えた名前の新しい Deployment と、元の Service の名前に -canary を加えた名前の新しい Service を作成します。

Secret、ConfigMap、HorizontalPodAutoscaler もコピーされ、-canary で名前が変更されます。
カナリアフェーズごとに、Cloud Deploy は HTTPRoute を変更し、元の Deployment の Pod とカナリアデプロイの Pod の間の重みを、そのフェーズの割合に基づいて更新します。

HTTPRoute リソースへの変更の伝播には遅延が生じる可能性があるため、構成に routeUpdateWaitTime プロパティを含めることで、システムがこの伝播に要する一定の時間待機するようにできます。
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 でオーケストレートされる、正確な割合ベースのトラフィック分割を行います。

Gateway API リソースを設定する: Gateway と基盤となるサービスメッシュ（Istio など）が、Istio）または Gateway コントローラがクラスタに正しく構成されている。
- Istio の使用
- GKE Gateway コントローラ
リリースを作成したときに Cloud Deploy に提供された Kubernetes マニフェストに、次の内容を含めます。
- Gateway リソースを参照する HTTPRoute
- A. Deployment
- サービス
デリバリーパイプラインと、カナリアデプロイするターゲットを構成します。
- ターゲットの構成は、他のターゲットと同じです。
- 特定のターゲットの進行シーケンスの配信パイプライン構成には、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 です。

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

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

ロールアウトフェーズ名

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

フェーズごとに割合を個別に指定します。
フェーズで使用する Skaffold プロファイル

フェーズごとに個別の Skaffold プロファイルを使用することも、同じプロファイルを使用することも、任意の組み合わせを使用することもできます。プロファイルは、それぞれ異なる Kubernetes マニフェストを使用できます。特定のフェーズに複数のプロファイルを使用することもできます。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 スタンザで構成した順序に従って実行されますが、割合の値が昇順でない場合は、デリバリーパイプラインを登録するコマンドはエラーで失敗します。

Gateway API カスタムカナリアの構成には runtimeConfig スタンザが含まれていません。runtimeConfig を含めると、カスタムサービスベースのカナリアと見なされます。

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

これにより、カスタムフェーズ定義（名前、割合、プロファイル、検証、フック）と、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 スタンザを作成します。

ターゲットで 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 の有無にかかわらず、任意の数のクラスタを含めることができます。
カナリア構成で routeDestinations を構成します。

各ルートの宛先は associatedEntities スタンザを参照し、Service を代替クラスタにもデプロイするかどうかを示します。カナリア構成の gatewayServiceMesh スタンザ内に次のコードを追加します。
```
routeDestinations:
  destinationIds: ["KEY"]
  propagateService: [true|false]
```
ここで
- KEY は、associatedEntities のターゲットで構成した名前です。この名前を使用して、カナリア構成の routeDestinations からエンティティを参照します。
  
  値 @self を指定して、関連付けられた宛先に加えて、ターゲットクラスタに HTTPRoute をデプロイすることもできます。
- propagateService は、HTTPRoute に加えて、関連付けられたクラスタに Service をデプロイするかどうかを示します。デフォルト値は false です。

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

パイプラインとターゲットを登録する: デリバリーパイプラインと GKE または GKE Enterprise ターゲット構成ファイルを適用します。
```
gcloud deploy apply --file=delivery-pipeline.yaml --region=REGION
gcloud deploy apply --file=gke-targets.yaml --region=REGION
```
配信パイプラインには、選択したランタイムの自動またはカスタムのカナリア構成が含まれます。

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


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

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

Gateway API ネットワーキングを使用した GKE と GKE Enterprise へのカナリア デプロイ コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

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

skaffold.yaml を準備する

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

自動カナリアを構成する

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

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