Anthos 服務網格和 Traffic Director 現已改名為 Cloud Service Mesh。詳情請參閱 Cloud Service Mesh 總覽。

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

使用 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
按一下「轉送規則對應」。
按一下「建立轉送規則對應關係」。
在「建立轉送規則對應關係」頁面中，輸入「名稱」。
在「Protocol」(通訊協定) 選單中，選取「HTTP」。
選取現有的轉送規則。
在「Routing rules」(轉送規則) 下方，選取「Advanced host, path and route rule」(進階型主機、路徑與路由規則)。
在「主機和路徑比對器」下方，按一下「新增主機和路徑比對器」。這會新增路徑比對器，您可以設定該比對器來分割流量。

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

    - 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% 的正式版流量。如果發現問題，可以反轉兩個部署作業的權重，這樣就能有效復原有問題的版本，並重新啟用已知良好的版本。GREENBLUE在前述任一情況下，兩個版本都可接收流量，因此您可以迅速調整流量。

如要啟用藍綠部署，請使用下列 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
按一下「轉送規則對應」。
按一下「建立轉送規則對應關係」。
在「建立轉送規則對應關係」頁面中，輸入「名稱」。
在「Protocol」(通訊協定) 清單中，選取「HTTP」。
選取現有的轉送規則。
在「Routing rules」(轉送規則) 下方，選取「Advanced host, path and route rule」(進階型主機、路徑與路由規則)。
在「主機和路徑比對器」下方，按一下「新增主機和路徑比對器」。這會新增路徑比對器，您可以設定該比對器來鏡像處理流量。

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

    - 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
按一下要更新的後端服務名稱。
點選「Edit」(編輯)。
按一下 [Advanced configurations] (進階設定)。
在「斷路器」下方，勾選「啟用」核取方塊。
點選「Edit」(編輯)。
1. 在「每個連線的要求數量上限」中，輸入 100。
2. 在「連線數量上限」中輸入 1000。
3. 在「待處理要求數量上限」中，輸入 200。
4. 在「Max requests」(要求上限) 中輸入 1000。
5. 在「Max retries」(重試次數上限) 中輸入 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
按一下要更新的後端服務名稱。
點選「Edit」(編輯)。
按一下 [Advanced configurations] (進階設定)。
在「工作階段相依性」下方，選取「HTTP Cookie」。
在「地區負載平衡政策」下方，選取「環形雜湊」。
1. 在「HTTP Cookie name」(HTTP Cookie 名稱) 欄位中輸入 http_cookie。
2. 在「HTTP Cookie path」欄位中，輸入 /cookie_path。
3. 在「HTTP Cookie TTL」欄位中輸入 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
按一下服務名稱。
點選「Edit」(編輯)。
按一下 [Advanced configurations] (進階設定)。
勾選「異常偵測」核取方塊。
點選「Edit」(編輯)。
1. 將「連續錯誤」設為 5。
2. 將「Interval」設為 1000 毫秒。
3. 將「基礎排除時間」設為 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
按一下服務名稱。
點選「Edit」(編輯)。
按一下 [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

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

設定網址重新導向

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

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

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

控制台

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

前往 Cloud Service Mesh
按一下「轉送規則對應」。
按一下「建立轉送規則對應關係」。
在「建立轉送規則對應關係」頁面中，輸入「名稱」。
在「Protocol」(通訊協定) 選單中，選取「HTTP」。
選取現有的轉送規則。
在「Routing rules」(轉送規則) 下方，選取「Advanced host, path and route rule」(進階型主機、路徑與路由規則)。
在「主機和路徑比對器」下方，按一下「新增主機和路徑比對器」。這會新增路徑比對器，重新導向流量。

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

    - 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/」前置字串，且要求的使用者代理程式包含「Android」，系統會將要求導向 SERVICE_ANDROID_URL。/mobile/User-AgentAndroid在將要求傳送至後端服務前，您可以將網址前置字串改成 REWRITE_PATH_ANDROID，例如 /android/。不過，如果路徑包含「/mobile/」前置字串，且使用者代理程式包含「iPhone」，則系統會將流量導向 $[SERVICE_IPHONE_URL]，並將網址前置字串改成 $[REWRITE_PATH_IPHONE]。/mobile/User-AgentiPhoneSERVICE_IPHONE_URLREWRITE_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 秒才收到回應。此外，503 回應的停止錯誤會套用到 50% 的要求。Service Unavailable用戶端發現有 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` 比對設定篩選條件

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

這項功能可讓您輕鬆操作設定的階段性部署。舉例來說，建立名為 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'
```

中繼資料篩選範例

如果多個專案位於同一個 Shared VPC 網路中，且您希望每個服務專案的 Cloud Service Mesh 資源對相同專案中的 Proxy 可見，請按照下列操作說明進行。

Shared VPC 設定如下：

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

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

gcloud

在 project1 中使用下列中繼資料建立所有轉送規則： filter:

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

在 project1 中設定部署至執行個體或端點的 Proxy 時，請在自我啟動檔案的節點中繼資料部分加入下列中繼資料：
```
   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 回應非預期增加。

解決方法：系統會依優先順序解譯轉送規則，因此請檢查指派給每項規則的優先順序。

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

第一條轉送規則
- 轉送規則符合 pathPrefix = /shopping/
- 重新導向動作：將流量傳送至後端服務 service-1
- 規則優先順序：4
第二條轉送規則
- 轉送規則比對規則運算式 match = /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` 比對設定篩選條件