配置使用 Envoy 的高级流量管理

本文档介绍如何为使用 Envoy 的 Traffic Director 部署配置高级流量管理功能。

准备工作

在配置高级流量管理之前，请按照准备使用 Envoy 设置 Traffic Director 中的说明进行操作，包括配置 Traffic Director 和您需要的任何虚拟机 (VM) 主机或 Google Kubernetes Engine (GKE) 集群。创建所需的 Google Cloud 资源。

高级流量管理功能的可用性因您选择的请求协议而异。在您使用目标 HTTP 或 HTTPS 代理、目标 gRPC 代理或目标 TCP 代理资源配置路由时，系统会配置此协议。

借助目标 HTTP 代理和目标 HTTPS 代理，本文档中介绍的所有功能都可供使用。
如果使用目标 gRPC 代理，某些功能可供使用。
如果使用目标 TCP 代理，无法使用任何高级流量管理功能。

如需了解详情，请参阅 Traffic Director 功能和高级流量管理。如需端到端设置指南，请参阅使用无代理 gRPC 服务配置高级流量管理。

设置流量拆分

此处的说明假定您采用如下设置：

您的 Traffic Director 部署使用一个名为 review-url-map 的网址映射。
网址映射会将所有流量发送到一项名为 review1 的后端服务，这是默认后端服务。
您计划将 5% 的流量路由到新版本的服务。该服务在与后端服务 review2 关联的网络端点组 (NEG) 中的后端虚拟机或端点上运行。
不使用主机规则或路径匹配器。

如果您要将流量拆分到网址映射之前未引用的新服务，请先将新服务添加到 weightedBackendServices 并赋予 0 权重。然后，逐步增加分配给该服务的权重。

如需设置流量拆分，请按以下步骤操作：

控制台

在 Google Cloud Console 中，转到 Traffic Director 页面。

打开 Traffic Director
点击路由规则映射。
点击 创建路由规则映射。
在创建路由规则映射页面上，输入名称。
在协议菜单中，选择 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。

设置部分版本

先使用部分部署流程（有时称为 Canary 版），将新的软件版本发布到一小部分服务器，然后再将新版本发布到剩余的生产服务器。

部分版本使用 weightedBackendServices。如需启用部分版本，请将后端服务指定为测试服务或 Canary 版服务，并为其指定较低的权重（例如 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 部署用于接收全部的生产流量。如果出现问题，您可以反转这两个部署的权重，从而有效地还原有缺陷的 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 是接收所有流量的后端服务的网址。

设置流量镜像

如果您希望将流量定向到两个不同的后端服务以调试或测试新服务，那么您可以使用流量镜像。

在以下示例中，所有请求都将发送到 SERVICE_URL 和 MIRROR_SERVICE_URL。只有来自 SERVICE_URL 的响应会发送回客户端。MIRROR_SERVICE_URL 对客户端没有任何影响。

如需设置流量镜像，请按以下步骤操作：

控制台

在 Google Cloud Console 中，转到 Traffic Director 页面。

打开 Traffic Director
点击路由规则映射。
点击 创建路由规则映射。
在创建路由规则映射页面上，输入名称。
在协议列表中，选择 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
请求数上限：1000
重试次数上限：3

要设置熔断，请按以下步骤操作：

控制台

在 Google Cloud Console 中，转到 Traffic Director 页面。

转到 Traffic Director
点击要更新的后端服务的名称。
点击修改。
点击高级配置。
在断路器下，选中启用复选框。
点击修改。
1. 在每个连接的最大请求数中，输入 100。
2. 在最大连接数中，输入 1000。
3. 在待处理请求数上限中，输入 200。
4. 在最大请求数中，输入 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 Console 中，转到 Traffic Director 页面。

转到 Traffic Director
点击要更新的后端服务的名称。
点击修改。
点击高级配置。
在会话亲和性下，选择 HTTP Cookie。
在局部负载平衡政策下，选择环哈希。
1. 在 HTTP Cookie 名称字段中，输入 http_cookie。
2. 在 HTTP Cookie 路径字段中，输入 /cookie_path。
3. 在 HTTP Cookie TTL 字段中，输入 100。
4. 在最小环大小字段中，输入 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

设置离群值检测

离群值检测控制负载平衡池中运行状况不佳的主机的逐出。为此，Traffic Director 使用一组指定从 NEG 中逐出运行状况不佳的后端虚拟机或端点的政策，以及将后端或端点视为运行状况良好、足以再次接收流量的条件。

在以下示例中，后端服务将一个实例组作为其后端。离群值检测设置指定每秒运行一次离群值检测分析。如果端点返回五个连续的 5xx 错误，则系统会从负载平衡考虑中移除该端点（首次移除的时长为 30 秒）。同一端点的实际移除时间为 30 秒乘以其移除次数。

若要在后端服务资源上设置离群值检测，请按照以下步骤操作：

控制台

在 Google Cloud Console 中，转到 Traffic Director 页面。

转到 Traffic Director
点击相应服务的名称。
点击修改。
点击高级配置。
选中离群值检测复选框。
点击修改。
1. 将连续错误数设置为 5。
2. 将间隔设置为 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

设置局部负载平衡政策

使用局部负载平衡政策，根据 Traffic Director 提供的局部权重和优先级选择负载平衡算法。例如，您可以在运行状况良好的端点之间执行加权轮循，或执行一致的哈希处理。

在以下示例中，后端服务将一个实例组作为其后端。局部负载平衡政策设置为 RING_HASH。

如需设置局部负载均衡政策，请按照以下步骤操作：

控制台

在 Google Cloud Console 中，转到 Traffic Director 页面。

转到 Traffic Director
点击相应服务的名称。
点击修改。
点击高级配置。
在流量政策下的局部负载均衡政策菜单中，选择环哈希。
点击保存。

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 资源的文档。

设置网址重定向

此处的说明假定您采用如下设置：

您的 Traffic Director 部署使用一个名为 review-url-map 的网址映射。
网址映射会将所有流量发送到一项名为 review1 的后端服务，这是默认后端服务。
您希望将流量从一个主机重定向到另一个主机。

如需设置网址重定向，请按以下步骤操作：

控制台

在 Google Cloud Console 中，转到 Traffic Director 页面。

打开 Traffic Director
点击路由规则映射。
点击 创建路由规则映射。
在创建路由规则映射页面上，输入名称。
在协议菜单中，选择 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/ 且具有包含 iPhone 的 User-Agent，那么流量会被定向到 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，并且全部请求都会增加 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 启用。使用此功能控制特定的转发规则或路由规则，以便控制层面仅将转发规则或路由规则发送到其节点元数据与元数据过滤条件设置匹配的代理。如果未指定任何 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.对于基于虚拟机的部署，请在 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'
```

元数据过滤示例

对于以下情况，请按以下说明操作：多个项目位于同一共享 VPC 网络中，并且您希望每个服务项目的 Traffic Director 资源对于同一项目中的代理可见。

共享 VPC 设置如下所示：

宿主项目名称：vpc-host-project
服务项目：project1、project2
project1 和 project2 中的后端服务，其中的后端实例或端点运行与 xDS 兼容的代理

如需配置 Traffic Director 以隔离 project1，请按照以下步骤操作：

gcloud

使用以下元数据过滤器在 project1 中创建所有转发规则：

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

在 project1 中配置部署到实例或端点的代理时，请将以下元数据添加到引导文件的节点元数据部分：
```
   project_name: 'project1'
   version: 'production'
```
验证已在 project2 中部署的代理没有收到在第一步中创建的转发规则。为此，请尝试通过在 project2 中运行代理的系统访问 project1 中的服务。如需了解如何验证 Traffic Director 配置是否正常工作，请参阅验证配置。

如需先对一部分代理进行新配置的测试，然后再将其提供给所有代理，请按以下步骤操作：

gcloud

使用以下节点元数据启动您要用于测试的代理。请勿为不会用于测试的代理添加此节点元数据。
```
  version: 'test'
```

对于您要测试的每条新转发规则，请添加以下元数据过滤器：

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

通过将流量发送到测试代理来测试新配置，并进行任何必要的更改。如果新配置正常工作，则只有您测试的代理才会收到新配置。其余代理不会收到新配置，因此无法使用新配置。
确认新配置正常工作后，请移除与其关联的元数据过滤器。这样一来，所有代理都会收到新配置。

问题排查

如果流量未按照您配置的路由规则和流量政策进行路由，您可以根据以下信息来进行问题排查。

症状：

发往规则中所涉及服务的流量超过相关规则指定的流量。
给定路由规则的 4xx 和 5xx HTTP 响应意外增加。

解决方案：由于路由规则按优先级顺序进行解释，请查看分配给每条规则的优先级。

定义路由规则时，请确保优先级较高（即优先级数字较低）的规则不会意外路由原本会通过后续路由规则路由的流量。请思考以下示例：

第一条路由规则
- 路由规则匹配 pathPrefix = /shopping/
- 重定向操作：将流量发送到后端服务 service-1
- 规则优先级：4
第二条路由规则
- 路由规则匹配 regexMatch = /shopping/cart/ordering/.*
- 重定向操作：将流量发送到后端服务 service-2
- 规则优先级：8

在这种情况下，路径为 /shopping/cart/ordering/cart.html 的请求将路由到 service-1。即使第二条规则可以匹配，系统也会忽略它，因为第一条规则的优先级更高。

禁止服务之间的流量

如果您想要阻止服务 A 和服务 B 之间的流量，并且您的部署在 GKE 上，请设置服务安全性，并使用授权政策来阻止服务之间的流量。如需查看完整说明，请参阅 Traffic Director 服务安全以及 Envoy 和无代理 gRPC 设置说明。

后续步骤

为了帮助您解决 Traffic Director 配置问题，请参阅排查使用 Envoy 的部署的问题。

配置使用 Envoy 的高级流量管理

准备工作

设置流量拆分

控制台

gcloud

设置部分版本

设置蓝绿部署

设置流量镜像

控制台

gcloud

设置熔断

控制台

gcloud

根据 HTTP_COOKIE 设置会话亲和性

控制台

gcloud

设置离群值检测

控制台

gcloud

设置局部负载平衡政策

控制台

gcloud

设置网址重定向

控制台

gcloud

通过网址重写设置流量导向

设置故障注入

设置基于 MetadataFilters 匹配的配置过滤

gcloud

元数据过滤示例

gcloud

gcloud

问题排查

禁止服务之间的流量

后续步骤

根据 `HTTP_COOKIE` 设置会话亲和性

设置基于 `MetadataFilters` 匹配的配置过滤