App Mesh 连接故障排除 - Amazon App Mesh
无法解析虚拟服务的 DNS 名称无法连接到虚拟服务后端无法连接到外部服务无法连接到 MySQL 或 SMTP 服务器无法连接到 App Mesh 中建模为 TCP 虚拟节点或虚拟路由器的服务成功连接到未列为虚拟节点虚拟服务后端的服务当虚拟服务有虚拟节点提供程序 503 时，某些请求会失败，并显示 HTTP 状态码无法连接到 Amazon EFS 文件系统连接成功服务，但传入的请求未出现在 Envoy 的访问日志、跟踪记录或指标中在容器级别设置HTTP_PROXY/HTTPS_PROXY环境变量无法按预期工作。即使设置了路由的超时时间，上游请求也会超时。Envoy 回复了 HTTP 错误的请求。无法正确配置超时。
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

App Mesh 连接故障排除

本主题详细介绍了您在使用 App Mesh 连接时可能遇到的常见问题。

无法解析虚拟服务的 DNS 名称

症状

您的应用程序无法解析它正在尝试连接的虚拟服务的 DNS 名称。

解决方案

这是一个已知问题。有关更多信息，请参阅 “ VirtualServices 按任意主机名命名” 或 FQDN GitHub 问题。App Mesh 中的虚拟服务可以被命名为任何名称。只要虚拟服务名称中有 DNS A 记录，并且应用程序可以解析虚拟服务名称，Envoy 就会代理请求并将其路由到相应的目的地。要解决此问题，请在任何非环回 IP 地址（例如 10.10.10.10 虚拟服务名称）中添加 DNS A 记录。在以下条件下可以添加 DNS A 记录：

  • 在 Amazon Route 53 中，如果名称以您的私有托管区域名称为后缀

  • 在应用程序容器的 /etc/hosts 文件中

  • 在您管理的第三方 DNS 服务器中

如果您的问题仍未解决，请考虑GitHub 提出问题或联系 Su Amazon pport。

无法连接到虚拟服务后端

症状

您的应用程序无法与虚拟节点上定义为后端的虚拟服务建立连接。尝试建立连接时，连接可能完全失败，或者从应用程序的角度来看，请求可能会失败并显示 HTTP 503 响应代码。

解决方案

如果应用程序根本无法连接（未返回 HTTP 503 响应代码），请执行以下操作：

如果应用程序连接但请求失败并显示 HTTP 503 响应代码，请尝试以下操作：

  • 确保您要连接的虚拟服务存在于网格中。

  • 确保虚拟服务有提供商（虚拟路由器或虚拟节点）。

  • 使用 Envoy 作为 HTTP 代理时，如果您看到出口流量通过 Envoy 统计数据进入 cluster.cds_egress_*_mesh-allow-all 而非正确的目的地，那么 Envoy 很可能没有正确路由请求。filter_chains这可能是由于使用了不合格的虚拟服务名称所致。我们建议您使用实际服务的服务发现名称作为虚拟服务名称，因为 Envoy 代理通过其他虚拟服务的名称与其他虚拟服务进行通信。

    有关更多信息，请参阅虚拟服务。

  • 检查 Envoy 代理日志中是否出现以下任何错误消息：

    • No healthy upstream：Envoy 代理尝试路由到的虚拟节点没有任何已解析的端点，或者它没有任何运行正常的端点。确保目标虚拟节点的服务发现和运行状况检查设置正确。

      如果在部署或扩展后端虚拟服务的过程中对该服务的请求失败，请按照 当虚拟服务有虚拟节点提供程序 503 时，某些请求会失败，并显示 HTTP 状态码 中的指导进行操作。

    • No cluster match for URL：这很可能是当向虚拟服务发送的请求与虚拟路由器提供商下定义的任何路由所定义的标准都不匹配时引起的。通过确保路径和 HTTP 请求标头正确，确保将来自应用程序的请求发送到受支持的路由。

    • No matching filter chain found：这很可能是通过无效端口向虚拟服务发送请求时造成的。确保来自应用程序的请求使用虚拟路由器上指定的相同端口。

如果您的问题仍未解决，请考虑GitHub 提出问题或联系 Su Amazon pport。

无法连接到外部服务

症状

您的应用程序无法连接到网格之外的服务，例如 amazon.com。

解决方案

默认情况下，App Mesh 不允许从网格内应用程序到网格之外任何目的地的出站流量。要启用与外部服务的通信，有两个选项：

  • 将网格资源的出站过滤器设置为 ALLOW_ALL。此设置将允许网格内的任何应用程序与网格内外的任何目标 IP 地址进行通信。

  • 使用虚拟服务、虚拟路由器、路由和虚拟节点对网格中的外部服务进行建模。例如，要对外部服务进行建模 example.com，您可以创建一个名为 example.com 的虚拟服务，该虚拟路由器和路由将所有流量发送到 DNS 服务发现主机名为 example.com 的虚拟节点。

如果您的问题仍未解决，请考虑GitHub 提出问题或联系 Su Amazon pport。

无法连接到 MySQL 或 SMTP 服务器

症状

当允许到所有目的地（网格 EgressFilter type=ALLOW_ALL）的出站流量时，例如使用虚拟节点定义的 SMTP 服务器或 MySQL 数据库，您应用程序的连接将失败。例如，以下是尝试连接 MySQL 服务器时出现的错误消息。

ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
解决方案

这是一个已知问题，可通过使用 App Mesh 镜像版本 1.15.0 或更高版本来解决。有关更多信息，请参阅无法通过 App Mesh 连接到 MySQL GitHub 问题。之所以出现此错误，是因为由 App Mesh 配置的 Envoy 中的出站侦听器添加了 Envoy TLS Inspector 侦听器过滤器。有关更多信息，请参阅 Envoy 文档中的 TLS Inspector。此过滤器通过检查从客户端发送的第一个数据包来评估连接是否使用 TLS。但是，在 MySQL 和 SMTP 中，服务器会在连接后发送第一个数据包。有关 MySQL 的更多信息，请参阅 MySQL 文档中的首次握手。由于服务器发送第一个数据包，因此过滤器检查失败。

要根据您的 Envoy 版本解决此问题，请执行以下操作：

  • 如果您的 App Mesh 镜像 Envoy 版本为 1.15.0 或更高版本，请勿将 MySQL、SMTP、MSSQL 等外部服务建模为应用程序虚拟节点的后端。

  • 如果您的 App Mesh 镜像 Envoy 版本低于 1.15.0，请将端口 3306 添加到您的 MySQL 服务的值列表APPMESH_EGRESS_IGNORED_PORTS 中，并作为您用于 STMP 的端口。

重要

虽然标准 SMTP 端口是 25、587 和 465，但您只应添加正在使用的端口，而不是全部添加 APPMESH_EGRESS_IGNORED_PORTS 三个端口。

有关更多信息，请参阅更新适用于 Kubernetes 的服务、Amazon ECS 的更新服务或亚马逊 EC2 的更新服务。

如果您的问题仍未解决，则可以向我们详细说明您在使用现有GitHub 问题时遇到的情况，或者联系 Su Amazon pp ort。

无法连接到 App Mesh 中建模为 TCP 虚拟节点或虚拟路由器的服务

症状

您的应用程序无法连接到使用 App Mesh PortMapping定义中的 TCP 协议设置的后端。

解决方案

这是一个已知问题。有关更多信息，请参阅路由到同一端口上的多个 TCP 目的地 GitHub。由于 OSI 第 4 层向 Envoy 代理提供的信息存在限制，App Mesh 目前不允许建模为 TCP 的多个后端目标共享同一个端口。为确保可将 TCP 流量正确路由到所有后端目标，请执行以下操作：

  • 确保所有目的地都使用唯一端口。如果您使用虚拟路由器提供商来提供后端虚拟服务，则可以更改虚拟路由器端口，而无需更改其路由到的虚拟节点上的端口。这样，应用程序可在虚拟路由器端口上打开连接，而 Envoy 代理可继续使用虚拟节点中定义的端口。

  • 如果建模为 TCP 的目标是 MySQL 服务器，或者任何其他基于 TCP 的协议，服务器在连接后使用该协议发送第一批数据包，请参见 无法连接到 MySQL 或 SMTP 服务器。

如果您的问题仍未解决，则可以向我们详细说明您在使用现有GitHub 问题时遇到的情况，或者联系 Su Amazon pp ort。

成功连接到未列为虚拟节点虚拟服务后端的服务

症状

您的应用程序能够连接并发送流量到您的虚拟节点上未指定为虚拟服务后端的目的地。

解决方案

如果请求成功发送到未在 App Mesh API 中建模的目标，则最有可能的原因是网格的出站过滤器类型已设置为 ALLOW_ALL。当出站筛选器设置为 ALLOW_ALL 时，您的应用程序发出的与建模目的地（后端）不匹配的出站请求将发送到该应用程序设置的目标 IP 地址。

如果要禁止流量前往未在网格中建模的目的地，请考虑将出站过滤器值设置为 DROP_ALL。

注意

设置网格出站过滤器值会影响网格中的所有虚拟节点。

配置egress_filter为DROP_ALL并启用 TLS 不适用于非 Amazon 域的出站流量。

如果您的问题仍未解决，请考虑GitHub 提出问题或联系 Su Amazon pport。

当虚拟服务有虚拟节点提供程序 503 时，某些请求会失败，并显示 HTTP 状态码

症状

您的应用程序的一部分请求无法发送到使用虚拟节点提供商而非虚拟路由器提供商的虚拟服务后端。使用虚拟路由器提供商提供虚拟服务时，请求不会失败。

解决方案

这是一个已知问题。有关更多信息，请参阅上针对虚拟服务的虚拟节点提供商的重试策略。 GitHub使用虚拟节点作为虚拟服务提供者时，您无法指定希望虚拟服务的客户端使用的默认重试策略。相比之下，虚拟路由器提供商允许指定重试策略，因为它们是子路由资源的属性。

要减少向虚拟节点提供商请求失败的情况，请改用虚拟路由器提供商，并在其路由上指定重试策略。有关减少应用程序请求失败的其他方法，请参阅App Mesh 最佳实践。

如果您的问题仍未解决，请考虑GitHub 提出问题或联系 Su Amazon pport。

无法连接到 Amazon EFS 文件系统

症状

使用 Amazon EFS 文件系统作为卷配置 Amazon ECS 任务时，该任务无法启动，并出现以下错误。

ResourceInitializationError: failed to invoke EFS utils commands to set up EFS volumes: stderr: mount.nfs4: Connection refused : unsuccessful EFS utils command execution; code: 32
解决方案

这是一个已知问题。之所以出现此错误，是因为与 Amazon EFS 的 NFS 连接发生在任务中的任何容器启动之前。此流量通过代理配置路由到 Envoy，此时不会运行。由于启动顺序的原因，NFS 客户端无法连接到 Amazon EFS 文件系统，任务也无法启动。要解决此问题，请在 Amazon ECS 任务定义的代理配置中EgressIgnoredPorts设置的值列表中添加端口 2049。有关更多信息，请参阅 代理配置。

如果您的问题仍未解决，请考虑GitHub 提出问题或联系 Su Amazon pport。

连接成功服务，但传入的请求未出现在 Envoy 的访问日志、跟踪记录或指标中

症状

尽管您的应用程序可以连接其他应用程序并向其发送请求，但您要么无法在访问日志中看到传入的请求，要么无法在 Envoy 代理的跟踪信息中看到传入的请求。

解决方案

这是一个已知问题。如需更多信息，请参阅 Github 上的 iptables 规则设置问题。Envoy 代理仅拦截其相应虚拟节点正在侦听的端口的入站流量。对任何其他端口的请求都将绕过 Envoy 代理，直接访问其背后的服务。为了让 Envoy 代理拦截服务的入站流量，您需要将虚拟节点和服务设置为在同一端口上侦听。

如果您的问题仍未解决，请考虑GitHub 提出问题或联系 Su Amazon pport。

在容器级别设置HTTP_PROXY/HTTPS_PROXY环境变量无法按预期工作。

症状

当 HTTP_PROXY/HTTPS_PROXY 被设置为环境变量时：

  • 任务定义中的应用程序容器启用了 App Mesh，发送到 App Mesh 服务命名空间的请求将从 Envoy sidecar HTTP 500 获得错误响应。

  • 任务定义中的 Envoy 容器启用了 App Mesh，从 Envoy sidecar 发出的请求将不会通过HTTP/HTTPS代理服务器，环境变量也无法工作。

解决方案

对于应用程序容器：

App Mesh 的功能是让任务中的流量通过 Envoy 代理。HTTP_PROXY/HTTPS_PROXY配置通过将容器流量配置为通过不同的外部代理来覆盖此行为。Envoy 仍会拦截流量，但不支持使用外部代理代理代理网格流量。

如果要代理所有非网格流量，请设置 NO_PROXY 为包括网格的 CIDR/命名空间、本地主机和凭证的端点，如下例所示。

NO_PROXY=localhost,127.0.0.1,169.254.169.254,169.254.170.2,10.0.0.0/16

对于 Envoy 容器：

Envoy 不支持通用代理。我们不建议设置这些变量。

如果您的问题仍未解决，请考虑GitHub 提出问题或联系 Su Amazon pport。

即使设置了路由的超时时间，上游请求也会超时。

症状

您为以下各项定义了超时：

  • 路由，但您仍然收到上游请求超时错误。

  • 虚拟节点侦听器以及路由的超时和重试超时，但您仍会收到上游请求超时错误。

解决方案

要使大于 15 秒的高延迟请求成功完成，您需要在路由和虚拟节点侦听器级别指定超时时间。

如果您指定的路由超时大于默认的 15 秒，请确保同时为所有参与的虚拟节点的侦听器指定了超时时间。但是，如果您将超时时间缩短到低于默认值的值，则可以选择更新虚拟节点的超时时间。有关设置虚拟节点和路由时选项的更多信息，请参阅虚拟节点和路由。

如果您指定了重试策略，则您为请求超时指定的持续时间应始终大于或等于重试超时乘以您在重试策略中定义的最大重试次数。这样，您的请求就可以成功完成所有重试操作。有关更多信息，请参阅路线。

如果您的问题仍未解决，请考虑GitHub 提出问题或联系 Su Amazon pport。

Envoy 回复了 HTTP 错误的请求。

症状

对于通过网络负载均衡器 (NLB) 发送的所有请求，Envoy 用 HTTP 400 错误请求进行响应。当我们查看 Envoy 日志时，我们会看到：

  • 调试日志：

    dispatch error: http/1.1 protocol error: HPE_INVALID_METHOD

  • 访问日志：

    "- - HTTP/1.1" 400 DPE 0 11 0 - "-" "-" "-" "-" "-"
解决方案

解决方案是在 NLB 的目标组属性上禁用代理协议版本 2 (PPv2)。

到目前为止，使用 App Mesh 控制面板运行的虚拟网关和虚拟节点 Envoy 不支持 PPv2。如果您在 Kubernetes 上使用 Amazon 负载平衡器控制器部署 NLB，请通过将以下属性设置为来禁用 PPv2：false

service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: proxy_protocol_v2.enabled

有关 NLB 资源属性的更多详细信息，请参阅Amazon 负载均衡器控制器注释。

如果您的问题仍未解决，请考虑GitHub 提出问题或联系 Su Amazon pport。

无法正确配置超时。

症状

即使在虚拟节点侦听器上配置了超时时间，在通往虚拟节点后端的路由上配置了超时，您的请求仍会在 15 秒内超时。

解决方案

确保后端列表中包含正确的虚拟服务。

如果您的问题仍未解决，请考虑GitHub 提出问题或联系 Su Amazon pport。