App Mesh Kubernetes 故障排除 - Amazon App Mesh
在 Kubernetes 中创建的应用网格资源无法在 App Mesh 中找到注入 Envoy sidecar 后，容器组 (pod) 无法进行就绪和活跃度检查容器组 (pod) 未注册或取消注册为实例 Amazon Cloud Map无法确定 App Mesh 资源的容器组 (pod) 在何处运行无法确定容器组 (pod) 以哪个 App Mesh 资源运行禁用后，客户特使无法与 App Mesh Envoy 管理服务通信 IMDSv1IRSA启用 App Mesh 并注入 Envoy 时，不适用于应用程序容器
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

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

App Mesh Kubernetes 故障排除

重要

终止支持通知：2026 年 9 月 30 日， Amazon 将停止对的支持。 Amazon App Mesh 2026 年 9 月 30 日之后，您将无法再访问 Amazon App Mesh 控制台或 Amazon App Mesh 资源。如需了解更多信息，请访问此博客文章从迁移 Amazon App Mesh 到 Amazon S ECS ervice Connect。

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

在 Kubernetes 中创建的应用网格资源无法在 App Mesh 中找到

症状

您已使用 Kubernetes 自定义资源定义 (CRD) 创建了 App Mesh 资源，但是当您使用或时，您创建的资源在 App Mesh 中不可见。 Amazon Web Services Management Console APIs

解决方案

可能的原因是 App Mesh 的 Kubernetes 控制器出现错误。有关更多信息，请参阅上的 “故障排除” GitHub。检查控制器日志中是否存在任何表明控制器无法创建任何资源的错误或警告。

kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller)

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

注入 Envoy sidecar 后，容器组 (pod) 无法进行就绪和活跃度检查

症状

您的应用程序的 pod 之前已成功运行，但是在 Envoy sidecar 注入容器组 (pod) 后，就绪和活跃度检查开始失败。

解决方案

确保注入到容器组 (pod) 的 Envoy 容器已通过 App Mesh 的 Envoy 管理服务进行引导。您可以通过参考 Envoy 与 App Mesh Envoy 管理服务断开连接，显示错误文本 中的错误代码来验证任何错误。您可以使用以下命令检查相关容器组 (pod) 的 Envoy 日志。

kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller) \
    | grep "gRPC config stream closed"

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

容器组 (pod) 未注册或取消注册为实例 Amazon Cloud Map

症状

您的 Kubernetes Pod 并未 Amazon Cloud Map 作为其生命周期的一部分在中注册或注销。容器组 (pod) 可能成功启动并准备好提供流量，但无法接收任何流量。当容器组 (pod) 终止时，客户端仍可能保留其 IP 地址并尝试向其发送流量，但失败了。

解决方案

这是一个已知问题。有关更多信息，请参阅 Pod 无法在 Kubernetes 中自动注册/ 注销，出现问题。 Amazon Cloud Map GitHub 由于 Pod、App Mesh 虚拟节点和 Amazon Cloud Map 资源之间的关系，Kubernetes 的 App Mesh 控制器可能会变得不同步并丢失资源。例如，如果虚拟节点资源在终止其关联的容器组 (pod) 之前从 Kubernetes 中删除，就会发生这种情况。

要缓解此问题，请执行以下操作：

  • 确保您运行的是适用于 Kubernetes 的最新版本的 App Mesh 控制器。

  • 确保虚拟节点定义中的 Amazon Cloud Map namespaceName和serviceName正确。

  • 在删除虚拟节点定义之前，请务必删除所有关联的容器组 (pod)。如果您需要帮助来确定哪些容器组 (pod) 与虚拟节点相关联，请参阅 无法确定 App Mesh 资源的容器组 (pod) 在何处运行。

  • 如果问题仍然存在，请运行以下命令检查控制器日志中是否存在可能有助于揭示潜在问题的错误。

    kubectl logs -n appmesh-system \
    $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)

  • 考虑使用以下命令重启控制器容器组 (pod)。这可能会解决同步问题。

    kubectl delete -n appmesh-system \
    $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)

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

无法确定 App Mesh 资源的容器组 (pod) 在何处运行

症状

当您在 Kubernetes 集群上运行 App Mesh 时，操作员无法确定给定的 App Mesh 资源的工作负载或容器在哪里运行。

解决方案

Kubernetes 容器组 (pod) 资源使用与其关联的网格和虚拟节点进行注释。您可以使用以下命令查询哪些容器组 (pod) 正在为给定的虚拟节点名称运行。

kubectl get pods --all-namespaces -o json | \
    jq '.items[] | { metadata } | select(.metadata.annotations."appmesh.k8s.aws/virtualNode" == "virtual-node-name")'

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

无法确定容器组 (pod) 以哪个 App Mesh 资源运行

症状

在 Kubernetes 集群上运行 App Mesh 时，操作员无法确定给定的容器组 (pod) 以什么形式运行 App Mesh 资源。

解决方案

Kubernetes 容器组 (pod) 资源使用与其关联的网格和虚拟节点进行注释。您可以使用以下命令直接查询容器组 (pod) 来输出网格和虚拟节点的名称。

kubectl get pod pod-name -n namespace -o json | \
    jq '{ "mesh": .metadata.annotations."appmesh.k8s.aws/mesh", "virtualNode": .metadata.annotations."appmesh.k8s.aws/virtualNode" }'

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

禁用后，客户特使无法与 App Mesh Envoy 管理服务通信 IMDSv1

症状

禁用 IMDSv1 后，客户 Envoy 无法与 App Mesh 控制面板（Envoy 管理服务）通信。v1.24.0.0-prod之前的 App Mesh Envoy 版本不提供支持 IMDSv2。

解决方案

要解决这个问题，你可以做这三件事之一。

  • 升级到 App Mesh Envoy 版本 v1.24.0.0-prod 或更高版本，该版本有 IMDSv2 支持。

  • 在运行 Envoy 的实例 IMDSv1 上重新启用。有关恢复的说明 IMDSv1，请参阅配置实例元数据选项。

  • 如果您的服务在 Amazon 上运行EKS，建议使用服务账户 (IRSA) 的IAM角色来获取证书。有关启用的说明IRSA，请参阅服务帐号的IAM角色。

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

IRSA启用 App Mesh 并注入 Envoy 时，不适用于应用程序容器

症状

在亚马逊的 App Mesh 控制器的帮助下，在亚马逊EKS集群上启用 App Mesh 时EKS，Envoy 和proxyinit容器将注入到应用程序容器中。应用程序无法假设 IRSA，而是假设 node role。当我们描述容器组 (pod) 的详细信息时，我们会看到应用程序容器中不包含 AWS_WEB_IDENTITY_TOKEN_FILE 或 AWS_ROLE_ARN 环境变量。

解决方案

如果定义了 AWS_WEB_IDENTITY_TOKEN_FILE 或 AWS_ROLE_ARN 环境变量，则 webhook 将跳过容器组 (pod)。不要提供这两个变量中的任何一个，webhook 会为您注入它们。

reservedKeys := map[string]string{
        "AWS_ROLE_ARN":                "",
        "AWS_WEB_IDENTITY_TOKEN_FILE": "",
    }
    ...
    for _, env := range container.Env {
        if _, ok := reservedKeys[env.Name]; ok {
            reservedKeysDefined = true
        }

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