Cloud Service Mesh 和 Traffic Director 現已改名為 Cloud Service Mesh。詳情請參閱 Cloud Service Mesh 總覽。

本頁面由 Cloud Translation API 翻譯而成。

使用 Envoy 設定進階流量管理

這項設定適用於搶先體驗方案客戶，但我們不建議新 Cloud Service Mesh 使用者採用。詳情請參閱 Cloud Service Mesh 服務路由總覽。

本文說明如何為使用 Envoy 的 Cloud Service Mesh 部署設定進階流量管理功能。

事前準備

設定進階流量管理功能前，請先按照「準備使用 Envoy 設定 Cloud Service Mesh」中的指示操作，包括設定 Cloud Service Mesh 和您需要的任何虛擬機器 (VM) 主機或 Google Kubernetes Engine (GKE) 叢集。建立必要的Google Cloud 資源。

進階流量管理功能的可用性會因您選擇的要求通訊協定而異。您使用目標 HTTP 或 HTTPS Proxy、目標 gRPC Proxy 或目標 TCP Proxy 資源設定路由時，系統會設定這個通訊協定：

您可以使用目標 HTTP Proxy 和目標 HTTPS Proxy，享有本文所述的所有功能。
使用目標 gRPC 代理程式，您可以使用部分功能。
使用目標 TCP Proxy 時，無法使用進階流量管理功能。

詳情請參閱「Cloud Service Mesh 功能」和「進階流量管理」。如需端對端設定指南，請參閱「透過無 Proxy gRPC 服務設定進階流量管理」。

設定流量拆分

此處的操作說明假設情況如下：

您的 Cloud Service Mesh 部署作業有一個名為 review-url-map 的網址對應。
網址對應會將所有流量傳送到名為 review1 的預設後端服務。
您打算將 5% 的流量轉送至新版服務。該服務會在與後端服務 review2 相關聯的網路端點群組 (NEG) 中，以後端 VM 或端點執行。
不使用主機規則或路徑比對器。

如果您要將流量切割給網址對應未曾參照的新服務，請先將新服務新增至 weightedBackendServices，並為其指定 0 的權重。然後逐步提高指派給該服務的權重。

如要設定流量分配，請按照下列步驟操作：

主控台

前往 Google Cloud 控制台的「Cloud Service Mesh」頁面。

前往 Cloud Service Mesh
按一下「轉送規則對應關係」。
按一下「建立轉送規則對應關係」。
在「Create a routing rule map」(建立轉送規則對應關係) 頁面中，輸入「Name」(名稱)。
在「Protocol」選單中，選取「HTTP」。
選取現有的轉送規則。
在「轉送規則」下方，選取「進階主機、路徑和轉送規則」。
在「主機和路徑比對器」下方，按一下「新增主機和路徑比對器」。這會新增可設定用於分割流量的路徑比對工具。

在「路徑比對工具」欄位中新增下列設定：

    - defaultService: global/backendServices/review1
      name: matcher1
      routeRules:
      - priority: 2
        matchRules:
        - prefixMatch: ''
        routeAction:
         weightedBackendServices:
         - backendService: global/backendServices/review1
           weight: 95
         - backendService: global/backendServices/review2
           weight: 5

按一下 [完成]。
按一下 [儲存]。

新版本滿足需求後，您可以逐步調整兩項服務的權重，並最終將所有流量傳送至 review2。

gcloud

執行 gcloud export 指令，取得網址對應設定：

gcloud compute url-maps export review-url-map \
    --destination=review-url-map-config.yaml

在 review-url-map-config.yaml 檔案中新增下列部分：

     hostRules:
     - description: ''
      hosts:
       - '*'
     pathMatcher: matcher1
     pathMatchers:
     - defaultService: global/backendServices/review1
       name: matcher1
       routeRules:
       - priority: 2
         matchRules:
         - prefixMatch: ''
         routeAction:
          weightedBackendServices:
          - backendService: global/backendServices/review1
            weight: 95
          - backendService: global/backendServices/review2
            weight: 5

更新網址對應：

gcloud compute url-maps import review-url-map \
    --source=review-url-map-config.yaml

新版本滿足需求後，您可以逐步調整兩項服務的權重，並最終將所有流量傳送至 review2。

設定部分發布

使用部分部署程序 (有時稱為「初期測試」)，先向一小部分的伺服器發布新版軟體，然後再將新版發布至其他正式版伺服器。

部分版本會使用 weightedBackendServices。如要啟用部分版本，請將後端服務指定為測試或初期測試版服務，並為其指定低權重，例如 2 或 5。只將新軟體版本部署至這些伺服器。確認新版本沒有問題後，即可將其部署至其他服務。

如要啟用部分發布功能，請使用下列 YAML 程式碼範例：

pathMatchers:
     - defaultService: DEFAULT_SERVICE_URL
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: BACKEND_SERVICE_PARTIAL_URL
            weight: 2
          - backendService: BACKEND_SERVICE_URL
            weight: 98

DEFAULT_SERVICE_URL 是服務的預設網址。
BACKEND_SERVICE_PARTIAL_URL 是接收 2% 流量的後端服務網址。
BACKEND_SERVICE_URL 是接收 98% 流量的後端服務網址。

設定藍綠部署

藍綠部署是一種版本發布模式，可縮短將正式環境流量切換至服務新版本，或回復服務舊版本所需的時間。這些部署作業可讓兩個服務版本都提供正式版，並將流量從一個版本轉移至另一個版本。

藍綠部署會使用 weightedBackendServices。在下方的 YAML 範例中，SERVICE_BLUE_URL 的後端已完整部署目前的正式發布版本，SERVICE_GREEN_URL 的後端則已完整部署新版本。在範例中的設定中，GREEN 部署會接收 100% 的實際流量。如果發現問題，您可以反轉兩個部署的權重，這樣就能有效復原有問題的 GREEN 版本，並恢復已知良好的 BLUE 版本。在前述任一情況下，由於兩種版本都可接收流量，因此您可以迅速調整流量。

如要啟用藍/綠部署，請使用下列 YAML 程式碼範例：

pathMatchers:
     - defaultService: DEFAULT_SERVICE_URL
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: BACKEND_SERVICE_BLUE_URL
            weight: 0
          - backendService: BACKEND_SERVICE_GREEN_URL
            weight: 100

DEFAULT_SERVICE_URL 是服務的預設網址。
BACKEND_SERVICE_BLUE_URL 是未接收任何流量的後端服務網址。
BACKEND_SERVICE_GREEN_URL 是接收 100% 流量的後端服務網址。

設定流量鏡像

如要將流量導向至兩個不同的後端服務，以便偵錯或測試新服務，請使用流量鏡射。

在以下範例中，所有要求都會傳送至 SERVICE_URL 和 MIRROR_SERVICE_URL。不過，只有來自 SERVICE_URL 的回應會傳回用戶端。MIRROR_SERVICE_URL 不會對用戶端產生任何影響。

如要設定流量鏡像功能，請按照下列步驟操作：

主控台

前往 Google Cloud 控制台的「Cloud Service Mesh」頁面。

前往 Cloud Service Mesh
按一下「轉送規則對應關係」。
按一下「建立轉送規則對應關係」。
在「Create a routing rule map」(建立轉送規則對應關係) 頁面中，輸入「Name」(名稱)。
在「Protocol」清單中，選取「HTTP」。
選取現有的轉送規則。
在「轉送規則」下方，選取「進階主機、路徑和轉送規則」。
在「主機和路徑比對器」下方，按一下「新增主機和路徑比對器」。這會新增可設定為鏡像流量的路徑比對器。

在「路徑比對工具」欄位中新增下列設定：

    - defaultService: DEFAULT_SERVICE_URL
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: '/'
        routeAction:
         weightedBackendServices:
         - backendService: BACKEND_SERVICE_URL
           weight: 100
         requestMirrorPolicy:
           backendService: BACKEND_SERVICE_MIRROR_URL

DEFAULT_SERVICE_URL 是服務的預設網址。
BACKEND_SERVICE_URL 是鏡像後端的網址。
BACKEND_SERVICE_MIRROR_URL 是您要鏡像的後端服務網址。

按一下 [完成]。
按一下 [儲存]。

gcloud

執行 gcloud export 指令，取得網址對應設定：

gcloud compute url-maps export review-url-map \
    --destination=review-url-map-config.yaml

在 review-url-map-config.yaml 檔案中新增下列部分：

     hostRules:
     - description: ''
      hosts:
       - '*'
     pathMatcher: matcher1
     pathMatchers:
    - defaultService: DEFAULT_SERVICE_URL
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: '/'
        routeAction:
         weightedBackendServices:
         - backendService: BACKEND_SERVICE_URL
           weight: 100
         requestMirrorPolicy:
           backendService: BACKEND_SERVICE_MIRROR_URL

DEFAULT_SERVICE_URL 是服務的預設網址。
BACKEND_SERVICE_URL 是鏡像後端的網址。
BACKEND_SERVICE_MIRROR_URL 是您要鏡像的後端服務網址。

更新網址對應：

gcloud compute url-maps import review-url-map \
    --source=review-url-map-config.yaml

設定斷路機制

斷路器可讓您設定失敗門檻，避免用戶端要求造成後端過載。要求達到您設定的上限後，用戶端就會停止允許新連線或傳送其他要求，讓後端有時間復原。

因此，電路中斷會將錯誤傳回給用戶端，而非將後端過載，藉此防止連鎖性故障。這樣一來，系統就能同時提供部分流量，並有時間管理超載情況，例如透過自動調度資源功能增加容量，以便處理流量激增情形。

在以下範例中，您會設定以下電路保險絲：

每個連線的要求數量上限：100
連線數量上限：1000
待處理要求數量上限：200
要求次數上限：1,000
重試次數上限：3 次

如要設定電路切斷功能，請按照下列步驟操作：

主控台

前往 Google Cloud 控制台的「Cloud Service Mesh」頁面。

前往 Cloud Service Mesh
按一下要更新的後端服務名稱。
按一下「編輯」圖示。
按一下 [Advanced configurations] (進階設定)。
在「Circuit breakers」(電路保險絲) 下方，勾選「Enable」(啟用) 核取方塊。
按一下「編輯」圖示。
1. 在「每個連線的要求數量上限」中輸入 100。
2. 在「連線數量上限」中輸入 1000。
3. 在「待處理要求數量上限」中輸入 200。
4. 在「Max requests」(最大請求次數) 中輸入 1000。
5. 在「重試次數上限」中輸入 3。
依序點選「儲存」和「儲存」。

gcloud

執行 gcloud export 指令，匯出後端服務設定。將 BACKEND_SERVICE_NAME 替換為後端服務名稱。

 gcloud compute backend-services export BACKEND_SERVICE_NAME \
     --destination=BACKEND_SERVICE_NAME-config.yaml --global

請按照下列步驟更新 BACKEND_SERVICE_NAME.yaml 檔案：

 affinityCookieTtlSec: 0
 backends:
 - balancingMode: UTILIZATION
   capacityScaler: 1.0
    group:https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroups/INSTANCE_GROUP_NAME
   maxUtilization: 0.8
 circuitBreakers:
   maxConnections: 1000
   maxPendingRequests: 200
   maxRequests: 1000
   maxRequestsPerConnection: 100
   maxRetries: 3
 connectionDraining:
   drainingTimeoutSec: 300
 healthChecks:
   - https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME
 loadBalancingScheme: INTERNAL_SELF_MANAGED
 localityLbPolicy: ROUND_ROBIN
 name: BACKEND_SERVICE_NAME
 port: 80
 portName: http
 protocol: HTTP
 sessionAffinity: NONE
 timeoutSec: 30

更新後端服務設定檔：

gcloud compute backend-services import BACKEND_SERVICE_NAME \
    --source=BACKEND_SERVICE_NAME-config.yaml --global

依據 `HTTP_COOKIE` 設定工作階段相依性

進階流量管理可讓您根據提供的 Cookie 來設定工作階段相依性。

如要使用 HTTP_COOKIE 設定工作階段相依性，請按照下列步驟操作：

主控台

前往 Google Cloud 控制台的「Cloud Service Mesh」頁面。

前往 Cloud Service Mesh
按一下要更新的後端服務名稱。
按一下「編輯」圖示。
按一下 [Advanced configurations] (進階設定)。
在「工作階段相依性」下方，選取「HTTP Cookie」。
在「Locality Load balancing policy」(地區負載平衡政策) 下方，選取「Ring hash」(環形雜湊)。
1. 在「HTTP Cookie name」欄位中輸入 http_cookie。
2. 在「HTTP Cookie path」欄位中輸入 /cookie_path。
3. 在「HTTP Cookie 存留時間」欄位中輸入 100。
4. 在「Minimum ring size」(最小環帶大小) 欄位中輸入 10000。
按一下 [儲存]。

gcloud

執行 gcloud export 指令，匯出後端服務設定。將 BACKEND_SERVICE_NAME 替換為後端服務名稱。

gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global

請依照下列方式更新 YAML 檔案：

sessionAffinity: 'HTTP_COOKIE'
localityLbPolicy: 'RING_HASH'
consistentHash:
httpCookie:
  name: 'http_cookie'
  path: '/cookie_path'
  ttl:
    seconds: 100
    nanos: 30
minimumRingSize: 10000

匯入後端服務設定檔：

gcloud compute backend-services import BACKEND_SERVICE_NAME \
    --source=BACKEND_SERVICE_NAME-config.yaml --global

設定離群值偵測

異常情況偵測可控制從負載平衡集區中移除健康狀態不良的主機。Cloud Service Mesh 會使用一組政策來執行這項操作，這些政策會指定移除 NEG 中健康狀態不良的後端 VM 或端點的條件，也會定義條件，決定後端或端點何時會被視為健康狀態良好到足以再次接收流量。

在下例中，後端服務有一個執行個體群組做為後端。離群值偵測設定會指定每秒執行一次離群值偵測分析。如果端點連續傳回五次 5xx 錯誤，系統會在第一次發生時將其從負載平衡考量中移除 30 秒。同一個端點的實際彈出時間為 30 秒乘以彈出次數。

如要在後端服務資源上設定異常值偵測功能，請按照下列步驟操作：

主控台

前往 Google Cloud 控制台的「Cloud Service Mesh」頁面。

前往 Cloud Service Mesh
按一下服務名稱。
按一下「編輯」圖示。
按一下 [Advanced configurations] (進階設定)。
勾選「異常值偵測」核取方塊。
按一下「編輯」圖示。
1. 將「連續錯誤」設為 5。
2. 將「Interval」設為 1000 毫秒。
3. 將「Base ejection time」設為 30000 毫秒。
依序點選「儲存」和「儲存」。

gcloud

執行 gcloud export 指令，匯出後端服務設定。將 BACKEND_SERVICE_NAME 替換為後端服務名稱。

gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global

請按照下列方式更新 YAML 檔案，將 BACKEND_SERVICE_NAME 替換為後端服務的名稱：

name: BACKEND_SERVICE_NAME
loadBalancingScheme: INTERNAL_SELF_MANAGED
backends:
- balancingMode: UTILIZATION
 capacityScaler: 1.0
 group: $INSTANCE_GROUP_URL
healthChecks:
- $HEALTH_CHECK_URL
port: 80
portName: http
protocol: HTTP
outlierDetection:
 consecutiveErrors: 5,
 interval:
     seconds: 1,
     nanos: 0
 baseEjectionTime:
     seconds: 30,
     nanos: 0

匯入後端服務設定檔：

gcloud compute backend-services import BACKEND_SERVICE_NAME \
    --source=BACKEND_SERVICE_NAME-config.yaml --global

設定地區負載平衡政策

使用地區負載平衡政策，根據 Cloud Service Mesh 提供的地區權重和優先順序，選擇負載平衡演算法。舉例來說，您可以在健康的端點之間執行加權輪替或一致的雜湊。

在下例中，後端服務有一個執行個體群組做為後端。地區負載平衡政策設為 RING_HASH。

如要設定地區負載平衡政策，請按照下列步驟操作：

主控台

前往 Google Cloud 控制台的「Cloud Service Mesh」頁面。

前往 Cloud Service Mesh
按一下服務名稱。
按一下「編輯」圖示。
按一下 [Advanced configurations] (進階設定)。
在「流量政策」下方的「地區負載平衡政策」選單中，選取「環形雜湊」。
按一下 [儲存]。

gcloud

執行 gcloud export 指令，匯出後端服務設定。將 BACKEND_SERVICE_NAME 替換為後端服務名稱。

gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global

請按照下列步驟更新 BACKEND_SERVICE_NAME.yaml 檔案：

name: shopping-cart-service
loadBalancingScheme: INTERNAL_SELF_MANAGED
backends:
- balancingMode: UTILIZATION
 capacityScaler: 1.0
 group: $INSTANCE_GROUP_URL
healthChecks:
- $HEALTH_CHECK_URL
port: 80
portName: http
protocol: HTTP
localityLbPolicy: RING_HASH

匯入後端服務設定檔：

gcloud compute backend-services import BACKEND_SERVICE_NAME \
    --source=BACKEND_SERVICE_NAME-config.yaml --global

如要進一步瞭解區域負載平衡政策的運作方式，請參閱 backendService 資源的說明文件。

設定網址重新導向

此處的操作說明假設情況如下：

您的 Cloud Service Mesh 部署作業有一個名為 review-url-map 的網址對應。
網址對應會將所有流量傳送到名為 review1 的預設後端服務。
您想將流量從一個主機重新導向至另一個主機。

如要設定網址重新導向，請按照下列步驟操作：

主控台

前往 Google Cloud 控制台的「Cloud Service Mesh」頁面。

前往 Cloud Service Mesh
按一下「轉送規則對應關係」。
按一下「建立轉送規則對應關係」。
在「Create a routing rule map」(建立轉送規則對應關係) 頁面中，輸入「Name」(名稱)。
在「Protocol」選單中，選取「HTTP」。
選取現有的轉送規則。
在「轉送規則」下方，選取「進階主機、路徑和轉送規則」。
在「主機和路徑比對器」下方，按一下「新增主機和路徑比對器」。這會新增可重新導向流量的路徑比對工具。

在「路徑比對工具」欄位中新增下列設定：

    - defaultService: global/backendServices/review1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: ''
        urlRedirect:
         hostRedirect: '[REDIRECT_HOST]'
         pathRedirect: '[REDIRECT_URL]'
         redirectResponseCode: 'FOUND',
        stripQuery: True

按一下 [完成]。
按一下 [儲存]。

gcloud

執行 gcloud export 指令，取得網址對應設定：

gcloud compute url-maps export review-url-map \
    --destination=review-url-map-config.yaml

在 review-url-map-config.yaml 檔案中新增下列部分：

     hostRules:
     - description: ''
      hosts:
       - '*'
     pathMatcher: matcher1
     pathMatchers:
    - defaultService: global/backendServices/review1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: ''
        urlRedirect:
         hostRedirect: '[REDIRECT_HOST]'
         pathRedirect: '[REDIRECT_URL]'
         redirectResponseCode: 'FOUND',
        stripQuery: True

更新網址對應：

gcloud compute url-maps import review-url-map \
    --source=review-url-map-config.yaml

使用網址重新編寫功能設定流量導向

流量導引功能可根據標頭值等要求屬性，將流量導向不同的後端服務。此外，您還可以設定動作，例如在將要求導向後端服務之前，先重寫要求中的網址。

在以下範例中，如果要求路徑包含 /mobile/ 前置字串，且要求的 User-Agent 包含 Android，系統會將要求導向 SERVICE_ANDROID_URL。在將要求傳送至後端服務前，您可以將網址前置字串改成 REWRITE_PATH_ANDROID，例如 /android/。不過，如果路徑包含 /mobile/ 前置字串，且 User-Agent 包含 iPhone，系統會將流量導向 SERVICE_IPHONE_URL，並將網址前置字串改成 REWRITE_PATH_IPHONE。所有其他前置字串為 /mobile/ 的要求，以及 User-Agent 值不是 Android 或 iPhone 的要求，都會導向 SERVICE_GENERIC_DEVICE_URL。

pathMatchers:
     - defaultService: [DEFAULT_SERVICE_URL]
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: /mobile/
           headerMatches:
           - headerName: User-Agent
             regexMatch: .*Android.*
         service: $[SERVICE_ANDROID_URL]
         routeAction:
           urlRewrite:
             pathPrefixRewrite: [REWRITE_PATH_ANDROID]
       - matchRules:
         - prefixMatch: /mobile/
           headerMatches:
           - headerName: User-Agent
             regexMatch: .*iPhone.*
         service: [SERVICE_IPHONE_URL]
         routeAction:
           urlRewrite:
             pathPrefixRewrite: [REWRITE_PATH_IPHONE]
       - matchRules:
         - prefixMatch: /mobile/
         service: [SERVICE_GENERIC_DEVICE_URL]

設定錯誤植入

錯誤植入功能可讓您在特定路徑中，植入固定的延遲時間或強制停止 (稱為中止)，以測試應用程式的彈性。

在下列範例中，所有要求都會傳送至 SERVICE_URL，並在 100% 的要求中加入 10 秒的固定延遲時間。傳送要求的用戶端會發現所有回應都延遲 10 秒。此外，50% 的要求會套用 Service Unavailable 503 回應的停止錯誤。用戶端發現有 50% 的要求會收到 503 回應。這些要求完全不會送達後端服務。

pathMatchers:
     - defaultService: [DEFAULT_SERVICE_URL]
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: [SERVICE_URL]
            weight: 100
          faultInjectionPolicy:
            delay:
              fixedDelay:
                seconds: 10
                nanos: 0
              percentage: 100
            abort:
              httpStatus: 503
              percentage: 50

根據 `MetadataFilters` 比對結果設定篩選器

MetadataFilters 會透過轉送規則和 HttpRouteRuleMatch 啟用。您可以使用這項功能控制特定轉送規則或路由規則，讓控制層只將轉送規則或路由規則傳送至節點中繼資料符合中繼資料篩選器設定的 Proxy。如果您未指定任何 MetadataFilters，系統會將規則傳送至所有 Envoy 代理程式。

這項功能可讓您輕鬆操作設定的分階段部署作業。舉例來說，您可以建立名為 forwarding-rule1 的轉送規則，並指定只將該規則推送至節點中繼資料包含 app: review 和 version: canary 的 Envoy。

如要將 MetadataFilters 新增至轉送規則，請按照下列步驟操作：

gcloud

執行 gcloud export 指令取得轉送規則設定：

gcloud compute forwarding-rules export forwarding-rule1 \
    --destination=forwarding-rule1-config.yaml \
    --global

刪除轉送規則：

gcloud compute forwarding-rules delete forwarding-rule1 \
    --global

更新 forwarding-rule1-config.yaml 檔案。

以下範例會建立 MATCH_ALL 中繼資料篩選器：

 metadataFilters:
 - filterMatchCriteria: 'MATCH_ALL'
   filterLabels:
   - name: 'app'
     value: 'review'
   - name: 'version'
     value: 'canary'

以下範例會建立 MATCH_ANY 中繼資料篩選器：

 metadataFilters:
 - filterMatchCriteria: 'MATCH_ANY'
   filterLabels:
   - name: 'app'
     value: 'review'
   - name: 'version'
     value: 'production'

從 forwarding-rule1-config.yaml 檔案中移除所有輸出專用欄位。詳情請參閱 gcloud compute forwarding-rules import 的說明文件。

執行 gcloud import 指令來更新 forwarding-rule1-config.yaml 檔案：

gcloud compute forwarding-rules import forwarding-rule1 \
    --source=forwarding-rule1-config.yaml \
    --global

請按照下列操作說明，在啟動 Envoy 前，先將節點中繼資料新增至 Envoy。系統僅支援字串值。

a. 如果是 VM 型部署，請在 bootstrap_template.yaml 中，在 metadata 部分下方新增下列內容：
```
   app: 'review'
   version: 'canary'
```
b. 如果是 Google Kubernetes Engine 或 Kubernetes 部署作業，請在 trafficdirector_istio_sidecar.yaml 的 env 部分新增以下內容：
```
   - name: ISTIO_META_app
     value: 'review'
   - name: ISTIO_META_version
     value: 'canary'
```

中繼資料篩選範例

請在以下情況下使用以下操作說明：多個專案位於同一個共用虛擬私有雲網路中，且您希望每個服務專案的 Cloud Service Mesh 資源都能向同一個專案中的 Proxy 顯示。

共用虛擬私有雲的設定如下：

主專案名稱：vpc-host-project
服務專案：project1、project2
後端服務，其中包含在 project1 和 project2 中執行 xDS 相容 Proxy 的後端執行個體或端點

如要設定 Cloud Service Mesh 以隔離 project1，請按照下列步驟操作：

gcloud

使用以下中繼資料篩選器，在 project1 中建立所有轉送規則：

     metadataFilters:
     - filterMatchCriteria: 'MATCH_ALL'
       filterLabels
       - name: 'project_name'
         value: 'project1'
       - name: 'version'
         value: 'production'

在 project1 中設定部署至執行個體或端點的 Proxy 時，請在 Bootstrap 檔案的節點中繼資料部分加入下列中繼資料：
```
   project_name: 'project1'
   version: 'production'
```
確認已在 project2 中部署的 Proxy 未收到在第一個步驟中建立的轉送規則。如要這麼做，請嘗試從在 project2 中執行 Proxy 的系統存取 project1 中的服務。如要瞭解如何驗證 Cloud Service Mesh 設定是否正常運作，請參閱「驗證設定」。

如要在將新設定套用至所有 Proxy 之前，先在部分 Proxy 上測試，請按照下列步驟操作：

gcloud

使用下列節點中繼資料啟動用於測試的 Proxy，請勿為未用於測試的 Proxy 加入這個節點中繼資料。
```
  version: 'test'
```

針對每項要測試的新轉送規則，加入下列中繼資料篩選器：

  metadataFilters:
  - filterMatchCriteria: 'MATCH_ALL'
    filterLabels:
    - name: 'version'
      value: 'test'

將流量傳送至測試 Proxy，藉此測試新設定，並視需要進行變更。如果新設定能正常運作，則只有您測試的 Proxy 會收到新設定。其餘的 Proxy 不會收到新設定，也無法使用新設定。
確認新設定運作正常後，請移除與其相關聯的中繼資料篩選器。這樣一來，所有 Proxy 都能收到新設定。

疑難排解

如果系統並未根據您設定的轉送規則和流量政策來轉送流量，請使用這項資訊進行故障排除。

問題：

規則中的服務流量增加，而該項規則優於有問題的規則。
指定轉送規則的 4xx 和 5xx HTTP 回應非預期增加。

解決方案：由於系統會依優先順序解譯轉送規則，請檢查為各項規則指定的優先順序。

定義轉送規則時，請確認優先順序較高 (即優先順序編號較小) 的規則不會意外轉送原先會由後續轉送規則所轉送的流量。請參考以下範例：

第一個轉送規則
- 路由規則比對路徑前置字串 = /shopping/
- 重新導向動作：將流量傳送至後端服務 service-1
- 規則優先順序：4
第二條路線規則
- 轉送規則比對規則運算式比對 = /shopping/cart/ordering/.*
- 重新導向動作：將流量傳送至後端服務 service-2
- 規則優先順序：8

在這種情況下，路徑為 /shopping/cart/ordering/cart.html 的要求會轉送至 service-1。雖然第二個規則會符合條件，但系統會忽略該規則，因為第一個規則的優先順序較高。

封鎖服務間的流量

如果您想封鎖服務 A 和服務 B 之間的流量，且部署作業是在 GKE 上執行，請設定服務安全性，並使用授權政策封鎖服務間的流量。如需完整操作說明，請參閱「Cloud Service Mesh 服務安全性」和Envoy 與無 Proxy gRPC的設定說明。

後續步驟

如要瞭解如何解決 Cloud Service Mesh 設定問題，請參閱排解使用 Envoy 的部署問題。

使用 Envoy 設定進階流量管理

事前準備

設定流量拆分

主控台

gcloud

設定部分發布

設定藍綠部署

設定流量鏡像

主控台

gcloud

設定斷路機制

主控台

gcloud

依據 HTTP_COOKIE 設定工作階段相依性

主控台

gcloud

設定離群值偵測

主控台

gcloud

設定地區負載平衡政策

主控台

gcloud

設定網址重新導向

主控台

gcloud

使用網址重新編寫功能設定流量導向

設定錯誤植入

根據 MetadataFilters 比對結果設定篩選器

gcloud

中繼資料篩選範例

gcloud

gcloud

疑難排解

封鎖服務間的流量

後續步驟

依據 `HTTP_COOKIE` 設定工作階段相依性

根據 `MetadataFilters` 比對結果設定篩選器