排查 Envoy 部署问题

本指南提供的信息可帮助您解决 Traffic Director 配置问题。如需了解如何使用客户端状态发现服务 (CSDS) API 来帮助您调查 Traffic Director 的问题，请参阅了解 Traffic Director 客户端状态。

确定虚拟机上安装的 Envoy 版本

使用以下说明来验证在虚拟机 (VM) 实例上运行哪个 Envoy 版本。

通过自动 Envoy 部署确定版本

如需通过自动部署来验证或检查 Envoy 版本，您可以执行以下操作：

• 检查 gce-service-proxy/proxy-version 路径下的虚拟机客机特性：

  gcloud compute --project cloud-vm-mesh-monitoring instances get-guest-attributes INSTANCE_NAME \
    --zone ZONE --query-path=gce-service-proxy/proxy-version
  
  NAMESPACE          KEY            VALUE
  gce-service-proxy  proxy-version  dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL
  

• 您可以使用如下查询在 Google Cloud Console 的“虚拟机实例详情 Logging”页面中检查 Cloud Logging 实例日志：

  resource.type="gce_instance"
  resource.labels.instance_id="3633122484352464042"
  jsonPayload.message:"Envoy version"
  

  您将收到如下响应：

  {
  "insertId": "9zy0btf94961a",
  "jsonPayload": {
    "message": "Envoy Version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
    "localTimestamp": "2021-01-12T11:39:14.3991Z"
  },
  "resource": {
    "type": "gce_instance",
    "labels": {
      "zone": "asia-southeast1-b",
      "instance_id": "3633122484352464042",
      "project_id": "cloud-vm-mesh-monitoring"
    }
  },
  "timestamp": "2021-01-12T11:39:14.399200504Z",
  "severity": "INFO",
  "logName": "projects/cloud-vm-mesh-monitoring/logs/service-proxy-agent",
  "receiveTimestamp": "2021-01-12T11:39:15.407023427Z"
  }
  

• 使用 SSH 连接到虚拟机并检查二进制文件版本：

  YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version
  
  /usr/local/bin/envoy  version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL
  

• 使用 SSH 以 root 用户身份连接到虚拟机和管理界面：

  root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info
  {
  "version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
  "state": "LIVE",
  "hot_restart_version": "disabled",
  ...
  }
  

通过手动 Envoy 部署确定版本

如需通过手动部署来验证或检查 Envoy 版本，您可以执行以下操作：

• 使用 SSH 连接到虚拟机并检查二进制文件版本：

  YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version
  
  /usr/local/bin/envoy  version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL
  

• 使用 SSH 以 root 用户身份连接到虚拟机和管理界面：

  root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info
  {
  "version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
  "state": "LIVE",
  "hot_restart_version": "disabled",
  ...
  }
  

Envoy 日志位置

如需排查某些问题，您需要检查 Envoy 代理日志。

在 Google Kubernetes Engine (GKE) 中，Envoy 代理随应用 pod 一起运行。您可以查看按 envoy 容器过滤的应用 pod 日志中的任何错误。

• 如果集群启用了工作负载日志记录，您可以在 Cloud Logging 中查看错误。以下是可能的过滤条件：

  resource.type="K8S_CONTAINER"
  resource.labels.project_id="PROJECT_NAME"
  resource.labels.location="CLUSTER_ZONE"
  resource.labels.cluster_name="CLUSTER_NAME"
  resource.labels.namespace_name="WORKLOAD_NAMESPACE"
  labels.k8s-pod/app="WORKLOAD_NAME"
  resource.labels.container_name="envoy"
  

• 如果集群未启用工作负载日志记录，则您可以使用如下所示的命令查看错误：

  kubectl logs $(kubectl get po -l app=WORKLOAD_NAME -o=jsonpath='{.items[0].metadata.name}') -c envoy --tail 50 #NOTE: This assumes the default namespace.
  

• 您还可以使用以下过滤条件查看所有集群中运行的所有 Envoy 日志以及任何工作负载的日志：

  resource.type="K8S_CONTAINER"
  resource.labels.container_name="envoy"
  

通过 Compute Engine 和手动部署，在运行设置指南中的 run.sh 脚本之前定义 LOG_DIR。

• 例如：

  LOG_DIR='/var/log/envoy/'
  

• 默认情况下，错误会显示在以下日志中：

  /var/log/envoy/envoy.err.log
  

如果用户没有执行任何其他配置以将其导出到 Logging，则只有在您使用 SSH 连接到实例并获取此文件时，才能看到这些错误。

如果您使用自动 Envoy 部署，则可以使用 SSH 连接到实例来获取日志文件。该路径可能与前面提到的路径相同。

代理未连接到 Traffic Director

如果您的代理未连接到 Traffic Director，请执行以下操作：

• 检查 Envoy 代理日志中是否存在关于连接到 trafficdirector.googleapis.com 的任何错误。

• 如果您已（通过使用 iptables）设置了 netfilter 以将所有流量重定向到 Envoy 代理，请确保您以其身份运行代理的用户 (UID) 不会被重定向。否则，这会导致流量不断回送至代理。

• 确保已为项目启用 Traffic Director API。在项目的API 和服务下，查找 Traffic Director API 的错误。

• 在创建虚拟机时指定以下内容，以确认该虚拟机的 API 访问权限范围已设置为授予对 Google Cloud API 的完整访问权限：

  --scopes=https://www.googleapis.com/auth/cloud-platform
  

• 确认服务账号具有正确的权限。如需了解详情，请参阅允许服务账号访问 Traffic Director API。

• 确认您可以通过虚拟机访问 trafficdirector.googleapis.com:443。如果此访问存在问题，可能的原因是防火墙阻止了通过 TCP 端口 443 访问 trafficdirector.googleapis.com，或是 trafficdirector.googleapis.com 主机名存在 DNS 解析问题。

• 如果是使用 Envoy 作为边车代理，请确认 Envoy 版本是 1.9.1 或更高版本。

无法访问通过 Traffic Director 配置的服务

如果无法访问通过 Traffic Director 配置的服务，请确认边车代理是否正在运行且能够连接到 Traffic Director。

如果使用 Envoy 作为边车代理，则可以通过运行以下命令进行确认：

1. 在命令行中，确认 Envoy 进程是否正在运行：

   ps aux | grep envoy
   

2. 检查 Envoy 的运行时配置，以确认 Traffic Director 已配置动态资源。要查看配置，请运行以下命令：

   curl http://localhost:15000/config_dump
   

3. 确保已正确设置边车代理的流量拦截功能。 对于使用 iptables 进行的重定向设置，请运行 iptables 命令，然后 grep 输出以确保您的规则发挥作用：

   sudo iptables -t nat -S | grep ISTIO
   

   以下输出示例是 iptables 拦截虚拟 IP 地址 (VIP) 10.0.0.1/32 并将其转发到在端口 15001 上运行的 Envoy 代理 (UID1006)：

   -N ISTIO_IN_REDIRECT
   -N ISTIO_OUTPUT
   -N ISTIO_REDIRECT
   -A OUTPUT -p tcp -j ISTIO_OUTPUT
   -A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
   -A ISTIO_OUTPUT -m owner --uid-owner 1006 -j RETURN
   -A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
   -A ISTIO_OUTPUT -d 10.0.0.1/32 -j ISTIO_REDIRECT
   -A ISTIO_OUTPUT -j RETURN
   

如果虚拟机实例是通过 Google Cloud Console 创建的，则在重启之前，某些与 IPv6 相关的模块不会安装，而且无法使用。这会导致 iptables 因缺少依赖项而失败。在这种情况下，请重启虚拟机并重新执行设置过程，这样应该可以解决问题。使用 Google Cloud CLI 创建的 Compute Engine 虚拟机预计不会出现此问题。

配置 Envoy 访问日志记录时无法访问服务

如果您使用 TRAFFICDIRECTOR_ACCESS_LOG_PATH 配置 Envoy 访问日志（如为 Traffic Director 配置 Envoy 引导特性中所述），请确保运行 Envoy 代理的系统用户有权写入指定的访问日志位置。

如果未提供必要的权限，则系统将不会在代理上对侦听器进行编程；您可以通过在 Envoy 代理日志中检查以下错误消息来检测此情况：

gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) TRAFFICDIRECTOR_INTERCEPTION_PORT:
unable to open file '/var/log/envoy.log': Permission denied

要解决该问题，请更改所选文件的权限，使 Envoy 用户可写入访问日志。

应用无法连接到未在 Traffic Director 中配置的服务

请确保仅为 Traffic Director 中配置的服务的 IP 地址设置了流量拦截。如果所有流量都被拦截，则边车代理将以静默方式舍弃与 Traffic Director 中未配置的服务的连接。

流量在节点内循环或节点崩溃

如果已将 netfilter (iptables) 设置为拦截所有流量，请确保用于运行边车代理的用户 (UID) 不会被拦截。否则，边车代理发送的流量将无限期地回送至代理。因此，边车代理进程可能会崩溃。在参考配置中，netfilter 规则不会拦截来自代理用户的流量。

Envoy 日志中指示配置问题的错误消息

如果您在 Traffic Director 配置方面遇到问题，则可能会在 Envoy 日志中看到以下任一错误消息：

• warning envoy config    StreamAggregatedResources gRPC config stream closed:
  5, Traffic Director configuration was not found for network "VPC_NAME" in
  project "PROJECT_NUMBER".

• warning envoy upstream  StreamLoadStats gRPC config stream closed:
  5, Traffic Director configuration was not found for network "VPC_NAME" in
  project "PROJECT_NUMBER".

• warning envoy config    StreamAggregatedResources gRPC config stream closed:
  5, Requested entity was not found.

• warning envoy upstream  StreamLoadStats gRPC config stream closed:
  5, Requested entity was not found.

• Traffic Director configuration was not found.

最后一条错误消息 (Traffic Director configuration was not found) 通常表示 Envoy 正在从 Traffic Director 请求配置，但无法找到匹配的配置。当 Envoy 连接到 Traffic Director 时，它会显示 VPC 网络名称（例如 my-network）。然后，Traffic Director 会查找符合以下条件的转发规则：具有 INTERNAL_SELF_MANAGED 负载平衡方案且引用相同的 VPC 网络名称。

要消除此错误，请执行以下操作：

1. 请确保您的网络中存在具有负载平衡方案 INTERNAL_SELF_MANAGED 的转发规则。请记下该转发规则的 VPC 网络名称。

2. 如果您将 Traffic Director 用于 Compute Engine 上的自动 Envoy 部署，请确保提供给 --service-proxy:network 标志的值与转发规则的网络名称匹配。

3. 如果您将 Traffic Director 用于 Compute Engine 上的手动 Envoy 部署，请检查 Envoy 引导文件中的下列内容：

   1. 确保 TRAFFICDIRECTOR_NETWORK_NAME 变量的值与转发规则的 VPC 网络名称匹配。
   2. 请确保在 TRAFFICDIRECTOR_GCP_PROJECT_NUMBER 变量中设置项目编号。

4. 如果您要在 GKE 上进行部署并且使用的是自动注入器，请确保根据为 GKE pod 进行自动 Envoy 注入的 Traffic Director 设置正确配置了项目编号和 VPC 网络名称。

对 Compute Engine 的自动部署进行问题排查

本部分介绍如何对 Compute Engine 的自动 Envoy 部署进行问题排查。

Envoy 和虚拟机引导过程和进一步的生命周期管理操作可能因多种原因而失败，包括临时连接问题、代码库损坏、引导脚本和虚拟机代理中的 Bug 以及意外用户操作。

用于问题排查的通信渠道

Google Cloud 提供了通信渠道，可帮助您了解虚拟机上的组件的引导过程和当前状态。

虚拟串行端口输出日志记录

虚拟机的操作系统、BIOS 和其他系统级实体通常会将输出写入串行端口。此输出有助于排查系统崩溃、启动失败、启动问题和关停问题。

Compute Engine 引导代理会将执行的所有操作记录到串行端口 1 中。这包括系统事件，从实例的元数据服务器获取数据的基本软件包安装、iptables 配置和 Envoy 安装状态。

虚拟机上的代理会记录 Envoy 进程运行状况状态、新发现的 Traffic Director 服务以及在调查虚拟机问题时可能有用的任何其他信息。

Cloud Monitoring 日志记录

串行端口输出公开的数据也会记录到 Monitoring 中，Monitoring 使用 Golang 库并将日志导出到单独的日志以减少噪声。由于此日志是实例级日志，您可以在与其他实例日志相同的页面上找到服务代理日志。

虚拟机客机特性

客机特性是指应用在实例上运行期间可写入的特定类型的自定义元数据。实例上的任何应用或用户都可以对这些客机特性元数据值执行数据读写操作。

Compute Engine Envoy 引导脚本和虚拟机代理公开特性，其中包含 Envoy 引导过程和当前状态的相关信息。所有客机特性都公开在 gce-service-proxy 命名空间中：

gcloud compute instances get-guest-attributes INSTANCE_NAME  \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

如果您发现任何问题，我们建议您检查客机特性 bootstrap-status 和 bootstrap-last-failure 的值。除 FINISHED 以外的任何 bootstrap-status 值都表示 Envoy 环境尚未配置。bookstrap-last-failure 的值可指明问题。

无法从通过启用了服务代理的实例模板创建的虚拟机访问 Traffic Director 服务

要解决此问题，请按以下步骤操作：

1. 虚拟机上服务代理组件的安装可能尚未完成或可能失败。 使用以下命令来确定所有组件是否已正确安装：

   gcloud compute instances get-guest-attributes INSTANCE_NAME \
       --query-path=gce-service-proxy/ \
       --zone=ZONE
   

   bootstrap-status 客机特性设置为以下其中一项：

   • [none] 表示安装尚未开始。虚拟机可能仍在启动。请在几分钟后再次检查状态。
   • IN PROGRESS 表示服务代理组件的安装和配置尚未完成。重复对流程更新进行状态检查。
   • FAILED 表示组件的安装或配置失败。通过查询 gce-service-proxy/bootstrap-last-failure 特性来检查错误消息。
   • FINISHED 表示安装和配置过程已完成并且没有任何错误。按照以下说明验证流量拦截功能和 Envoy 代理已正确配置。

2. 对于基于 Traffic Director 的服务，虚拟机上的流量拦截功能未正确配置。 登录虚拟机并检查 iptables 配置：

   gcloud compute ssh INSTANCE_NAME \
       --zone=ZONE \
       sudo iptables -L -t nat
   

   在 SERVICE_PROXY_SERVICE_CIDRS 链中检查 SERVICE_PROXY_REDIRECT 条目，例如：

   Chain SERVICE_PROXY_SERVICE_CIDRS (1 references)
   target                   prot opt source         destination ...
   SERVICE_PROXY_REDIRECT   all  --  anywhere       10.7.240.0/20
   

   对于每项服务，destination 列中都应有匹配的 IP 地址或 CIDR。如果虚拟 IP 地址 (VIP) 没有条目，则从 Traffic Director 填充 Envoy 代理配置时出现问题，或者虚拟机代理失败。

3. Envoy 代理尚未从 Traffic Director 收到配置。 登录到虚拟机检查 Envoy 代理配置：

   gcloud compute ssh INSTANCE_NAME \
       --zone=ZONE \
       sudo curl localhost:15000/config_dump
   

   检查从 Traffic Director 收到的侦听器配置。例如：

   "dynamic_active_listeners": [
     ...
     "filter_chains": [{
       "filter_chain_match": {
         "prefix_ranges": [{
           "address_prefix": "10.7.240.20",
           "prefix_len": 32
         }],
         "destination_port": 80
       },
     ...
       "route_config_name": "URL_MAP/PROJECT_NUMBER.td-routing-rule-1"
     ...
   ]
   

   address_prefix 是 Traffic Director 服务的虚拟 IP 地址 (VIP)。它指向名为 td-routing-rule-1 的网址映射。检查您要连接的服务是否已包含在监听器配置中。

4. 虚拟机上的代理未运行。 创建新的 Traffic Director 服务时，虚拟机上的代理会自动配置流量拦截功能。如果代理未运行，则新服务的所有流量将直接流向 VIP 地址，从而绕过 Envoy 代理和超时。

   1. 通过运行以下命令来验证虚拟机代理中的状态：

      gcloud compute instances get-guest-attributes INSTANCE_NAME \
         --query-path=gce-service-proxy/ \
         --zone=ZONE
      

   2. 检查虚拟机代理的特性。agent-heartbeat 特性的值包含代理上次执行操作或检查的时间。如果该值超过 5 分钟，则代理会卡住，您应该使用以下命令重新创建该虚拟机：

      gcloud compute instance-groups managed recreate-instance
      

   3. agent-last-failure 特性会显示代理中发生的最后一个错误。这可能是一个暂时性问题，可在代理下次检查时解决（例如，如果错误为 Cannot reach the Traffic Director API server）或可能是永久性错误。等待几分钟，然后重新检查错误。

入站流量拦截功能配置到工作负载端口，但无法从虚拟机外部连接到该端口

要解决此问题，请按以下步骤操作：

1. 虚拟机上服务代理组件的安装可能尚未完成或可能失败。 使用以下命令来确定所有组件是否已正确安装：

   gcloud compute instances get-guest-attributes INSTANCE_NAME \
       --query-path=gce-service-proxy/ \
       --zone=ZONE
   

   bootstrap-status 客机特性设置为以下其中一项：

   • [none] 表示安装尚未开始。虚拟机可能仍在启动。请在几分钟后再次检查状态。
   • IN PROGRESS 表示服务代理组件的安装和配置尚未完成。重复对流程更新进行状态检查。
   • FAILED 表示组件的安装或配置失败。通过查询 gce-service-proxy/bootstrap-last-failure 特性来检查错误消息。
   • FINISHED 表示安装和配置过程已完成并且没有任何错误。按照以下说明验证流量拦截功能和 Envoy 代理已正确配置。

2. 虚拟机上的流量拦截功能未针对入站流量进行正确配置。 登录虚拟机并检查 iptables 配置：

   gcloud compute ssh INSTANCE_NAME \
       --zone=ZONE \
       sudo iptables -L -t nat
   

   在 SERVICE_PROXY_INBOUND 链中检查 SERVICE_PROXY_IN_REDIRECT 条目，例如：

   Chain SERVICE_PROXY_INBOUND (1 references)
   target                      prot opt source       destination ...
   SERVICE_PROXY_IN_REDIRECT   tcp  --  anywhere     anywhere  tcp dpt:mysql
   

   对于在 service-proxy:serving-ports 中定义的每个端口，destination 列中应该有一个匹配端口。如果端口没有条目，则所有入站流量都会绕过 Envoy 代理，直接进入此端口。

   验证是否没有其他规则会丢弃此端口或除某个特定端口之外的所有端口的流量。

3. Envoy 代理未从 Traffic Director 收到入站端口的配置。 登录到虚拟机检查 Envoy 代理配置：

   gcloud compute ssh INSTANCE_NAME \
       --zone=ZONE \
       sudo curl localhost:15000/config_dump
   

   查找从 Traffic Director 收到的inbound侦听器配置：

   "dynamic_active_listeners": [
     ...
     "filter_chains": [{
       "filter_chain_match": {
         "prefix_ranges": [{
           "address_prefix": "10.0.0.1",
           "prefix_len": 32
         }],
         "destination_port": 80
       },
     ...
       "route_config_name": "inbound|default_inbound_config-80"
     ...
   ]
   

   以 inbound 开头的 route_config_name 表示为入站流量拦截目的而创建的特殊服务。检查您要连接的端口是否已包含在监听器配置中的 destination_port 下。

对 GKE Pod 的自动部署进行问题排查

本部分介绍如何对 GKE pod 的自动 Envoy 部署进行问题排查。

启用自动 Envoy 注入后，pod 无法启动

在某些情况下，应用 Pod 可能无法正常启动。当您使用具有严格防火墙规则的专用 GKE 集群时，可能会发生这种情况。

如果要将 Traffic Director 与专用 GKE 集群搭配使用，则需要为 Sidecar 注入器网络钩子创建额外的防火墙规则。如需创建允许 GKE 控制层面访问 TCP 端口 9443 上的 pod 的防火墙规则，请参阅针对特定使用场景添加防火墙规则。

在创建独立 Pod 或部署尝试创建 Pod 时，您可以观察到此问题。

创建独立 pod（例如，使用 kubectl apply 或 kubectl run）时，kubectl 命令行可能返回如下错误消息：

Error from server (InternalError): Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

从部署创建 Pod 时，您可能会遇到以下症状：

• kubectl get pods 不显示与部署关联的 Pod。

• kubectl get events --all-namespaces 会显示如下所示的错误消息：

  Warning  FailedCreate  15s   replicaset-controller  Error creating: Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
  

按照设置指南执行操作时，您可以先在部署示例客户端并验证验证注入步骤中遇到此问题。运行 kubectl create -f demo/client_sample.yaml 之后，请运行 kubectl get deploy busybox 以查看 0/1 READY Pod。您还可以通过发出 kubectl describe rs -l run=client 命令来描述与部署关联的 replicaset，从而找到错误。

验证配置后连接被拒

如果使用自动 Envoy 注入功能设置 Traffic Director，则您在尝试验证配置时可能会收到连接被拒错误。可能是以下某个原因造成的：

• specs/01-configmap.yaml 文件中的 discoveryAddress 值不正确。值应当为 trafficdirector.googleapis.com:443。
• specs/01-configmap.yaml 文件中的 VPC 网络的值不正确。
• specs/01-configmap.yaml 文件中的 Traffic Director 项目的值不正确。
• Pod 中 discoveryAddress 的值错误。
• Istio Sidecar 注入器而不是 Traffic Director Sidecar 注入器正在运行。

您可以在配置 Sidecar 注入器中查看 specs/01-configmap.yaml 文件的示例。如果 specs/01-configmap.yaml 文件包含的值不正确，Envoy 将无法从 Traffic Director 获取更正配置。要解决此问题，请检查 specs/01-configmap.yaml 文件并确保值正确无误，然后重新创建自动注入器。

请务必在 specs/01-configmap.yaml 文件和 pod 中检查 discoveryAddress 的值。在 pod 中，Sidecar 注入器会设置该值。如需检查 pod 中 discoveryAddress 的值，请运行以下命令：

kubectl get po $BUSYBOX_POD -o yaml|grep -Po '\"discoveryAddress\":\"[^,]*\"'

您应该会看到如下所示的输出：

"discoveryAddress":"trafficdirector.googleapis.com:443"

连接因手动 Envoy 注入和 GKE Pod 被拒

如果您收到连接拒绝消息，请参阅 busybox 日志，了解已启用 Traffic Director API 还是 Envoy 日志的权限不正确。

连接因手动 Envoy 注入和 GKE Pod 超时

如果您收到连接超时消息，则问题很可能是部署中的网址映射、转发规则或后端服务的配置不正确。请检查这些资源以确认它们是否已正确配置。

连接使用服务器优先协议时的问题

某些应用（如 MySQL）使用的协议规定，服务器发送第一个数据包。这意味着，初始连接时，服务器发送第一个字节。Traffic Director 不支持这些协议和应用。

排查服务网格的健康状况

本指南提供的信息可帮助您解决 Traffic Director 配置问题。

大多数端点运行状况不佳时的 Traffic Director 行为

为了提高可靠性，当 99% 的端点运行状况不佳时，Traffic Director 会将数据层面配置为忽略端点的运行状况。相反，数据层面会平衡所有端点之间的流量，因为服务端口可能仍然有效。

不健康的后端导致流量分配不理想

Traffic Director 使用连接到后端服务的 HealthCheck 资源中的信息来评估后端的运行状况。Traffic Director 使用此运行状况将流量路由到最近的运行状况良好的后端。如果您的某些后端运行状况不佳，流量可能仍会继续得到处理，但分布不理想。例如，流量可能流向一个仍然存在健康后端的区域，但该区域离客户端更远，从而增加延迟时间。如需识别和监控后端的运行状况，请尝试按照以下步骤操作：

• 在 Google Cloud Console 中检查后端服务的运行状况。
  转到 Traffic Director 服务
• 确保为 HealthCheck 资源启用日志记录。
• 如果健康检查最近失败，请检查 Cloud Audit Logs 以确定 HealthCheck 配置最近是否更改。

后端意外拒绝流量

如果您配置了 Traffic Director 服务安全，则会使用 EndpointPolicy 资源将安全政策应用于后端。EndpointPolicy 配置错误可能会导致后端拒绝流量。使用以下日志来排查这种情况：

• 检查 Traffic Director 报告的任何端点政策冲突。
• 检查 Cloud Audit Logs 以检查用户配置（具体而言是 EndpointPolicy、ServerTlsPolicy 或 AuthorizationPolicy）最近是否发生了更改。

后续步骤

• 如需了解 Traffic Director 的工作原理，请参阅 Traffic Director 概览。
• 如需解决在部署无代理 gRPC 服务时遇到的配置问题，请参阅排查使用无代理 gRPC 的部署的问题。
• 如需查找使用 Traffic Director 的其他支持，请参阅获取支持。