使用初期測試部署策略

本文件說明如何設定及使用 Canary 部署策略。

什麼是初期測試部署？

初期測試部署是應用程式的漸進式推出作業，可在已部署的版本和新版本之間分割流量，先向部分使用者推出，再全面推出。

支援的目標類型

Cloud Deploy 中的初期測試部署支援所有目標類型，包括：

• Google Kubernetes Engine
• Cloud Run (僅限服務，不含作業)。
• GKE Enterprise

Canary 也支援多目標。

為什麼要採用初期測試部署策略？

您可以透過初期測試部署，發布部分應用程式。這樣一來，您就能確保應用程式的新版本可靠，再提供給所有使用者。

舉例來說，如果您要部署至 GKE 或 GKE Enterprise，就會將新版應用程式部署至數量有限的 Pod。舊版會繼續執行，但更多流量會傳送至新 Pod。

如果您要部署至 Cloud Run，Cloud Run 會根據您設定的百分比，在舊版和新版之間拆分流量。

可用來測試的類型

Cloud Deploy 可讓您設定下列類型的 Canary 部署：

• 自動

  使用自動化可疑版本部署功能時，您可以使用一系列百分比來設定 Cloud Deploy，以表示逐步部署。Cloud Deploy 會代您執行其他作業，以便在舊版和新版之間分配流量百分比。

• 自訂自動

  針對自訂自動化 Canary，您可以提供下列資訊：

  • 階段名稱
  • 百分比目標
  • 要用於階段的 Skaffold 設定檔
  • 是否要納入驗證工作
  • 是否要加入前部署或後部署工作，或同時加入

  不過，您不需要提供流量平衡資訊，Cloud Deploy 會建立必要資源。

• 自訂

  使用自訂 Canary 測試時，您可以分別設定每個 Canary 測試階段，包括：

  • 階段名稱
  • 百分比目標
  • 要用於階段的 Skaffold 設定檔
  • 是否要納入驗證工作
  • 是否要加入前部署或後部署工作，或同時加入

  此外，如果是完全自訂的 Canary 實驗，您必須提供所有流量平衡設定，如這裡所述。

初期測試部署的階段

為 Canary 部署建立版本時，系統會為每個 Canary 增量建立階段，並加上 100% 的最終 stable 階段。

舉例來說，如果您將初期測試設定為 25%、50% 和 75% 的增量，則推出作業將包含以下階段：

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

如要進一步瞭解推出階段、工作和工作執行作業，請參閱管理推出作業。

自動或自訂自動化 Canary 期間的情況

為了支援 Canary 部署作業，Cloud Deploy 會在算繪 Kubernetes 資訊清單或 Cloud Run 服務設定時，加入特殊的處理步驟：

如要查看初期測試部署階段之間的差異，您可以在發布檢查器中查看各階段轉譯的資訊清單中的變更。即使在推出前也能這麼做。此外，如果您使用平行部署，也可以檢查每個子項的算繪資訊清單。

設定初期測試部署

本節說明如何設定 Canary 部署的提交管道和目標。

這裡的操作說明僅包含 Canary 設定的相關內容。部署應用程式文件提供設定及執行部署管道的一般操作說明。

請確認您具備必要權限

除了使用 Cloud Deploy 所需的其他身分和存取管理權限之外，您還需要下列權限，才能執行 Canary 部署作業可能需要的其他動作：

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

如要進一步瞭解哪些可用角色包含這些權限，請參閱「IAM 角色與權限」。

準備好「skaffold.yaml」

如同標準部署作業，您的 Canary 需要 skaffold.yaml 檔案，用於定義如何轉譯及部署資訊清單和服務定義。

您為 Canary 部署作業建立的 skaffold.yaml 除了標準部署作業所需的條件外，不需其他特殊要求。

準備資訊清單或服務定義

和標準部署一樣，您的 Canary 需要 Kubernetes 資訊清單或 Cloud Run 服務定義。

設定自動化初期測試

以下說明適用於 Cloud Run 和 GKE 和 GKE Enterprise 服務式網路目標。如果您使用 Kubernetes Gateway API 搭配 GKE 或 GKE Enterprise，請參閱這份說明文件。

您可以在推送管道定義中設定自動化初期測試：

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"

設定自訂初期測試

您可以手動設定 Canary，而非完全仰賴 Cloud Deploy 提供的自動化功能。使用自訂 Canary 設定時，您可以在發布管道定義中指定下列項目：

• 推出階段名稱

  在完全自動化的 Canary 中，Cloud Deploy 會為您命名各個階段 (例如 canary-25、canary-75、stable)。不過，您可以使用自訂 Canary 為每個階段命名，只要名稱在 Canary 階段的所有階段中不重複，且符合資源名稱限制即可。但最終 (100%) 階段名稱必須是 stable。

• 各階段的百分比目標

  分別為每個階段指定百分比。

• 要用於該階段的 Skaffold 設定檔

  您可以為每個階段使用不同的 Skaffold 設定檔，也可以使用相同的設定檔，或任意組合。每個設定檔可使用不同的 Kubernetes 資訊清單或 Cloud Run 服務定義。您也可以為特定階段使用多個設定檔。Cloud Deploy 會將這些項目合併。

• 是否有該階段的驗證工作

  請注意，如果您要啟用驗證功能，也必須設定 skaffold.yaml 進行驗證。

• 這個階段是否有前置部署或後置部署工作

  如果您要啟用前部署或後部署工作，請為這些工作設定 skaffold.yaml。

自訂 Canary 支援所有目標類型。

自訂初期測試設定元素

下列 YAML 檔案顯示完全自訂 Canary 部署階段的設定：

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 節中設定的順序執行階段，但如果百分比值不是依遞增順序排列，註冊提交管道的指令就會失敗，並顯示錯誤訊息。

請注意，自訂 Canary 的設定不包含 runtimeConfig 節。如果您加入 runtimeConfig，系統會將其視為自訂自動化初期測試。

設定自訂自動化初期測試

自訂自動化 Canary 與自訂 Canary 類似，因為您會指定個別 Canary 階段，並使用自訂階段名稱、百分比值、Skaffold 設定檔、驗證作業，以及部署前和部署後作業。不過，使用自訂初期測試時，您不需要提供定義流量分配的設定，因為 Cloud Deploy 會為您完成這項工作，但您仍需提供要用於各階段的 Skaffold 設定檔。

如要設定自訂自動化初期測試，請加入 runtimeConfig 節，如這裡所示，並加入 customCanaryDeployment 節，如這裡所示。

使用 Kubernetes Gateway API 服務網格設定 Canary 部署

雖然您可以使用 Cloud Deploy 的金絲雀部署作業，將應用程式部署至以 Kubernetes 服務為基礎的網路架構，但您也可以改用 Kubernetes Gateway API 服務中介。本節將說明如何執行這項操作。

您可以搭配 Istio 或任何支援的導入方式使用 Gateway API。

1. 設定 Gateway API 資源：

   • 使用 Istio

   • GKE Gateway 控制器

   這些只是範例。

2. 在您建立版本時提供給 Cloud Deploy 的 Kubernetes 資訊清單中，請加入下列項目：

   • 參照閘道資源的 HTTPRoute

   • 部署

   • 服務

3. 設定推送管道和要進行初期測試部署的目標：

   • 目標的設定與任何目標相同。

   • 在特定目標的進度序列中，提交管道設定包含 gatewayServiceMesh 節，可參照 Kubernetes Gateway API HTTPRoute 設定，以及部署和服務。

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

     其中...

     • ROUTE 是 httpRoute 設定，可定義所需的轉送行為。

     • SERVICE 是服務設定，Cloud Deploy 需要這項設定才能將 Canary 部署作業整合至 GKE 和 GKE Enterprise。

     • DEPLOYMENT 是部署設定，Cloud Deploy 會在 GKE 和 GKE Enterprise 上進行 Canary 部署時使用。

     • WAIT_TIME 是 Cloud Deploy 等待 HTTPRoute 資源變更完成傳播所需的時間，以免要求遭到捨棄。例如：routeUpdateWaitTime: 60s。

       如果您使用 Gateway API 執行 Canary 而未使用 Istio，且 Gateway API 已連線至 Google Cloud 負載平衡器，則在縮減 Canary 執行個體時，可能會遺失少量流量。如果您發現這項行為，可以設定這項設定。

     • LABEL 是 Pod 選取器標籤。這個標籤必須與資訊清單中定義的 Kubernetes 服務和部署作業中的標籤選取器相符。這不是必要的步驟。預設值為 app。

搭配初期測試部署策略使用並行部署

您可以使用平行部署功能執行初期測試部署作業。也就是說，您逐步部署的目標可以包含兩個以上的子目標。舉例來說，您可以同時逐步部署至不同區域的叢集。

並行 Canary 與單一目標 Canary 有何不同

• 如同單一目標 Canary 部署，如果您要部署至 GKE 目標，則需要在資訊清單中設定 Kubernetes 部署和 Kubernetes 服務。

• 如同單一目標初期測試部署作業，您必須在適用階段的階段定義中加入 strategy.canary 節，以便在管道設定中納入。

• 此外，您需要設定多部署目標，並設定多部署目標參照的子目標。

• 建立版本時，系統會建立控制器推出作業和子項推出作業。

  無論是控制器還是子項這兩種發布類型，都會為所有已設定的測試群組百分比設有個別階段，並為測試群組 100% 設有 stable 階段。

• 您無法推進子項推出作業。

  您只能推進控制器推出作業。當您將控制器推出作業推進至下一個階段時，Cloud Deploy 也會推進子項推出作業。

• 您無法重試控制器推出作業中的失敗工作。

  您只能在子項推出作業中重試工作。

• 您無法忽略控制器推出作業中的失敗工作。

  您只能忽略子項推出作業中的失敗工作。

• 您可以取消控制器推出作業，但無法取消子項推出作業。

• 您只能在子項推出作業下終止工作執行作業，而非控制器推出作業。

在金絲雀中並行推出失敗時該怎麼做

當子項推出作業失敗時，控制器推出作業可以轉換至不同的狀態，具體取決於子項推出作業的結果：

• 如果一或多項子項推出作業失敗，但至少有一項子項推出作業仍為 IN_PROGRESS，控制器推出作業仍為 IN_PROGRESS。

• 如果一或多項子項推出作業失敗，但至少有一個子項推出作業成功，且目前階段後還有更多階段，則控制器推出作業會變成 HALTED。

  如果這是 stable 階段，控制器推出作業就是 FAILED。

  HALTED 可讓您略過、重試失敗子項推出作業中的失敗工作，或是取消控制器推出作業，並防止對子項推出作業採取進一步行動。

• 如果控制器推出作業因子項推出作業失敗而處於 HALTED 狀態，且您略過子項推出作業中的失敗工作，控制器推出作業就會還原為 IN_PROGRESS 狀態。

將 HTTPRoute 部署至其他叢集

使用 Gateway API 服務網格設定 Canary 後，您可以指定其他非目標叢集，以便部署 HTTPRoute。

如要這麼做，您可以在 Canary 策略設定中使用 routeDestinations 節，識別 HTTPRoute 的目的地叢集或叢集，以及布林值設定，將服務傳播至相同的非目標叢集。您可以在目標設定中建立 associatedEntities 節，用於識別叢集。

1. 在目標上設定 associatedEntities。

   每個實體都是叢集，Cloud Deploy 會在其中部署 HTTPRoute，並視需要部署 Kubernetes 服務。在目標定義中加入 associatedEntities 節：

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

   其中：

   • KEY 是這組相關實體的任意名稱。您會使用這個名稱，在 Canary 設定中參照 routeDestinations 中的實體。

   • PATH 是資源路徑，可識別 HTTPRoute (以及選用的服務) 的部署位置。

   • dnsEndpoint 會指出在設定多個端點時，是否要使用叢集的 DNS 端點。預設值為 false。

   • internalIp 會指出是否要使用叢集的內部 IP (私人 IP)，如果已設定多個端點。預設值為 false。

   您可以納入任意數量的叢集，不論是否包含 internalIp 皆可。

2. 在初期測試版本設定中設定 routeDestinations。

   每個路徑目的地都會參照 associatedEntities 節，並指出是否要將服務部署至其他叢集。在 Canary 設定檔的 gatewayServiceMesh 段落中加入以下內容：

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

   其中：

   • KEY 是您在 associatedEntities 中指定目標時設定的名稱。使用這個名稱，在 Canary 設定中參照 routeDestinations 中的實體。

     您也可以提供 @self 值，除了相關聯的目的地之外，還可將 HTTPRoute 部署至目標叢集。

   • propagateService 表示除了 HTTPRoute 之外，您是否也想將服務部署至相關聯的叢集。預設值為 false。

執行已設定的初期測試

如要執行初期測試部署，請按照下列步驟操作：

1. 註冊已設定的推送管道和目標。

   gcloud deploy apply --file=PIPELINE
   

   推送管道會根據您選擇的執行階段，納入自動或自訂 Canary 設定。

   這個指令假設目標是在同一個檔案中定義，或已註冊。如果沒有，請務必註冊目標。

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. 按一下推送管道清單中顯示的管道。

      「Delivery pipeline details」頁面會以圖表呈現推送管道的進度。

   3. 在「推出作業」分頁的「提交管道詳細資料」下方，按一下推出作業的名稱。

      系統會顯示該推出作業的詳細資料頁面。

      

      請注意，在這個範例中，發布作業包含 canary-50 階段和 stable 階段。你的推行計畫可能會有更多或不同的階段。

   4. 按一下「進展至下一個推出階段」。

      推出作業會推進至下一個階段。

略過的階段

如果您部署 Canary 版本，但應用程式尚未部署至該執行階段，Cloud Deploy 會略過 Canary 階段，並執行穩定版階段。請參閱「第一次略過階段」，瞭解發生這種情況的原因。

後續步驟

• 請試試初期測試部署快速入門導覽課程。

• 瞭解如何管理 Canary 的發布作業生命週期。

• 進一步瞭解平行部署。