View a markdown version of this page

App Mesh 设置故障排除 - AWS App Mesh
无法提取 Envoy 容器镜像无法连接到 App Mesh Envoy 管理服务Envoy 已断开与 App Mesh Envoy 管理服务的连接，Envoy 容器运行状况检查、就绪探测或活跃度探测失败从负载均衡器到网格端点的运行状况检查失败虚拟网关不接受端口 1024 或更少的流量

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

App Mesh 设置故障排除

重要

终止支持通知：2026 年 9 月 30 日， AWS 将停止对的支持。 AWS App Mesh 2026 年 9 月 30 日之后，您将无法再访问 AWS App Mesh 控制台或 AWS App Mesh 资源。有关更多信息，请访问这篇博客文章从 AWS App Mesh 亚马逊ECS服务连接迁移。

本主题详细介绍了您在设置 App Mesh 时可能遇到的常见问题。

无法提取 Envoy 容器镜像

症状

您在 Amazon ECS 任务中收到以下错误消息。以下消息Region中的 Amazon ECR account ID 和可能有所不同，具体取决于您从哪个 Amazon ECR 存储库中提取容器镜像。

CannotPullContainerError: Error response from daemon: pull access denied for 840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy, repository does not exist or may require 'docker login'
解决方案

此错误表示正在使用的任务执行角色无权与 Amazon ECR 通信，也无法从存储库中提取 Envoy 容器镜像。分配给您的 Amazon ECS 任务的任务执行角色需要包含以下声明的 IAM 策略：

{
  "Action": [
    "ecr:BatchCheckLayerAvailability",
    "ecr:GetDownloadUrlForLayer",
    "ecr:BatchGetImage"
  ],
  "Resource": "arn:aws:ecr:us-west-2:111122223333:repository/aws-appmesh-envoy",
  "Effect": "Allow"
},
{
  "Action": "ecr:GetAuthorizationToken",
  "Resource": "*",
  "Effect": "Allow"
}

如果您的问题仍未解决，请考虑提出GitHub 问题或联系AWS 支持部门。

无法连接到 App Mesh Envoy 管理服务

症状

您的 Envoy 代理无法连接到 App Mesh Envoy 管理服务。您将看到：

  • “连接被拒绝”错误

  • 连接超时

  • 解析 App Mesh Envoy 管理服务端点时出错

  • gRPC 错误

解决方案

确保您的 Envoy 代理可以访问互联网或私有 VPC 终端节点，并且您的安全组允许端口 443 上的出站流量。App Mesh 的公有 Enoy 管理服务端点遵循完全限定域名（FQDN）格式。

# App Mesh Production Endpoint
appmesh-envoy-management.Region-code.amazonaws.com

# App Mesh Preview Endpoint
appmesh-preview-envoy-management.Region-code.amazonaws.com

您可以使用以下命令调试与 EMS 的连接。这会向 Envoy 管理服务发送一个有效但为空的 gRPC 请求。

curl -v -k -H 'Content-Type: application/grpc' -X POST https://appmesh-envoy-management.Region-code.amazonaws.com:443/envoy.service.discovery.v3.AggregatedDiscoveryService/StreamAggregatedResources

如果您收到这些回复，则表明您与 Envoy 管理服务的连接正常。要调试 gRPC 相关错误，请参阅 Envoy 中与 App Mesh Envoy 管理服务断开连接的错误以及错误文本。

grpc-status: 16
grpc-message: Missing Authentication Token

如果您的问题仍未解决，请考虑提出GitHub 问题或联系AWS 支持部门。

Envoy 已断开与 App Mesh Envoy 管理服务的连接，

症状

您的 Envoy 代理无法连接到 App Mesh Envoy 管理服务并接收其配置。您的 Envoy 代理日志包含如下日志条目。

gRPC config stream closed: gRPC status code, message
解决方案

在大多数情况下，日志的消息部分应指明问题。下表列出了您可能会看到的最常见的 gRPC 状态码、其原因和解决方案。

gRPC 状态码 原因 解决方案
0 正常断开与 Envoy 管理服务的连接。 没有消息。App Mesh 偶尔会使用此状态码断开 Envoy 代理的连接。Envoy 将重新连接并继续接收更新。
3 找不到网格端点（虚拟节点或虚拟网关）或其关联资源之一。 仔细检查您的 Envoy 配置，确保它具有其所代表的 App Mesh 资源的相应名称。如果您的 App Mesh 资源与其他 AWS 资源（例如 AWS Cloud Map 命名空间或 ACM 证书）集成在一起，则请确保这些资源存在。
7 Envoy 代理未经授权执行操作，例如连接到 Envoy 管理服务或检索关联资源。 请务必创建包含适用于 App Mesh 和其他服务的相应策略声明的 IAM 策略，并将该策略附加到您的 Envoy 代理用于连接 Envoy 管理服务的 IAM 用户或角色。
8 给定 App Mesh 资源的 Envoy 代理数量超过了账户级别的服务限额。 有关默认账户配额以及如何请求增加配额的更多信息，请参阅 App Mesh 服务限额。
16 Envoy 代理没有有效的 AWS身份验证凭证。 确保 Envoy 拥有适当的凭证，可以通过 IAM 用户或角色连接到 AWS 服务。如果 Envoy 进程使用 1024 文件描述符，则版本 v1.24 及之前版本的 Envoy 中存在一个已知问题 #24136 无法获取凭证。当 Envoy 为高流量提供服务时，就会发生这种情况。您可以通过在调试级别查看 Envoy 日志中是否有文本“A libcurl function was given a bad argument”来确认此问题。要缓解此问题，请升级到 Envoy 版本 v1.25.1.0-prod 或更高版本。

您可以使用以下查询通过 Amazon CloudWatch Insights 观察来自 Envo y 代理的状态代码和消息：

filter @message like /gRPC config stream closed/
| parse @message "gRPC config stream closed: *, *" as StatusCode, Message

如果提供的错误消息无济于事，或者您的问题仍未解决，请考虑提出GitHub 问题。

Envoy 容器运行状况检查、就绪探测或活跃度探测失败

症状

您的 Envoy 代理在 Amazon ECS 任务、Amazon EC2 实例或 Kubernetes 容器组 (pod) 中的运行状况检查失败。例如，您使用以下命令查询 Envoy 管理界面，但收到的状态不是 LIVE。

curl -s http://my-app.default.svc.cluster.local:9901/server_info | jq '.state'
解决方案

以下是补救步骤列表，具体取决于 Envoy 代理返回的状态。

  • PRE_INITIALIZING 或者 INITIALIZING — Envoy 代理尚未接收配置，或者无法从 App Mesh Envoy 管理服务连接和检索配置。Envoy 在尝试连接时可能会收到来自 Envoy 管理服务的错误。有关更多信息，请查看 Envoy 已断开与 App Mesh Envoy 管理服务的连接， 中的错误文本。

  • DRAINING：Envoy 代理已开始耗尽连接，以响应 Envoy 管理界面上的 /healthcheck/fail 或 /drain_listeners 请求。除非您即将终止您的 Amazon ECS 任务、Amazon EC2 实例或 Kubernetes 容器组 (pod)，否则我们不建议您在管理界面上调用这些路径。

如果您的问题仍未解决，请考虑提出GitHub 问题或联系AWS 支持部门。

从负载均衡器到网格端点的运行状况检查失败

症状

容器运行状况检查或就绪情况探测认为您的网格端点运行正常，但是从负载均衡器到网状端点的运行状况检查失败。

解决方案

要解决此问题，请完成以下任务。

  • 确保与您的网格端点关联的安全组接受您为运行状况检查配置的端口上的入站流量。

  • 请确保在手动请求运行状况检查时始终如一地成功；例如，来自您的 VPC 内的堡垒主机。

  • 如果您正在为虚拟节点配置运行状况检查，我们建议您在应用程序中实现运行状况检查端点；例如，/ping for HTTP。这样可以确保 Envoy 代理和您的应用程序均可从负载均衡器进行路由。

  • 根据所需的功能，您可以针对虚拟节点使用任何类型的弹性负载均衡器。有关更多信息，请参阅 弹性负载均衡功能。

  • 如果您正在为虚拟网关配置运行状况检查，我们建议使用网络负载均衡器，并在虚拟网关的侦听器端口上进行 TCP 或 TLS 运行状况检查。这可确保虚拟网关侦听器已启动并准备好接受连接。

如果您的问题仍未解决，请考虑提出GitHub 问题或联系AWS 支持部门。

虚拟网关不接受端口 1024 或更少的流量

症状

您的虚拟网关不接受端口 1024 或更少的流量，但接受端口号大于 1024 的流量。例如，使用以下命令查询 Envoy 统计数据并收到一个非零值。

curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "update_rejected"

您可能会在日志中看到与以下描述绑定到特权端口失败的文本类似的文本：

gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) lds_ingress_0.0.0.0_port_<port num>: cannot bind '0.0.0.0:<port num>': Permission denied
解决方案

要解决此问题，为网关指定的用户需要具有 linux 功能 CAP_NET_BIND_SERVICE。有关更多信息，请参阅《Linux 程序员手册》中的功能、ECS 任务定义参数中的 Linux 参数和 Kubernetes 文档中的设置容器功能。

重要

Fargate 必须使用大于 1024 的端口值。

如果您的问题仍未解决，请考虑提出GitHub 问题或联系AWS 支持部门。