Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Résolution des problèmes liés à App Mesh
**Important**
Avis de fin de support : le 30 septembre 2026, AWS le support de. 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 [intitulé Migration from AWS App Mesh to Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
Ce chapitre décrit les meilleures pratiques de résolution des problèmes et les problèmes courants que vous pouvez rencontrer lors de l'utilisation d'App Mesh. Sélectionnez l'un des domaines suivants pour passer en revue les meilleures pratiques et les problèmes courants dans ce domaine.
**Topics**
+ [Meilleures pratiques de résolution des problèmes liés à App Mesh](troubleshooting-best-practices.md)
+ [Résolution des problèmes de configuration d'App Mesh](troubleshooting-setup.md)
+ [Résolution des problèmes de connectivité App Mesh](troubleshooting-connectivity.md)
+ [Résolution des problèmes liés au dimensionnement de l'App Mesh](troubleshooting-scaling.md)
+ [Résolution des problèmes liés à l'observabilité de l'App Mesh](troubleshooting-observability.md)
+ [Résolution des problèmes de sécurité liés à App Mesh](troubleshooting-security.md)
+ [Résolution des problèmes liés à App Mesh Kubernetes](troubleshooting-kubernetes.md)
# Meilleures pratiques de résolution des problèmes liés à App Mesh
**Important**
Avis de fin de support : le 30 septembre 2026, AWS le support de. 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 [intitulé Migration from AWS App Mesh to Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
Nous vous recommandons de suivre les meilleures pratiques décrites dans cette rubrique pour résoudre les problèmes liés à l'utilisation d'App Mesh.
## Activer l'interface d'administration du proxy Envoy
Le proxy Envoy est fourni avec une interface d'administration que vous pouvez utiliser pour découvrir la configuration et les statistiques et pour exécuter d'autres fonctions administratives telles que le drainage des connexions. Pour plus d'informations, consultez la section [Interface d'administration](https://www.envoyproxy.io/docs/envoy/latest/operations/admin) dans la documentation d'Envoy.
Si vous utilisez le point de terminaison géré[Image de l'envoyé](envoy.md), le point de terminaison d'administration est activé par défaut sur le port 9901. Les exemples fournis dans [Résolution des problèmes de configuration d'App Mesh](troubleshooting-setup.md) affichent l'exemple d'URL du point de terminaison d'administration sous la forme`http://my-app.default.svc.cluster.local:9901/`.
**Note**
Le terminal d'administration ne doit jamais être exposé à l'Internet public. En outre, nous vous recommandons de surveiller les journaux des points de terminaison d'administration, qui sont définis par la variable d'`ENVOY_ADMIN_ACCESS_LOG_FILE`environnement sur « `/tmp/envoy_admin_access.log` par défaut ».
## Activer l'intégration d'Envoy DogStats D pour le déchargement métrique
Le proxy Envoy peut être configuré pour décharger les statistiques relatives au trafic OSI des couches 4 et 7 et à l'état des processus internes. Bien que cette rubrique explique comment utiliser ces statistiques sans les décharger sur des serveurs tels que CloudWatch Metrics et Prometheus, le fait de disposer de ces statistiques dans un emplacement centralisé pour toutes vos applications peut vous aider à diagnostiquer les problèmes et à confirmer le comportement plus rapidement. Pour plus d'informations, consultez [Using Amazon CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) et la documentation [Prometheus](https://prometheus.io/docs/introduction/overview/).
Vous pouvez configurer les métriques DogStats D en définissant les paramètres définis dans[DogStatsVariables D](envoy-config.md#envoy-dogstatsd-config). Pour plus d'informations sur DogStats D, consultez la documentation [DogStatsD.](https://docs.datadoghq.com/developers/dogstatsd/?tab=hostagent) Vous trouverez une démonstration du transfert des métriques vers les AWS CloudWatch métriques dans l'[App Mesh, avec la présentation des principes de base d'Amazon ECS.](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-ecs-basics) GitHub
## Activer les journaux d'accès
Nous vous recommandons d'activer les journaux d'accès sur votre [Passerelles virtuelles](virtual_gateways.md) ordinateur [Nœuds virtuels](virtual_nodes.md) et de découvrir les détails du trafic transitant entre vos applications. Pour plus d'informations, consultez la section [Journalisation des accès](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/access_logging) dans la documentation d'Envoy. Les journaux fournissent des informations détaillées sur le comportement du trafic des couches 4 et 7 de l'OSI. Lorsque vous utilisez le format par défaut d'Envoy, vous pouvez analyser les journaux d'accès avec CloudWatch Logs [Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) à l'aide de l'instruction d'analyse suivante.
```
parse @message "[*] \"* * *\" * * * * * * * * * * *" as StartTime, Method, Path, Protocol, ResponseCode, ResponseFlags, BytesReceived, BytesSent, DurationMillis, UpstreamServiceTimeMillis, ForwardedFor, UserAgent, RequestId, Authority, UpstreamHost
```
## Activer la journalisation du débogage d'Envoy dans les environnements de pré-production
Nous vous recommandons de définir le niveau de journalisation du proxy Envoy sur `debug` un environnement de pré-production. Les journaux de débogage peuvent vous aider à identifier les problèmes avant d'intégrer la configuration App Mesh associée à votre environnement de production.
Si vous utilisez l'[image Envoy](envoy.md), vous pouvez définir le niveau de journalisation `debug` via la variable d'`ENVOY_LOG_LEVEL`environnement.
**Note**
Nous déconseillons d'utiliser ce `debug` niveau dans les environnements de production. La définition du niveau de manière à `debug` augmenter la journalisation peut affecter les performances et le coût global des journaux déchargés vers des solutions telles que [CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html).
Lorsque vous utilisez le format par défaut d'Envoy, vous pouvez analyser les journaux de processus avec CloudWatch Logs [Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) à l'aide de l'instruction d'analyse suivante :
```
parse @message "[*][*][*][*] [*] *" as Time, Thread, Level, Name, Source, Message
```
## Surveillez la connectivité du proxy Envoy avec le plan de contrôle App Mesh
Nous vous recommandons de surveiller les métriques Envoy `control_plane.connected_state` pour vous assurer que le proxy Envoy communique avec le plan de contrôle App Mesh pour récupérer les ressources de configuration dynamique. Pour plus d'informations, consultez [la section Serveur de gestion](https://www.envoyproxy.io/docs/envoy/latest/configuration/overview/mgmt_server.html).
# Résolution des problèmes de configuration d'App Mesh
**Important**
Avis de fin de support : le 30 septembre 2026, AWS le support de. 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 [intitulé Migration from AWS App Mesh to Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
Cette rubrique décrit les problèmes courants que vous pouvez rencontrer lors de la configuration d'App Mesh.
## Impossible d'extraire l'image du conteneur Envoy
**Symptômes**
Vous recevez le message d'erreur suivant dans une tâche Amazon ECS. L'Amazon ECR *account ID* et *Region* le message suivant peuvent être différents, selon le référentiel Amazon ECR d'où vous avez extrait l'image du conteneur.
```
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'
```
**Résolution**
Cette erreur indique que le rôle d'exécution de tâche utilisé n'est pas autorisé à communiquer avec Amazon ECR et ne peut pas extraire l'image du conteneur Envoy du référentiel. Le rôle d'exécution de tâche attribué à votre tâche Amazon ECS nécessite une politique IAM comportant les déclarations suivantes :
```
{
"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"
}
```
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Impossible de se connecter au service de gestion App Mesh Envoy
**Symptômes**
Votre proxy Envoy ne parvient pas à se connecter au service de gestion App Mesh Envoy. Vous êtes en train de voir :
+ Erreurs de connexion refusée
+ Délai d’expiration de connexion
+ Erreurs lors de la résolution du point de terminaison du service de gestion App Mesh Envoy
+ Erreurs gRPC
**Résolution**
Assurez-vous que votre proxy Envoy a accès à Internet ou à un point de [terminaison VPC](vpc-endpoints.md) privé et que vos [groupes de sécurité](https://docs.aws.amazon.com//vpc/latest/userguide/VPC_SecurityGroups.html) autorisent le trafic sortant sur le port 443. Les points de terminaison du service de gestion Envoy public d'App Mesh suivent le format du nom de domaine complet (FQDN).
```
# App Mesh Production Endpoint
appmesh-envoy-management.Region-code.amazonaws.com
# App Mesh Preview Endpoint
appmesh-preview-envoy-management.Region-code.amazonaws.com
```
Vous pouvez déboguer votre connexion à EMS à l'aide de la commande ci-dessous. Cela envoie une demande gRPC valide mais vide au service de gestion Envoy.
```
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
```
Si vous recevez ces messages en retour, votre connexion à Envoy Management Service est fonctionnelle. Pour le débogage des erreurs liées au gRPC, consultez les erreurs [dans Envoy déconnecté du service de gestion App Mesh Envoy avec un texte](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes) d'erreur.
```
grpc-status: 16
grpc-message: Missing Authentication Token
```
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Envoy s'est déconnecté du service de gestion App Mesh Envoy avec un texte d'erreur
**Symptômes**
Votre proxy Envoy ne parvient pas à se connecter au service de gestion App Mesh Envoy et à recevoir sa configuration. Les journaux de votre proxy Envoy contiennent une entrée de journal comme celle-ci.
```
gRPC config stream closed: gRPC status code, message
```
**Résolution**
Dans la plupart des cas, le message du journal doit indiquer le problème. Le tableau suivant répertorie les codes d'état gRPC les plus courants que vous pouvez voir, leurs causes et leurs résolutions.
| Code d'état gRPC | Cause | Résolution |
| --- | --- | --- |
| 0 | Déconnectez-vous gracieusement du service de gestion Envoy. | Il n'y a aucun problème. App Mesh déconnecte parfois les proxys Envoy avec ce code d'état. Envoy se reconnectera et continuera à recevoir des mises à jour. |
| 3 | Le point de terminaison du maillage (nœud virtuel ou passerelle virtuelle), ou l'une de ses ressources associées, est introuvable. | Vérifiez votre configuration Envoy pour vous assurer qu'elle porte le nom approprié de la ressource App Mesh qu'elle représente. Si votre ressource App Mesh est intégrée à d'autres AWS ressources, telles que des AWS Cloud Map espaces de noms ou des certificats ACM, assurez-vous que ces ressources existent. |
| 7 | Le proxy Envoy n'est pas autorisé à effectuer une action, telle que se connecter au service de gestion Envoy ou récupérer les ressources associées. | Assurez-vous de [créer une politique IAM contenant les déclarations de politique](proxy-authorization.md#create-iam-policy) appropriées pour App Mesh et les autres services et d'associer cette politique à l'utilisateur ou au rôle IAM que votre proxy Envoy utilise pour se connecter au service de gestion Envoy. |
| 8 | Le nombre de proxys Envoy pour une ressource App Mesh donnée dépasse le quota de service au niveau du compte. | Consultez [Quotas de service App Mesh](service-quotas.md) pour plus d'informations sur les quotas de compte par défaut et sur la procédure à suivre pour demander une augmentation de quota. |
| 16 | Le proxy Envoy ne dispose pas d'informations d'authentification valides pour AWS. | Assurez-vous que l'Envoy dispose des informations d'identification appropriées pour se connecter aux AWS services via un utilisateur ou un rôle IAM. Un problème connu, [\$124136](https://github.com/envoyproxy/envoy/issues/24136), dans Envoy pour les versions v1.24 précédentes ne parvient pas à récupérer les informations d'identification si le processus Envoy utilise des descripteurs de 1024 fichiers supplémentaires. Cela se produit lorsque Envoy dessert un volume de trafic élevé. Vous pouvez confirmer ce problème en vérifiant la présence du texte « A libcurl function was given a bad argument » dans les journaux Envoy au niveau du débogage. Pour atténuer ce problème, passez à la version Envoy v1.25.1.0-prod ou à une version ultérieure. |
Vous pouvez observer les codes d'état et les messages de votre proxy Envoy avec [Amazon CloudWatch Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) en utilisant la requête suivante :
```
filter @message like /gRPC config stream closed/
| parse @message "gRPC config stream closed: *, *" as StatusCode, Message
```
Si le message d'erreur fourni ne vous a pas aidé ou si votre problème n'est toujours pas résolu, envisagez d'ouvrir un [GitHub problème](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here).
## Échec de la vérification de l'état du conteneur Envoy, de la sonde de disponibilité ou de la sonde de vivacité
**Symptômes**
Votre proxy Envoy échoue aux contrôles de santé d'une tâche Amazon ECS, d'une instance Amazon EC2 ou d'un pod Kubernetes. Par exemple, vous interrogez l'interface d'administration d'Envoy à l'aide de la commande suivante et vous recevez un statut autre que`LIVE`.
```
curl -s http://my-app.default.svc.cluster.local:9901/server_info | jq '.state'
```
**Résolution**
Voici une liste des étapes de correction en fonction de l'état renvoyé par le proxy Envoy.
+ `PRE_INITIALIZING`ou `INITIALIZING` — Le proxy Envoy n'a pas encore reçu de configuration ou ne peut pas se connecter et récupérer la configuration depuis le service de gestion App Mesh Envoy. L'Envoy reçoit peut-être une erreur du service de gestion Envoy lorsqu'il tente de se connecter. Pour plus d'informations, consultez les erreurs dans[Envoy s'est déconnecté du service de gestion App Mesh Envoy avec un texte d'erreur](#ts-setup-grpc-error-codes).
+ `DRAINING`— Le proxy Envoy a commencé à épuiser les connexions en réponse à une `/drain_listeners` demande `/healthcheck/fail` ou sur l'interface d'administration d'Envoy. Nous vous déconseillons d'invoquer ces chemins sur l'interface d'administration, sauf si vous êtes sur le point de mettre fin à votre tâche Amazon ECS, à votre instance Amazon EC2 ou à votre pod Kubernetes.
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Health : le contrôle de santé entre l'équilibreur de charge et le point de terminaison du maillage échoue
**Symptômes**
Votre point de terminaison de maillage est considéré comme sain par le contrôle de l'état du conteneur ou la sonde de disponibilité, mais le contrôle de santé entre l'équilibreur de charge et le point de terminaison du maillage échoue.
**Résolution**
Pour résoudre le problème, effectuez les tâches suivantes.
+ Assurez-vous que le [groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) associé à votre point de terminaison maillé accepte le trafic entrant sur le port que vous avez configuré pour votre bilan de santé.
+ Assurez-vous que le contrôle de santé aboutit systématiquement lorsqu'il est demandé manuellement, par exemple, depuis un [hôte bastion au sein de votre VPC](https://aws.amazon.com/quickstart/architecture/linux-bastion/).
+ Si vous configurez un contrôle de santé pour un nœud virtuel, nous vous recommandons d'implémenter un point de terminaison de contrôle de santé dans votre application, par exemple, /ping pour HTTP. Cela garantit que le proxy Envoy et votre application sont routables depuis l'équilibreur de charge.
+ Vous pouvez utiliser n'importe quel type d'équilibreur de charge élastique pour le nœud virtuel, en fonction des fonctionnalités dont vous avez besoin. Pour plus d'informations, consultez la section [Fonctionnalités d'Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/features/#compare).
+ Si vous configurez un contrôle de santé pour une [passerelle virtuelle](virtual_gateways.md), nous vous recommandons d'utiliser un [équilibreur de charge réseau](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html) avec un contrôle de santé TCP ou TLS sur le port d'écoute de la passerelle virtuelle. Cela garantit que l'écouteur de passerelle virtuelle est amorcé et prêt à accepter les connexions.
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## La passerelle virtuelle n'accepte pas le trafic sur les ports 1024 ou moins
**Symptômes**
Votre passerelle virtuelle n'accepte pas le trafic sur le port 1024 ou moins, mais accepte le trafic sur un numéro de port supérieur à 1024. Par exemple, vous interrogez les statistiques d'Envoy avec la commande suivante et vous recevez une valeur autre que zéro.
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "update_rejected"
```
Vous pouvez voir un texte similaire au texte suivant dans vos journaux décrivant un échec de liaison à un port privilégié :
```
gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) lds_ingress_0.0.0.0_port_: cannot bind '0.0.0.0:': Permission denied
```
**Résolution**
Pour résoudre le problème, l'utilisateur spécifié pour la passerelle doit disposer de la fonctionnalité Linux`CAP_NET_BIND_SERVICE`. Pour plus d'informations, consultez les [sections Fonctionnalités](https://www.man7.org/linux/man-pages/man7/capabilities.7.html) dans le manuel du programmeur [Linux, Paramètres Linux dans les paramètres](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_linuxparameters) de définition des tâches ECS et [Définir les capacités d'un conteneur](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) dans la documentation de Kubernetes.
**Important**
Fargate doit utiliser une valeur de port supérieure à 1024.
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
# Résolution des problèmes de connectivité App Mesh
**Important**
Avis de fin de support : le 30 septembre 2026, AWS le support de. 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 [intitulé Migration from AWS App Mesh to Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
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 le problème [Name VirtualServices by any hostname or FQDN](https://github.com/aws/aws-app-mesh-roadmap/issues/65) GitHub . Les services virtuels dans 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 sans boucle, par exemple pour le `10.10.10.10` nom du service virtuel. L'`A`enregistrement 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
+ Dans un serveur DNS tiers que vous gérez
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Impossible de se connecter à un backend de service virtuel
**Symptômes**
Votre application n'est pas en mesure d'établir une connexion à un service virtuel défini comme un backend sur votre nœud virtuel. Lorsque vous essayez d'établir une connexion, celle-ci peut échouer complètement ou la demande, du point de vue de l'application, 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](proxy-authorization.md) appropriée est activée. Pour une end-to-end présentation détaillée, consultez [Getting Started with App Mesh et Amazon ECS.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/appmesh-getting-started.html)
+ 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](https://hub.helm.sh/charts/aws/appmesh-controller) sur Helm Hub ou [Tutoriel : Configurer l'intégration d'App Mesh avec Kubernetes](https://docs.aws.amazon.com/app-mesh/latest/userguide/mesh-k8s-integration.html).
+ Pour Amazon EC2, assurez-vous d'avoir configuré votre instance Amazon EC2 pour transmettre le trafic App Mesh par proxy. Pour plus d'informations, consultez la section [Services de mise à jour](https://docs.aws.amazon.com/app-mesh/latest/userguide/appmesh-getting-started.html#update-services).
+ 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 vérifiant les statistiques d'Envoy pour le champ`control_plane.connected_state`. Pour plus d'informations`control_plane.connected_state`, consultez la section [Surveiller la connectivité du proxy Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-best-practices.html#ts-bp-enable-envoy-control-plane-connected-state) dans nos **meilleures pratiques de dépannage**.
Si l'Envoy a réussi à établir la connexion initialement, mais qu'il a ensuite été déconnecté et n'a jamais été reconnecté, voir [Envoy s'est déconnecté du service de gestion App Mesh Envoy avec un texte d'erreur](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes) pour savoir 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 (routeur virtuel ou nœud virtuel).
+ Lorsque vous utilisez Envoy comme proxy HTTP, si vous voyez du trafic sortant arriver au `cluster.cds_egress_*_mesh-allow-all` 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 du service réel comme nom du service virtuel, car le proxy Envoy communique avec les autres services virtuels par le biais de leurs noms.
Pour plus d'informations, consultez la section [Services virtuels](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_services.html).
+ 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 de se diriger ne possède aucun point de terminaison résolu ou aucun point de terminaison sain. Assurez-vous que le nœud virtuel cible possède les paramètres de découverte des services et de vérification de l'état corrects.
Si les demandes adressées au service échouent lors du déploiement ou du dimensionnement du service virtuel principal, suivez les instructions figurant dans[Certaines demandes échouent avec le code d'état HTTP `503` lorsqu'un service virtuel dispose d'un fournisseur de nœuds virtuels](#ts-connectivity-virtual-node-provider).
+ `No cluster match for URL`— Cela se produit très probablement lorsqu'une demande est envoyée à 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 demandes de l'application sont envoyées vers une route prise en charge en vérifiant que le chemin et les en-têtes de requête HTTP sont corrects.
+ `No matching filter chain found`— Cela est probablement dû au fait qu'une demande est envoyée à un service virtuel sur un port non valide. Assurez-vous que les demandes provenant 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, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Impossible de se connecter à un service externe
**Symptômes**
Votre application ne parvient pas à se connecter à un service en dehors du maillage, tel que`amazon.com`.
**Résolution**
Par défaut, App Mesh n'autorise pas le trafic sortant des applications situées dans le 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](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html) de la ressource de maillage sur. `ALLOW_ALL` Ce paramètre permet à n'importe quelle application au sein 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 externe`example.com`, vous pouvez créer un service virtuel nommé `example.com` avec un routeur et une route virtuels qui envoie tout le trafic vers un nœud virtuel dont le nom d'hôte de découverte du `example.com` service DNS est.
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## 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`), telles qu'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, le message d'erreur suivant provient 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](https://github.com/aws/aws-app-mesh-roadmap/issues/62). Cette erreur se produit car l'écouteur sortant dans Envoy configuré par App Mesh ajoute le filtre d'écouteur Envoy TLS Inspector. Pour plus d'informations, consultez [TLS Inspector](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/tls_inspector#config-listener-filters-tls-inspector) dans la documentation d'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 [Initial Handshake](https://dev.mysql.com/doc/internals/en/initial-handshake.html) dans la documentation MySQL. Comme le serveur envoie le premier paquet, l'inspection 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 de 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 le protocole STMP.**
**Important**
Bien que les ports SMTP standard soient `25``587`, et`465`, 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](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-kubernetes.html#create-update-services) pour Kubernetes, Services de [mise à jour pour](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ecs.html#update-services) Amazon ECS ou [Services de mise à jour pour Amazon EC2](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ec2.html#update-services).
Si votre problème n'est toujours pas résolu, vous pouvez nous fournir des informations sur ce que vous rencontrez en lien avec le [GitHub problème](https://github.com/aws/aws-app-mesh-roadmap/issues/62) existant ou contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).
## 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 du protocole TCP dans la définition de l'App Mesh [PortMapping](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_PortMapping.html).
**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 activé](https://github.com/aws/aws-app-mesh-roadmap/issues/195). GitHub App Mesh n'autorise actuellement pas plusieurs destinations de backend modélisées en TCP à partager le même port en raison des restrictions relatives aux informations fournies au proxy Envoy au niveau de la couche 4 de l'OSI. Pour vous assurer que le trafic TCP peut être acheminé de manière appropriée 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 tandis que le proxy Envoy continue d'utiliser le port défini dans le nœud virtuel.
+ Si la destination modélisée en TCP est un serveur MySQL ou tout autre protocole basé sur le protocole TCP dans lequel le serveur envoie les premiers paquets après la connexion, consultez. [Impossible de se connecter à un serveur MySQL ou SMTP](#ts-connectivity-troubleshooting-mysql-and-smtp)
Si votre problème n'est toujours pas résolu, vous pouvez nous fournir des informations sur ce que vous rencontrez en lien avec le [GitHub problème](https://github.com/aws/aws-app-mesh-roadmap/issues/195) existant ou contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).
## La connectivité réussit à ce que le service ne soit pas répertorié en tant que 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 en tant que backend de service virtuel sur votre nœud virtuel.
**Résolution**
Si les demandes aboutissent à une destination qui n'a pas été modélisée dans l'App Mesh APIs, la cause la plus probable est que le type de [filtre sortant](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html) du maillage a été défini sur. `ALLOW_ALL` Lorsque le filtre sortant est défini sur`ALLOW_ALL`, une demande sortante provenant de votre application qui ne correspond pas à une destination modélisée (backend) sera 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 `DROP_ALL` et `egress_filter` l'activation du protocole TLS 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, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Certaines demandes échouent avec le code d'état HTTP `503` lorsqu'un service virtuel dispose d'un fournisseur de nœuds virtuels
**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, voir [Politique de nouvelle tentative sur le fournisseur de nœuds virtuels pour un service virtuel activé](https://github.com/aws/aws-app-mesh-roadmap/issues/194) GitHub. Lorsque vous utilisez un nœud virtuel en tant que fournisseur d'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 la route enfant.
Pour réduire le nombre d'échecs de 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 de requêtes adressées à vos applications, consultez[Meilleures pratiques en matière d'App Mesh](best-practices.md).
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## 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 est établie 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 de valeurs pour le `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](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#proxyConfiguration).
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## La connectivité réussit à assurer le service, mais la demande entrante n'apparaît pas dans les journaux d'accès, les traces ou les métriques 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 du proxy Envoy.
**Résolution**
Il s'agit d'un problème connu. Pour plus d'informations, consultez le problème de [configuration des règles iptables](https://github.com/aws/aws-app-mesh-roadmap/issues/166) sur Github. Le proxy Envoy intercepte uniquement le trafic entrant vers le port écouté par le nœud virtuel correspondant. Les demandes 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, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## La définition des variables d'`HTTPS_PROXY`environnement`HTTP_PROXY`/au niveau du conteneur ne fonctionne pas comme prévu.
**Symptômes**
Lorsque HTTP\$1PROXY/HTTPS\$1PROXY est défini comme variable d'environnement dans :
+ Conteneur d'applications dans la définition des tâches avec App Mesh activé, les demandes envoyées à l'espace de noms des services App Mesh recevront des réponses `HTTP 500` d'erreur de la part du sidecar Envoy.
+ Conteneur Envoy dans la définition des tâches avec App Mesh activé, les demandes provenant du sidecar Envoy ne passeront pas par le serveur `HTTPS` proxy`HTTP`/et la variable d'environnement ne fonctionnera pas.
**Résolution**
Pour le conteneur d'applications :
App Mesh fonctionne en faisant passer le trafic au sein de votre tâche par le proxy Envoy. `HTTP_PROXY`/`HTTPS_PROXY`configuration remplace ce comportement en configurant le trafic de 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 transfert par 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 le CIDR/namespace de votre maillage, localhost et les points de terminaison 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 les proxys génériques. Il est déconseillé de définir ces variables.
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Expiration des demandes en amont, même après avoir défini le délai d'expiration pour les itinéraires.
**Symptômes**
Vous avez défini le délai d'expiration pour :
+ Les itinéraires, mais vous recevez toujours une erreur de délai d'attente de la demande en amont.
+ L'écouteur du nœud virtuel, le délai d'expiration et le délai de nouvelle tentative pour les itinéraires, mais vous obtenez toujours une erreur de délai d'expiration de la demande en amont.
**Résolution**
Pour que les demandes à latence élevée supérieure à 15 secondes soient traitées avec succès, vous devez spécifier un délai d'attente au niveau de la route et au niveau de l'écouteur du nœud virtuel.
Si vous spécifiez un délai d'attente d'itinéraire supérieur à la valeur par défaut de 15 secondes, assurez-vous que le délai d'expiration est également spécifié pour l'écouteur pour tous les nœuds virtuels participants. Toutefois, si vous réduisez le délai d'expiration à une valeur inférieure à la valeur par défaut, il est facultatif de mettre à jour le délai d'expiration au niveau des 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](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html) virtuels](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html).
**Si vous avez défini une **politique de nouvelles tentatives**, la durée que vous spécifiez pour le délai d'expiration des demandes doit toujours être supérieure ou égale au *délai de nouvelles tentatives* multiplié par le nombre *maximum de tentatives que vous avez défini dans la politique de nouvelles tentatives*.** Cela permet à votre demande, avec toutes les nouvelles tentatives, de se terminer avec succès. Pour plus d'informations, consultez la section [itinéraires](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html).
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Envoy répond par une requête HTTP Bad.
**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 constatons que :
+ 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 la version 2 du protocole proxy (PPv2) sur les [attributs du groupe cible](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-group-attributes) de votre NLB.
À ce jour, PPv2 il 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-le PPv2 en définissant l'attribut suivant sur : `false`
```
service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: proxy_protocol_v2.enabled
```
Consultez les [annotations du AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/#resource-attributestrue) pour plus de détails sur les attributs des ressources NLB.
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Impossible de configurer correctement le délai d'expiration.
**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, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
# Résolution des problèmes liés au dimensionnement de l'App Mesh
**Important**
Avis de fin de support : le 30 septembre 2026, AWS le support de. 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 [intitulé Migration from AWS App Mesh to Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
Cette rubrique décrit les problèmes courants que vous pouvez rencontrer lors de la mise à l'échelle d'App Mesh.
## La connectivité échoue et les vérifications de l'état du conteneur échouent lorsque le dimensionnement d'une passerelle virtuelle node/virtual dépasse les 50 répliques
**Symptômes**
Lorsque vous augmentez le nombre de répliques, telles que les tâches Amazon ECS, les pods Kubernetes ou les instances Amazon EC2, pour une node/virtual passerelle virtuelle au-delà de 50, les contrôles de santé des conteneurs Envoy pour les nouveaux Envoys ou ceux en cours d'exécution commencent à échouer. Les applications en aval qui envoient du trafic vers la node/virtual passerelle virtuelle commencent à rencontrer des échecs de requête avec le code d'état HTTP`503`.
**Résolution**
Le quota par défaut d'App Mesh pour le nombre d'envoyés par node/virtual passerelle virtuelle est de 50. Lorsque le nombre d'envoyés en cours d'exécution dépasse ce quota, les nouveaux envoyés et ceux en cours d'exécution ne parviennent pas à se connecter au service de gestion Envoy d'App Mesh avec le code d'état gRPC (). `8` `RESOURCE_EXHAUSTED` Ce quota peut être augmenté. Pour de plus amples informations, veuillez consulter [Quotas de service App Mesh](service-quotas.md).
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Les demandes échouent `503` lorsqu'un backend de service virtuel évolue horizontalement vers l'extérieur ou vers l'intérieur
**Symptômes**
Lorsqu'un service virtuel principal est étendu ou intégré horizontalement, les demandes des applications en aval échouent avec un code d'`HTTP 503`état.
**Résolution**
App Mesh recommande plusieurs approches pour atténuer les cas de défaillance tout en dimensionnant les applications horizontalement. Pour obtenir des informations détaillées sur la manière de prévenir ces défaillances, consultez[Meilleures pratiques en matière d'App Mesh](best-practices.md).
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Le conteneur Envoy se bloque avec segfault en cas de charge accrue
**Symptômes**
En cas de charge de trafic élevée, le proxy Envoy se bloque en raison d'une erreur de segmentation (code de sortie Linux`139`). Les journaux de processus d'Envoy contiennent une déclaration comme celle-ci.
```
Caught Segmentation fault, suspect faulting address 0x0"
```
**Résolution**
Le proxy Envoy a probablement dépassé la limite nofile ulimit par défaut du système d'exploitation, la limite du nombre de fichiers qu'un processus peut ouvrir à la fois. Cette violation est due au fait que le trafic entraîne l'augmentation du nombre de connexions, qui consomment des sockets supplémentaires du système d'exploitation. Pour résoudre ce problème, augmentez la valeur ulimit nofile sur le système d'exploitation hôte. Si vous utilisez Amazon ECS, cette limite peut être modifiée via les [paramètres Ulimit](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html) des [limites de ressources](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_limits) de la définition de tâche.
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## L'augmentation des ressources par défaut n'est pas reflétée dans les limites de service
**Symptômes**
Après avoir augmenté la limite par défaut des ressources App Mesh, la nouvelle valeur n'est pas prise en compte lorsque vous examinez vos limites de service.
**Résolution**
Bien que les nouvelles limites ne soient pas affichées actuellement, les clients peuvent toujours les appliquer.
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## L'application se bloque en raison d'un grand nombre d'appels de bilan de santé.
**Symptômes**
Après avoir activé les contrôles de santé actifs pour un nœud virtuel, le nombre d'appels de contrôle de santé augmente. L'application se bloque en raison de l'augmentation considérable du nombre d'appels de vérification de santé effectués vers l'application.
**Résolution**
Lorsque le contrôle de santé actif est activé, chaque point de terminaison Envoy du terminal en aval (client) envoie des demandes d'état à chaque point de terminaison du cluster en amont (serveur) afin de prendre des décisions de routage. Par conséquent, le nombre total de demandes de bilan de santé serait de `number of client Envoys` \$1 `number of server Envoys` \$1`active health check frequency`.
Pour résoudre ce problème, modifiez la fréquence de la sonde de contrôle de santé, ce qui réduirait le volume total des sondes de contrôle de santé. Outre les bilans de santé actifs, App Mesh permet de configurer la [détection des valeurs aberrantes](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_OutlierDetection.html) comme moyen de vérification passive de l'état de santé. Utilisez la détection des valeurs aberrantes pour configurer le moment où il convient de supprimer un hôte spécifique en fonction `5xx` des réponses consécutives.
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
# Résolution des problèmes liés à l'observabilité de l'App Mesh
**Important**
Avis de fin de support : le 30 septembre 2026, AWS le support de. 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 [intitulé Migration from AWS App Mesh to Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
Cette rubrique décrit les problèmes courants que vous pouvez rencontrer avec l'observabilité d'App Mesh.
## Impossible de voir les AWS X-Ray traces de mes applications
**Symptômes**
Votre application dans App Mesh n'affiche pas les informations de suivi X-Ray dans la console X-Ray ou APIs.
**Résolution**
Pour utiliser X-Ray dans App Mesh, vous devez configurer correctement les composants afin de permettre la communication entre votre application, les conteneurs annexes et le service X-Ray. Suivez les étapes suivantes pour vérifier que X-Ray a été correctement configuré :
+ Assurez-vous que le protocole d'écoute App Mesh Virtual Node n'est pas défini comme`TCP`.
+ Assurez-vous que le conteneur X-Ray déployé avec votre application expose le port UDP `2000` et s'exécute en tant qu'utilisateur. `1337` Pour plus d'informations, consultez l'[exemple d'Amazon ECS X-Ray](https://github.com/aws/aws-app-mesh-examples/blob/main/walkthroughs/howto-ecs-basics/deploy/2-meshify.yaml#L374-L386) sur GitHub.
+ Assurez-vous que le suivi est activé sur le conteneur Envoy. Si vous utilisez l'[image App Mesh Envoy](envoy.md), vous pouvez activer X-Ray en définissant la variable d'`ENABLE_ENVOY_XRAY_TRACING`environnement sur une valeur de `1` et la variable d'`XRAY_DAEMON_PORT`environnement sur`2000`.
+ Si vous avez instrumenté X-Ray dans le code de votre application avec l'un des [langages spécifiques SDKs , assurez-vous qu'il est correctement configuré en suivant les guides correspondant à votre langue](https://docs.aws.amazon.com/xray/index.html).
+ Si tous les éléments précédents sont correctement configurés, consultez les journaux des conteneurs X-Ray pour détecter les erreurs et suivez les instructions de la section [Dépannage AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-troubleshooting.html). Vous trouverez une explication plus détaillée de l'intégration de X-Ray dans App Mesh dans [Integrating X-Ray with App Mesh](https://aws.amazon.com/blogs/compute/integrating-aws-x-ray-with-aws-app-mesh/).
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Impossible de voir les métriques Envoy pour mes applications dans CloudWatch les métriques Amazon
**Symptômes**
Votre application dans App Mesh n'émet pas de métriques générées par le proxy Envoy vers CloudWatch des métriques.
**Résolution**
Lorsque vous utilisez CloudWatch des métriques dans App Mesh, vous devez configurer correctement plusieurs composants pour permettre la communication entre votre proxy Envoy, le sidecar de l' CloudWatch agent et le service de CloudWatch métriques. Suivez les étapes suivantes pour vérifier que CloudWatch les métriques du proxy Envoy ont été correctement configurées :
+ Assurez-vous que vous utilisez l'image de l' CloudWatch agent pour App Mesh. Pour plus d'informations, consultez la section [ CloudWatchAgent App Mesh](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent) activé GitHub.
+ Assurez-vous d'avoir correctement configuré l' CloudWatch agent pour App Mesh en suivant les instructions d'utilisation spécifiques à la plate-forme. Pour plus d'informations, consultez la section [ CloudWatchAgent App Mesh](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent#usage) activé GitHub.
+ Si tous les éléments précédents sont correctement configurés, consultez les journaux du conteneur de l' CloudWatch agent pour détecter les erreurs et suivez les instructions fournies dans la section [Dépannage de l' CloudWatch agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html).
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Impossible de configurer des règles d'échantillonnage personnalisées pour les AWS X-Ray traces
**Symptômes**
Votre application utilise le traçage X-Ray, mais vous ne parvenez pas à configurer les règles d'échantillonnage pour vos traces.
**Résolution**
Étant donné qu'App Mesh Envoy ne prend actuellement pas en charge la **configuration d'échantillonnage Dynamic X-Ray**, les solutions de contournement suivantes sont disponibles.
Si votre version d'Envoy est `1.19.1` ou ultérieure, les options suivantes s'offrent à vous.
+ Pour définir uniquement le taux d'échantillonnage, utilisez la variable d'`XRAY_SAMPLING_RATE`environnement sur le conteneur Envoy. La valeur doit être spécifiée sous forme décimale entre `0` et `1.00` (100 %). Pour de plus amples informations, veuillez consulter [AWS X-Ray variables](envoy-config.md#envoy-xray-config).
+ Pour configurer les règles d'échantillonnage personnalisées localisées pour le traceur X-Ray, utilisez la variable d'`XRAY_SAMPLING_RULE_MANIFEST`environnement pour spécifier un chemin de fichier dans le système de fichiers du conteneur Envoy. Pour plus d'informations, consultez la section [Règles d'échantillonnage](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling) dans le *Guide du AWS X-Ray développeur*.
Si votre version d'Envoy est antérieure à`1.19.1`, procédez comme suit.
+ Utilisez la variable d'`ENVOY_TRACING_CFG_FILE`environnement pour modifier votre taux d'échantillonnage. Pour de plus amples informations, veuillez consulter [Variables de configuration Envoy](envoy-config.md). Spécifiez une configuration de suivi personnalisée et définissez des règles d'échantillonnage locales. Pour plus d'informations, consultez la section [Configuration d'Envoy X-Ray](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/trace/v3/xray.proto.html#config-trace-v3-xrayconfig).
+ Exemple de configuration de suivi personnalisée pour la variable d'`ENVOY_TRACING_CFG_FILE`environnement :
```
tracing:
http:
name: envoy.tracers.xray
typedConfig:
"@type": type.googleapis.com/envoy.config.trace.v3.XRayConfig
segmentName: foo/bar
segmentFields:
origin: AWS::AppMesh::Proxy
aws:
app_mesh:
mesh_name: foo
virtual_node_name: bar
daemonEndpoint:
protocol: UDP
address: 127.0.0.1
portValue: 2000
samplingRuleManifest:
filename: /tmp/sampling-rules.json
```
+ Pour plus de détails sur la configuration du manifeste des règles d'échantillonnage dans la `samplingRuleManifest` propriété, consultez [Configuring the X-Ray SDK for Go](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling).
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
# Résolution des problèmes de sécurité liés à App Mesh
**Important**
Avis de fin de support : le 30 septembre 2026, AWS le support de. 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 [intitulé Migration from AWS App Mesh to Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
Cette rubrique décrit les problèmes courants que vous pouvez rencontrer avec la sécurité d'App Mesh.
## Impossible de se connecter à un service virtuel principal avec une politique client TLS
**Symptômes**
Lorsque vous ajoutez une politique client TLS à un backend de service virtuel dans un nœud virtuel, la connectivité à ce backend échoue. Lorsque vous tentez d'envoyer du trafic vers le service principal, les demandes échouent avec un code de `HTTP 503` réponse et le message d'erreur :`upstream connect error or disconnect/reset before headers. reset reason: connection failure`.
**Résolution**
Afin de déterminer la cause première du problème, nous vous recommandons d'utiliser les journaux de processus du proxy Envoy pour vous aider à diagnostiquer le problème. Pour de plus amples informations, veuillez consulter [Activer la journalisation du débogage d'Envoy dans les environnements de pré-production](troubleshooting-best-practices.md#ts-bp-enable-envoy-debug-logging). Utilisez la liste suivante pour déterminer la cause de l'échec de connexion :
+ Assurez-vous que la connectivité au backend fonctionne correctement en excluant les erreurs mentionnées dans. [Impossible de se connecter à un backend de service virtuel](troubleshooting-connectivity.md#ts-connectivity-virtual-service-backend)
+ Dans les journaux de processus d'Envoy, recherchez les erreurs suivantes (enregistrées au niveau du débogage).
```
TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
```
Cette erreur est due à une ou plusieurs des raisons suivantes :
+ Le certificat n'a pas été signé par l'une des autorités de certification définies dans le bundle de confiance relatif à la politique client TLS.
+ Le certificat n'est plus valide (expiré).
+ Le nom alternatif du sujet (SAN) ne correspond pas au nom d'hôte DNS demandé.
+ Assurez-vous que le certificat proposé par le service principal est valide, qu'il est signé par l'une des autorités de certification de votre bundle de confiance pour les politiques client TLS et qu'il répond aux critères définis dans. [Protocole TLS (Transport Layer Security)](tls.md)
+ Si l'erreur que vous recevez est similaire à celle ci-dessous, cela signifie que la demande contourne le proxy Envoy et atteint directement l'application. Lors de l'envoi de trafic, les statistiques sur Envoy ne changent pas, ce qui indique qu'Envoy n'est pas sur le point de déchiffrer le trafic. Dans la configuration du proxy du nœud virtuel, assurez-vous qu'il `AppPorts` contient la bonne valeur que l'application écoute.
```
upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
```
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue-bug-report.md&title=Bug%3A+describe+bug+here) Si vous pensez avoir découvert une faille de sécurité ou si vous avez des questions concernant la sécurité d'App Mesh, consultez les [directives relatives au signalement des AWS vulnérabilités](https://aws.amazon.com/security/vulnerability-reporting/).
## Impossible de se connecter à un service virtuel principal lorsque l'application est à l'origine du protocole TLS
**Symptômes**
Lorsque vous lancez une session TLS depuis une application, plutôt que depuis le proxy Envoy, la connectivité à un service virtuel principal échoue.
**Résolution**
Il s'agit d'un problème connu. Pour plus d'informations, consultez le GitHub problème de [demande de fonctionnalité : négociation TLS entre l'application en aval et le proxy en amont](https://github.com/aws/aws-app-mesh-roadmap/issues/162). Dans App Mesh, l'origine TLS est actuellement prise en charge par le proxy Envoy, mais pas par l'application. Pour utiliser la prise en charge de l'origine TLS au niveau de l'Envoy, désactivez la prise en charge de l'origine TLS dans l'application. Cela permet à l'Envoy de lire les en-têtes des demandes sortantes et de transmettre la demande à la destination appropriée via une session TLS. Pour de plus amples informations, veuillez consulter [Protocole TLS (Transport Layer Security)](tls.md).
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) Si vous pensez avoir découvert une faille de sécurité ou si vous avez des questions concernant la sécurité d'App Mesh, consultez les [directives relatives au signalement des AWS vulnérabilités](https://aws.amazon.com/security/vulnerability-reporting/).
## Impossible d'affirmer que la connectivité entre les proxys Envoy utilise le protocole TLS
**Symptômes**
Votre application a activé la terminaison TLS sur le nœud virtuel ou l'écouteur de passerelle virtuelle, ou l'origine du TLS sur la politique du client TLS principal, mais vous ne pouvez pas affirmer que la connectivité entre les proxys Envoy se produit au cours d'une session négociée par TLS.
**Résolution**
Les étapes définies dans cette résolution utilisent l'interface d'administration d'Envoy et les statistiques d'Envoy. Pour obtenir de l'aide pour les configurer, reportez-vous [Activer l'interface d'administration du proxy Envoy](troubleshooting-best-practices.md#ts-bp-enable-proxy-admin-interface) aux sections et[Activer l'intégration d'Envoy DogStats D pour le déchargement métrique](troubleshooting-best-practices.md#ts-bp-enable-envoy-statsd-integration). Les exemples de statistiques suivants utilisent l'interface d'administration pour des raisons de simplicité.
+ Pour le proxy Envoy effectuant la terminaison du protocole TLS :
+ Assurez-vous que le certificat TLS a été amorcé dans la configuration Envoy à l'aide de la commande suivante.
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
Dans le résultat renvoyé, vous devriez voir au moins une entrée sous `certificates[].cert_chain` pour le certificat utilisé pour la terminaison du protocole TLS.
+ Assurez-vous que le nombre de connexions entrantes réussies avec l'écouteur du proxy est exactement le même que le nombre de poignées de main SSL plus le nombre de sessions SSL réutilisées, comme le montrent les exemples de commandes et de sorties suivants.
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep downstream_cx_total
listener.0.0.0.0_15000.downstream_cx_total: 11
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.connection_error
listener.0.0.0.0_15000.ssl.connection_error: 1
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.handshake
listener.0.0.0.0_15000.ssl.handshake: 9
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.session_reused
listener.0.0.0.0_15000.ssl.session_reused: 1
# Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)
```
+ Pour le proxy Envoy effectuant la création TLS :
+ Assurez-vous que le magasin de confiance TLS a été amorcé dans la configuration Envoy à l'aide de la commande suivante.
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
Vous devriez voir au moins une entrée ci-dessous pour les certificats utilisés `certificates[].ca_certs` pour valider le certificat du backend lors de la création du protocole TLS.
+ Assurez-vous que le nombre de connexions sortantes réussies vers le cluster principal est exactement le même que le nombre de connexions SSL plus le nombre de sessions SSL réutilisées, comme le montrent les exemples de commandes et de résultats suivants.
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep upstream_cx_total
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.upstream_cx_total: 11
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.connection_error
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.connection_error: 1
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.handshake
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.handshake: 9
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.session_reused
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.session_reused: 1
# Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)
```
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) Si vous pensez avoir découvert une faille de sécurité ou si vous avez des questions concernant la sécurité d'App Mesh, consultez les [directives relatives au signalement des AWS vulnérabilités](https://aws.amazon.com/security/vulnerability-reporting/).
## Résolution des problèmes liés au TLS avec Elastic Load Balancing
**Symptômes**
Lorsque vous essayez de configurer un Application Load Balancer ou un Network Load Balancer pour chiffrer le trafic vers un nœud virtuel, les vérifications de connectivité et de santé de l'équilibreur de charge peuvent échouer.
**Résolution**
Afin de déterminer la cause première du problème, vous devez vérifier les points suivants :
+ Pour que le proxy Envoy effectue la terminaison du protocole TLS, vous devez exclure toute erreur de configuration. Suivez les étapes indiquées ci-dessus dans le[Impossible de se connecter à un service virtuel principal avec une politique client TLS](#ts-security-tls-client-policy).
+ Pour l'équilibreur de charge, vous devez examiner la configuration du `TargetGroup:`
+ Assurez-vous que le `TargetGroup` port correspond au port d'écoute défini par le nœud virtuel.
+ Pour les équilibreurs de charge d'application qui créent des connexions TLS via HTTP vers votre service, assurez-vous que le `TargetGroup` protocole est défini sur. `HTTPS` Si des bilans de santé sont utilisés, assurez-vous qu'ils `HealthCheckProtocol` sont définis sur`HTTPS`.
+ Pour les équilibreurs de charge réseau qui créent des connexions TLS via TCP vers votre service, assurez-vous que le `TargetGroup` protocole est défini sur. `TLS` Si des bilans de santé sont utilisés, assurez-vous qu'ils `HealthCheckProtocol` sont définis sur`TCP`.
**Note**
Toute mise à jour `TargetGroup` nécessitant un changement de `TargetGroup` nom.
Une fois cette configuration correctement configurée, votre équilibreur de charge devrait fournir une connexion sécurisée à votre service à l'aide du certificat fourni au proxy Envoy.
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) Si vous pensez avoir découvert une faille de sécurité ou si vous avez des questions concernant la sécurité d'App Mesh, consultez les [directives relatives au signalement des AWS vulnérabilités](https://aws.amazon.com/security/vulnerability-reporting/).
# Résolution des problèmes liés à App Mesh Kubernetes
**Important**
Avis de fin de support : le 30 septembre 2026, AWS le support de. 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 [intitulé Migration from AWS App Mesh to Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
Cette rubrique décrit les problèmes courants que vous pouvez rencontrer lorsque vous utilisez App Mesh avec Kubernetes.
## Les ressources App Mesh créées dans Kubernetes sont introuvables dans App Mesh
**Symptômes**
Vous avez créé les ressources App Mesh à l'aide de la définition de ressource personnalisée (CRD) de Kubernetes, mais les ressources que vous avez créées ne sont pas visibles dans App Mesh lorsque vous utilisez le ou. AWS Management Console APIs
**Résolution**
La cause probable est une erreur dans le contrôleur Kubernetes pour App Mesh. Pour plus d'informations, consultez la section [Résolution des problèmes](https://github.com/aws/aws-app-mesh-controller-for-k8s/blob/master/docs/guide/troubleshooting.md) sur GitHub. Vérifiez les journaux du contrôleur pour détecter toute erreur ou tout avertissement indiquant que le contrôleur n'a pas pu créer de ressources.
```
kubectl logs -n appmesh-system -f \
$(kubectl get pods -n appmesh-system -o name | grep controller)
```
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Les dosettes échouent aux contrôles de préparation et de vivacité après l'injection du sidecar Envoy
**Symptômes**
Les modules de votre application fonctionnaient correctement auparavant, mais une fois que le sidecar Envoy a été injecté dans un module, les contrôles de disponibilité et de vivacité commencent à échouer.
**Résolution**
Assurez-vous que le conteneur Envoy injecté dans le pod a démarré avec le service de gestion Envoy d'App Mesh. Vous pouvez vérifier les erreurs éventuelles en référençant les codes d'erreur dans[Envoy s'est déconnecté du service de gestion App Mesh Envoy avec un texte d'erreur](troubleshooting-setup.md#ts-setup-grpc-error-codes). Vous pouvez utiliser la commande suivante pour inspecter les journaux Envoy pour le pod concerné.
```
kubectl logs -n appmesh-system -f \
$(kubectl get pods -n appmesh-system -o name | grep controller) \
| grep "gRPC config stream closed"
```
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Les pods ne s'enregistrent pas ou ne se désenregistrent pas en tant qu'instances AWS Cloud Map
**Symptômes**
Vos pods Kubernetes ne sont pas enregistrés ou désenregistrés dans le AWS Cloud Map cadre de leur cycle de vie. Un module peut démarrer correctement et être prêt à traiter le trafic, mais ne pas en recevoir. Lorsqu'un pod est fermé, les clients peuvent toujours conserver son adresse IP et tenter d'y envoyer du trafic, sans succès.
**Résolution**
Il s'agit d'un problème connu. Pour plus d'informations, consultez la section Les [pods ne s'autoactivent pas registered/deregistered dans Kubernetes](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/159) en cas de problème. AWS Cloud Map GitHub En raison de la relation entre les pods, les nœuds virtuels App Mesh et les AWS Cloud Map ressources, le [contrôleur App Mesh pour Kubernetes peut se](https://github.com/aws/aws-app-mesh-controller-for-k8s) désynchroniser et perdre des ressources. Par exemple, cela peut se produire si une ressource de nœud virtuel est supprimée de Kubernetes avant de mettre fin à ses pods associés.
Pour atténuer ce problème, procédez comme suit :
+ Assurez-vous que vous utilisez la dernière version du contrôleur App Mesh pour Kubernetes.
+ Assurez-vous que les AWS Cloud Map `namespaceName` et `serviceName` sont corrects dans la définition de votre nœud virtuel.
+ Assurez-vous de supprimer tous les pods associés avant de supprimer la définition de votre nœud virtuel. Si vous avez besoin d'aide pour identifier les pods associés à un nœud virtuel, consultez[Impossible de déterminer où s'exécute un pod pour une ressource App Mesh](#ts-kubernetes-where-pod-running).
+ Si le problème persiste, exécutez la commande suivante pour inspecter les journaux de votre manette afin de détecter les erreurs susceptibles de révéler le problème sous-jacent.
```
kubectl logs -n appmesh-system \
$(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)
```
+ Envisagez d'utiliser la commande suivante pour redémarrer vos modules de manette. Cela peut résoudre les problèmes de synchronisation.
```
kubectl delete -n appmesh-system \
$(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)
```
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Impossible de déterminer où s'exécute un pod pour une ressource App Mesh
**Symptômes**
Lorsque vous exécutez App Mesh sur un cluster Kubernetes, un opérateur ne peut pas déterminer où s'exécute une charge de travail, ou un pod, pour une ressource App Mesh donnée.
**Résolution**
Les ressources du pod Kubernetes sont annotées avec le maillage et le nœud virtuel auxquels elles sont associées. Vous pouvez demander quels pods sont en cours d'exécution pour un nom de nœud virtuel donné à l'aide de la commande suivante.
```
kubectl get pods --all-namespaces -o json | \
jq '.items[] | { metadata } | select(.metadata.annotations."appmesh.k8s.aws/virtualNode" == "virtual-node-name")'
```
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Impossible de déterminer la ressource App Mesh sous laquelle un pod est exécuté
**Symptômes**
Lors de l'exécution d'App Mesh sur un cluster Kubernetes, un opérateur ne peut pas déterminer la ressource App Mesh utilisée par un pod donné.
**Résolution**
Les ressources du pod Kubernetes sont annotées avec le maillage et le nœud virtuel auxquels elles sont associées. Vous pouvez générer les noms du maillage et des nœuds virtuels en interrogeant directement le pod à l'aide de la commande suivante.
```
kubectl get pod pod-name -n namespace -o json | \
jq '{ "mesh": .metadata.annotations."appmesh.k8s.aws/mesh", "virtualNode": .metadata.annotations."appmesh.k8s.aws/virtualNode" }'
```
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## Les envoyés clients ne sont pas en mesure de communiquer avec le service de gestion App Mesh Envoy s'ils sont désactivés IMDSv1
**Symptômes**
Lorsqu'elle `IMDSv1` est désactivée, le client Envoys ne peut pas communiquer avec le plan de contrôle App Mesh (Envoy Management Service). `IMDSv2`le support n'est pas disponible sur la version App Mesh Envoy auparavant`v1.24.0.0-prod`.
**Résolution**
Pour résoudre ce problème, vous pouvez effectuer l'une des trois opérations suivantes.
+ Passez à la version App Mesh Envoy `v1.24.0.0-prod` ou à une version ultérieure, qui est `IMDSv2` prise en charge.
+ Réactivez-le `IMDSv1` sur l'instance sur laquelle Envoy est exécuté. Pour obtenir des instructions sur la restauration`IMDSv1`, consultez [Configurer les options de métadonnées de l'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html).
+ Si vos services s'exécutent sur Amazon EKS, il est recommandé d'utiliser les rôles IAM pour les comptes de service (IRSA) pour récupérer les informations d'identification. Pour obtenir des instructions sur l'activation de l'IRSA, consultez la section [Rôles IAM pour les comptes de service](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html).
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)
## L'IRSA ne fonctionne pas sur le conteneur d'applications lorsque App Mesh est activé et qu'Envoy est injecté
**Symptômes**
Lorsque App Mesh est activé sur un cluster Amazon EKS à l'aide du contrôleur App Mesh pour Amazon EKS, Envoy et les `proxyinit` conteneurs sont injectés dans le module d'application. L'application n'est pas en mesure de supposer `IRSA` et suppose à la place le`node role`. Lorsque nous décrivons les détails du pod, nous constatons alors que la variable d'`AWS_ROLE_ARN`environnement `AWS_WEB_IDENTITY_TOKEN_FILE` ou n'est pas incluse dans le conteneur de l'application.
**Résolution**
Si l'une `AWS_WEB_IDENTITY_TOKEN_FILE` ou `AWS_ROLE_ARN` l'autre des variables d'environnement sont définies, le webhook ignorera le pod. Ne fournissez aucune de ces variables et le webhook se chargera de vous les injecter.
```
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
}
```
[Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le [AWS Support](https://aws.amazon.com/premiumsupport/).](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)