Résolution des problèmes de connectivité App Mesh

Important

Avis de fin de support : le 30 septembre 2026, AWS le support pour AWS App Mesh. Après le 30 septembre 2026, vous ne pourrez plus accéder à la AWS App Mesh console ni aux AWS App Mesh ressources. Pour plus d'informations, consultez ce billet de blog Migration depuis Amazon ECS Service Connect AWS App Mesh vers Amazon ECS.

Cette rubrique décrit les problèmes courants que vous pouvez rencontrer avec la connectivité App Mesh.

Impossible de résoudre le nom DNS d'un service virtuel

Symptômes

Votre application ne parvient pas à résoudre le nom DNS d'un service virtuel auquel elle tente de se connecter.

Résolution

Il s'agit d'un problème connu. Pour plus d'informations, consultez la section Name VirtualServices by any hostname or FQDN issue GitHub . Les services virtuels d'App Mesh peuvent porter n'importe quel nom. Tant qu'il existe un A enregistrement DNS pour le nom du service virtuel et que l'application peut résoudre le nom du service virtuel, la demande sera transmise par proxy par Envoy et acheminée vers la destination appropriée. Pour résoudre le problème, ajoutez un A enregistrement DNS à toute adresse IP non bouclée, par exemple pour le 10.10.10.10 nom du service virtuel. L'Aenregistrement DNS peut être ajouté dans les conditions suivantes :

• Dans Amazon Route 53, si le nom est suffixé par le nom de votre zone hébergée privée

• Dans le /etc/hosts fichier du conteneur de l'application

• Sur un serveur DNS tiers que vous gérez

Si votre problème n'est toujours pas résolu, envisagez d'en ouvrir un GitHub ou contactez le AWS support.

Impossible de se connecter à un backend de service virtuel

Symptômes

Votre application ne parvient pas à établir de connexion à un service virtuel défini comme un backend sur votre nœud virtuel. Lorsque vous tentez d'établir une connexion, celle-ci peut échouer complètement ou, du point de vue de l'application, la demande peut échouer avec un code de HTTP 503 réponse.

Résolution

Si l'application ne parvient pas du tout à se connecter (aucun code de HTTP 503 réponse n'est renvoyé), procédez comme suit :

• Assurez-vous que votre environnement informatique a été configuré pour fonctionner avec App Mesh.

  • Pour Amazon ECS, assurez-vous que la configuration de proxy appropriée est activée. Pour une présentation détaillée de bout en bout, consultez la section Démarrage avec App Mesh et Amazon ECS.

  • Pour Kubernetes, y compris Amazon EKS, assurez-vous que le dernier contrôleur App Mesh est installé via Helm. Pour plus d'informations, consultez App Mesh Controller sur Helm Hub ou Tutoriel : Configurer l'intégration d'App Mesh avec Kubernetes.

  • Pour Amazon EC2, assurez-vous d'avoir configuré votre instance Amazon EC2 pour le proxy du trafic App Mesh. Pour plus d'informations, consultez la section Services de mise à jour.

• Assurez-vous que le conteneur Envoy qui s'exécute sur votre service informatique s'est correctement connecté au service de gestion App Mesh Envoy. Vous pouvez le confirmer en consultant les statistiques d'Envoy pour le terraincontrol_plane.connected_state. Pour plus d'informationscontrol_plane.connected_state, consultez la section Surveiller la connectivité du proxy Envoy dans nos meilleures pratiques de dépannage.

  Si l'Envoy a pu établir la connexion initialement, mais qu'il s'est ensuite déconnecté et ne s'est jamais reconnecté, consultez Envoy déconnecté du service de gestion App Mesh Envoy avec un texte d'erreur pour déterminer pourquoi il a été déconnecté.

Si l'application se connecte mais que la demande échoue avec un code de HTTP 503 réponse, essayez ce qui suit :

• Assurez-vous que le service virtuel auquel vous vous connectez existe dans le maillage.

• Assurez-vous que le service virtuel dispose d'un fournisseur (un routeur virtuel ou un nœud virtuel).

• Lorsque vous utilisez Envoy comme proxy HTTP, si vous voyez du trafic sortant entrer cluster.cds_egress_*_mesh-allow-all au lieu de la bonne destination via les statistiques d'Envoy, il est fort probable qu'Envoy n'achemine pas correctement les demandes. filter_chains Cela peut être dû à l'utilisation d'un nom de service virtuel non qualifié. Nous vous recommandons d'utiliser le nom de découverte de service du service réel comme nom du service virtuel, car le proxy Envoy communique avec d'autres services virtuels via leurs noms.

  Pour plus d'informations, consultez la section Services virtuels.

• Consultez les journaux du proxy Envoy pour détecter l'un des messages d'erreur suivants :

  • No healthy upstream— Le nœud virtuel vers lequel le proxy Envoy tente d'acheminer n'a aucun point de terminaison résolu, ou il ne possède aucun point de terminaison sain. Assurez-vous que le nœud virtuel cible possède les bons paramètres de découverte de services et de vérification de l'état.

    Si les demandes adressées au service échouent lors du déploiement ou de la mise à l'échelle du service virtuel principal, suivez les instructions figurant dansCertaines requêtes échouent avec le code d'état HTTP 503 lorsqu'un service virtuel possède un fournisseur de nœud virtuel.

  • No cluster match for URL— Cela est probablement dû à l'envoi d'une demande à un service virtuel qui ne correspond aux critères définis par aucune des routes définies par un fournisseur de routeur virtuel. Assurez-vous que les requêtes de l'application sont envoyées vers une route prise en charge en vous assurant que le chemin et les en-têtes de requête HTTP sont corrects.

  • No matching filter chain found— Cela est probablement dû à l'envoi d'une demande à un service virtuel sur un port non valide. Assurez-vous que les requêtes de l'application utilisent le même port que celui spécifié sur le routeur virtuel.

Si votre problème n'est toujours pas résolu, envisagez d'en ouvrir un GitHub ou contactez le AWS support.

Impossible de se connecter à un service externe

Symptômes

Votre application ne parvient pas à se connecter à un service en dehors du maillage, tel queamazon.com.

Résolution

Par défaut, App Mesh n'autorise pas le trafic sortant des applications du maillage vers une destination en dehors du maillage. Pour activer la communication avec un service externe, deux options s'offrent à vous :

• Définissez le filtre sortant de la ressource maillée sur. ALLOW_ALL Ce paramètre permet à n'importe quelle application du maillage de communiquer avec n'importe quelle adresse IP de destination à l'intérieur ou à l'extérieur du maillage.

• Modélisez le service externe dans le maillage à l'aide d'un service virtuel, d'un routeur virtuel, d'une route et d'un nœud virtuel. Par exemple, pour modéliser le service externeexample.com, vous pouvez créer un service virtuel nommé example.com avec un routeur virtuel et une route qui envoie tout le trafic vers un nœud virtuel dont le nom d'hôte de découverte de example.com services DNS est.

Si votre problème n'est toujours pas résolu, envisagez d'en ouvrir un GitHub ou contactez le AWS support.

Impossible de se connecter à un serveur MySQL ou SMTP

Symptômes

Lorsque vous autorisez le trafic sortant vers toutes les destinations (Mesh EgressFilter type =ALLOW_ALL), comme un serveur SMTP ou une base de données MySQL à l'aide d'une définition de nœud virtuel, la connexion depuis votre application échoue. À titre d'exemple, voici un message d'erreur lors d'une tentative de connexion à un serveur MySQL.

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

Résolution

Il s'agit d'un problème connu qui est résolu à l'aide de la version 1.15.0 ou ultérieure de l'image App Mesh. Pour plus d'informations, consultez le GitHub problème Impossible de se connecter à MySQL avec App Mesh. Cette erreur se produit car l'écouteur sortant dans Envoy configuré par App Mesh ajoute le filtre d'écoute Envoy TLS Inspector. Pour plus d'informations, consultez TLS Inspector dans la documentation Envoy. Ce filtre évalue si une connexion utilise le protocole TLS en inspectant le premier paquet envoyé par le client. Cependant, avec MySQL et SMTP, le serveur envoie le premier paquet après la connexion. Pour plus d'informations sur MySQL, consultez la section Initial Handshake dans la documentation MySQL. Comme le serveur envoie le premier paquet, l'inspection au niveau du filtre échoue.

Pour contourner ce problème en fonction de votre version d'Envoy :

• Si la version d'Envoy de votre image App Mesh est 1.15.0 ou ultérieure, ne modélisez pas des services externes tels que MySQL, SMTP, MSSQL , etc. comme backend pour le nœud virtuel de votre application.

• Si la version d'Envoy de votre image App Mesh est antérieure à la version 1.15.0, ajoutez le port 3306 à la liste des valeurs de vos services pour MySQL et APPMESH_EGRESS_IGNORED_PORTS en tant que port que vous utilisez pour STMP.

Important

Bien que les ports SMTP standard soient 25587, et465, vous ne devez ajouter que le port que vous utilisez, APPMESH_EGRESS_IGNORED_PORTS et non les trois.

Pour plus d'informations, consultez Services de mise à jour pour Kubernetes, Services de mise à jour pour Amazon ECS ou Services de mise à jour pour Amazon EC2.

Si votre problème n'est toujours pas résolu, vous pouvez nous fournir des informations sur ce que vous rencontrez en utilisant le GitHub problème existant ou contacter le AWS support.

Impossible de se connecter à un service modélisé comme un nœud virtuel TCP ou un routeur virtuel dans App Mesh

Symptômes

Votre application ne parvient pas à se connecter à un backend qui utilise le paramètre de protocole TCP dans la définition App Mesh PortMapping.

Résolution

Il s'agit d'un problème connu. Pour plus d'informations, consultez la section Routage vers plusieurs destinations TCP sur le même port sur GitHub. App Mesh n'autorise pas actuellement plusieurs destinations dorsales modélisées comme TCP à partager le même port en raison de restrictions concernant les informations fournies au proxy Envoy au niveau de la couche 4 de l'OSI. Pour vous assurer que le trafic TCP peut être acheminé correctement pour toutes les destinations principales, procédez comme suit :

• Assurez-vous que toutes les destinations utilisent un port unique. Si vous utilisez un fournisseur de routeur virtuel pour le service virtuel principal, vous pouvez modifier le port du routeur virtuel sans modifier le port des nœuds virtuels vers lesquels il est acheminé. Cela permet aux applications d'ouvrir des connexions sur le port du routeur virtuel pendant que le proxy Envoy continue d'utiliser le port défini dans le nœud virtuel.

• Si la destination modélisée comme TCP est un serveur MySQL ou tout autre TCP-based protocole dans lequel le serveur envoie les premiers paquets après la connexion, consultez. Impossible de se connecter à un serveur MySQL ou SMTP

Si votre problème n'est toujours pas résolu, vous pouvez nous fournir des informations sur ce que vous rencontrez en utilisant le GitHub problème existant ou contacter le AWS support.

La connectivité réussit à un service qui n'est pas répertorié comme backend de service virtuel pour un nœud virtuel

Symptômes

Votre application est capable de se connecter et d'envoyer du trafic vers une destination qui n'est pas spécifiée comme backend de service virtuel sur votre nœud virtuel.

Résolution

Si les requêtes aboutissent à une destination qui n'a pas été modélisée dans les API App Mesh, la cause la plus probable est que le type de filtre sortant du maillage a été défini sur. ALLOW_ALL Lorsque le filtre sortant est défini surALLOW_ALL, une demande sortante de votre application qui ne correspond pas à une destination modélisée (backend) est envoyée à l'adresse IP de destination définie par l'application.

Si vous souhaitez interdire le trafic vers des destinations non modélisées dans le maillage, pensez à définir la valeur du filtre sortant sur. DROP_ALL

Note

La définition de la valeur du filtre sortant du maillage affecte tous les nœuds virtuels du maillage.

La configuration egress_filter en tant que TLS DROP_ALL et son activation ne sont pas disponibles pour le trafic sortant qui n'est pas destiné à un AWS domaine.

Si votre problème n'est toujours pas résolu, envisagez d'en ouvrir un GitHub ou contactez le AWS support.

Certaines requêtes échouent avec le code d'état HTTP 503 lorsqu'un service virtuel possède un fournisseur de nœud virtuel

Symptômes

Une partie des demandes de votre application ne parviennent pas à un backend de service virtuel qui utilise un fournisseur de nœuds virtuels au lieu d'un fournisseur de routeur virtuel. Lorsque vous utilisez un fournisseur de routeur virtuel pour le service virtuel, les demandes n'échouent pas.

Résolution

Il s'agit d'un problème connu. Pour plus d'informations, consultez la section Politique de nouvelle tentative sur le fournisseur de nœud virtuel pour un service virtuel sur GitHub. Lorsque vous utilisez un nœud virtuel comme fournisseur pour un service virtuel, vous ne pouvez pas spécifier la politique de nouvelle tentative par défaut que vous souhaitez que les clients de votre service virtuel utilisent. En comparaison, les fournisseurs de routeurs virtuels autorisent la spécification de politiques de nouvelle tentative car elles sont une propriété des ressources de routage enfants.

Pour réduire les échecs des demandes adressées aux fournisseurs de nœuds virtuels, utilisez plutôt un fournisseur de routeur virtuel et spécifiez une politique de nouvelle tentative sur ses itinéraires. Pour d'autres moyens de réduire le nombre d'échecs des demandes adressées à vos applications, consultezMeilleures pratiques d'App Mesh.

Si votre problème n'est toujours pas résolu, envisagez d'en ouvrir un GitHub ou contactez le AWS support.

Impossible de se connecter à un système de fichiers Amazon EFS

Symptômes

Lors de la configuration d'une tâche Amazon ECS avec un système de fichiers Amazon EFS en tant que volume, la tâche ne démarre pas avec l'erreur suivante.

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

Résolution

Il s'agit d'un problème connu. Cette erreur se produit car la connexion NFS à Amazon EFS se produit avant le démarrage des conteneurs de votre tâche. Ce trafic est acheminé par la configuration du proxy vers Envoy, qui ne sera pas exécuté à ce stade. En raison de l'ordre de démarrage, le client NFS ne parvient pas à se connecter au système de fichiers Amazon EFS et la tâche ne démarre pas. Pour résoudre le problème, ajoutez le port 2049 à la liste des valeurs du EgressIgnoredPorts paramètre dans la configuration proxy de votre définition de tâche Amazon ECS. Pour plus d'informations, consultez la section Configuration du proxy.

Si votre problème n'est toujours pas résolu, envisagez d'en ouvrir un GitHub ou contactez le AWS support.

La connectivité parvient à être traitée, mais la demande entrante n'apparaît pas dans les journaux d'accès, les traces ou les mesures d'Envoy

Symptômes

Même si votre application peut se connecter et envoyer des demandes à une autre application, vous ne pouvez pas voir les demandes entrantes dans les journaux d'accès ou dans les informations de suivi pour le proxy Envoy.

Résolution

Il s'agit d'un problème connu. Pour plus d'informations, consultez la section Problème de configuration des règles iptables sur Github. Le proxy Envoy intercepte uniquement le trafic entrant vers le port sur lequel le nœud virtuel correspondant écoute. Les requêtes adressées à tout autre port contourneront le proxy Envoy et atteindront directement le service qui le sous-tend. Pour permettre au proxy Envoy d'intercepter le trafic entrant pour votre service, vous devez configurer votre nœud virtuel et votre service pour qu'ils écoutent sur le même port.

Si votre problème n'est toujours pas résolu, envisagez d'en ouvrir un GitHub ou contactez le AWS support.

La définition des variables d'environnement HTTP_PROXY/HTTPS_PROXY au niveau du conteneur ne fonctionne pas comme prévu.

Symptômes

Quand HTTP_PROXY/HTTPS_PROXY est défini en tant que variable d'environnement au niveau de :

• Conteneur d'applications dans la définition de la tâche avec App Mesh activé, les demandes envoyées à l'espace de noms des services App Mesh recevront des réponses HTTP 500 d'erreur du sidecar Envoy.

• Conteneur Envoy dans la définition des tâches avec App Mesh activé, les requêtes provenant du sidecar Envoy ne passeront pas par le serveurHTTP/HTTPSproxy et la variable d'environnement ne fonctionnera pas.

Résolution

Pour le conteneur d'applications :

App Mesh fonctionne en faisant passer le trafic lié à votre tâche via le proxy Envoy. HTTP_PROXY/HTTPS_PROXYconfiguration remplace ce comportement en configurant le trafic des conteneurs pour qu'il passe par un autre proxy externe. Le trafic sera toujours intercepté par Envoy, mais il ne prend pas en charge le proxy du trafic maillé à l'aide d'un proxy externe.

Si vous souhaitez utiliser un proxy pour tout le trafic non maillé, configurez NO_PROXY pour inclure les points de terminaison de votre maillage CIDR/namespace, de votre hôte local et des informations d'identification, comme dans l'exemple suivant.

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

Pour le conteneur Envoy :

Envoy ne prend pas en charge un proxy générique. Nous ne recommandons pas de définir ces variables.

Si votre problème n'est toujours pas résolu, envisagez d'en ouvrir un GitHub ou contactez le AWS support.

Délais d'attente des requêtes en amont, même après avoir défini le délai d'attente pour les itinéraires.

Symptômes

Vous avez défini le délai d'attente pour :

• Les itinéraires, mais vous recevez toujours une erreur de temporisation de la demande en amont.

• L'écouteur du nœud virtuel et le délai d'attente et le délai de nouvelle tentative pour les routes, mais vous recevez toujours une erreur de délai d'expiration de la demande en amont.

Résolution

Pour que les demandes à latence élevée supérieures à 15 secondes soient traitées avec succès, vous devez spécifier un délai d'attente à la fois au niveau de la route et de l'écouteur du nœud virtuel.

Si vous spécifiez un délai de routage supérieur aux 15 secondes par défaut, assurez-vous qu'il est également spécifié pour l'écouteur pour tous les nœuds virtuels participants. Toutefois, si vous réduisez le délai à une valeur inférieure à la valeur par défaut, il est facultatif de mettre à jour les délais d'expiration sur les nœuds virtuels. Pour plus d'informations sur les options de configuration de nœuds et de routes virtuels, consultez la section Nœuds et itinéraires virtuels.

Si vous avez spécifié une politique de nouvelle tentative, la durée que vous spécifiez pour le délai d'expiration de la demande doit toujours être supérieure ou égale au délai de nouvelle tentative multiplié par le nombre maximum de tentatives que vous avez défini dans la politique de nouvelle tentative. Cela permet à votre demande, avec toutes les nouvelles tentatives, de se terminer avec succès. Pour plus d'informations, consultez la section itinéraires.

Si votre problème n'est toujours pas résolu, envisagez d'en ouvrir un GitHub ou contactez le AWS support.

Envoy répond par une requête HTTP incorrecte.

Symptômes

Envoy répond par une requête HTTP 400 Bad pour toutes les demandes envoyées via le Network Load Balancer (NLB). Lorsque nous consultons les journaux d'Envoy, nous voyons :

• Journaux de débogage :

  dispatch error: http/1.1 protocol error: HPE_INVALID_METHOD

• Journaux d'accès :

  "- - HTTP/1.1" 400 DPE 0 11 0 - "-" "-" "-" "-" "-"

Résolution

La solution consiste à désactiver le protocole proxy version 2 (PPv2) sur les attributs du groupe cible de votre NLB.

À ce jour, le PPv2 n'est pas pris en charge par la passerelle virtuelle et le nœud virtuel Envoy qui sont exécutés à l'aide du plan de contrôle App Mesh. Si vous déployez NLB à l'aide d'un contrôleur d'équilibrage de AWS charge sur Kubernetes, désactivez PPv2 en définissant l'attribut suivant sur : false

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

Consultez AWS la section Annotations du contrôleur Load Balancer pour plus de détails sur les attributs des ressources NLB.

Si votre problème n'est toujours pas résolu, envisagez d'en ouvrir un GitHub ou contactez le AWS support.

Impossible de configurer correctement le délai d'attente.

Symptômes

Votre demande expire dans les 15 secondes, même après avoir configuré le délai d'attente sur l'écouteur du nœud virtuel et le délai d'attente sur la route vers le backend du nœud virtuel.

Résolution

Assurez-vous que le service virtuel approprié est inclus dans la liste des backends.

Si votre problème n'est toujours pas résolu, envisagez d'en ouvrir un GitHub ou contactez le AWS support.