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

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

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

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

サービスベースのネットワーキングを使用する GKE と GKE Enterprise でカナリアデプロイが機能する仕組み

Deployment リソース名と Service リソース名を指定します。
Cloud Deploy は、現在の Deployment の名前に -canary を加えた名前の Deployment リソースをもう 1 つ作成します。

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

Cloud Deploy は、現在の Deployment とカナリア Pod の Pod を選択するためにセレクタを調整する Service を変更します。

Cloud Deploy は、Pod のプロビジョニングセクションで説明されている計算に基づいて、カナリアに使用する Pod の数を計算します。この計算は、Pod のオーバープロビジョニングが有効か無効かによって異なります。

stable フェーズにスキップする場合、Cloud Deploy は Pod の照合に使用するラベルを追加するため、後続のカナリア実行で使用できます。

Cloud Deploy は、フェーズ固有の Pod の割合を含む Deployment を作成し、各フェーズで更新します。これは、Pod の数を元の Pod の数の割合として計算することで行われます。これにより、トラフィックの分割が不正確になる可能性があります。トラフィックを正確に分割する必要がある場合は、Gateway API を使用して実現できます。
stable フェーズでは、-canary Deployment がゼロにスケールダウンされ、元の Deployment が新しい Deployment に置き換えられます。

オーバープロビジョニングを無効にしない限り、Cloud Deploy は stable フェーズまで元の Deployment を変更しません。

Cloud Deploy は、リクエストされたカナリアの割合にできるだけ近い割合になるように Pod をプロビジョニングします。これは、Pod へのトラフィックではなく、Pod の数に基づきます。カナリアをトラフィックに基づいて行う場合は、Gateway API を使用する必要があります。

GKE ネットワークベースのカナリアの場合、Pod のオーバープロビジョニングを有効または無効にできます。以降のセクションでは、各カナリアフェーズのカナリアデプロイにプロビジョニングする Pod の数を Cloud Deploy がどのように計算するかについて説明します。

オーバープロビジョニングを有効にした Pod のプロビジョニング

オーバープロビジョニング（disablePodOverprovisioning: false）を有効にすると、既存のデプロイを実行している Pod の数に基づいて、必要なカナリア率を実行するのに十分な追加の Pod を Cloud Deploy で作成できます。次の式は、Pod のオーバープロビジョニングが有効になっている場合に、各カナリアフェーズのカナリアデプロイにプロビジョニングする Pod の数を Cloud Deploy がどのように計算するかを示しています。

math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))

この式では、現在のレプリカ数（このカナリアの前に存在する Pod の数）にフェーズのカナリア率を掛けて、その結果を（100 - カナリア率）で割ります。

たとえば、すでに Pod が 4 つあり、カナリアフェーズが 50% の場合、カナリア Pod の数は 4 になります。（100-percentage の結果は .50 として扱われる割合 100-50=50 として使用されます。）

Pod のオーバープロビジョニングはデフォルトの動作です。

オーバープロビジョニングを無効にした Pod のプロビジョニング

オーバープロビジョニング（disablePodOverprovisioning: true）を無効にして、Cloud Deploy がレプリカ数を増やさないようにすることができます。

次の式は、Pod のオーバープロビジョニングが無効になっている場合に、各カナリアフェーズのカナリアデプロイにおける Pod のプロビジョニングを Cloud Deploy がどのように計算するかを示しています。

math.Ceil( (ReplicaCountOfDeploymentOnCluster + ReplicaCountOfCanaryDeploymentOnCluster) * percentage)

この数式では、すでにカナリアフェーズが存在する場合にのみ ReplicaCountOfCanaryDeploymentOnCluster が存在します。これが最初のカナリアフェーズの場合、ReplicaCountOfCanaryDeploymentOnCluster はありません。

4 つの Pod から開始する場合、その数にカナリア率（50% または .5 など）を掛けて 2 を取得します。元の Deployment は 2 にスケールダウンされ、カナリア Deployment 用に 2 つの新しい Pod が作成されます。カナリアステージが 75% の場合、2（元の Deployment）+2（最初のカナリアステージ）*.75 で 3 個のカナリア Pod と元の Deployment を実行する 1 個のPod を取得します。

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 ですが、これはパイプラインで構成できます。

自動カナリアを構成する

標準の Kubernetes Service ネットワーキングを使用して、特定の GKE ステージまたは GKE Enterprise ステージの配信パイプライン定義内で自動カナリアを直接構成します。

パイプラインステージに、次のように strategy プロパティを含めます。

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"

この設定は以下のようなものです...

SERVICE_NAME は、マニフェストで定義されている Kubernetes Service の名前です。
DEPLOYMENT_NAME は、マニフェストで定義されている Kubernetes Deployment の名前です。
LABEL は Pod セレクタラベルです。これは、マニフェストで定義されている Kubernetes Service のラベルセレクタと一致している必要があります。これは省略することもできます。デフォルトは app です。
PERCENTAGES は、カナリア増分を表す割合値のカンマ区切りリストです（例: [5, 25, 50]）。

また、これには 100 は含まれません。デプロイの 100% がカナリアで想定され、stable フェーズで処理されるためです。
デプロイ検証（verify: true）を有効にできます。有効にすると、各フェーズで verify ジョブが有効になります。
PREDEPLOY_ACTION

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

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

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

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 スタンザで構成した順序に従って実行されますが、割合の値が昇順でない場合は、デリバリーパイプラインを登録するコマンドはエラーで失敗します。

カスタムカナリアの構成には 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:
            serviceNetworking:
              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

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

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

サービスベースのネットワーキングを使用する GKE と GKE Enterprise でカナリア デプロイが機能する仕組み

オーバープロビジョニングを有効にした Pod のプロビジョニング

オーバープロビジョニングを無効にした Pod のプロビジョニング

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

skaffold.yaml を準備する

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

自動カナリアを構成する

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

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