Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Solución de problemas de App Mesh
**importante**
Aviso de fin de soporte: el 30 de septiembre de 2026, AWS suspenderemos el soporte para AWS App Mesh. Después del 30 de septiembre de 2026, ya no podrás acceder a la AWS App Mesh consola ni a AWS App Mesh los recursos. Para obtener más información, visite esta entrada del blog [Migración desde AWS App Mesh a Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
En este capítulo se describen las prácticas recomendadas para solucionar problemas comunes que puedan surgir al utilizar App Mesh. Seleccione una de las siguientes áreas para revisar las prácticas recomendadas y los problemas comunes de dicha área.
**Topics**
+ [Solución de problemas y prácticas recomendadas de App Mesh](troubleshooting-best-practices.md)
+ [Solución de problemas de configuración de App Mesh](troubleshooting-setup.md)
+ [Solución de problemas de conectividad de App Mesh](troubleshooting-connectivity.md)
+ [Solución de problemas de escalado de App Mesh](troubleshooting-scaling.md)
+ [Solución de problemas de observabilidad de App Mesh](troubleshooting-observability.md)
+ [Solución de problemas de seguridad de App Mesh](troubleshooting-security.md)
+ [Solución de problemas de App Mesh para Kubernetes](troubleshooting-kubernetes.md)
# Solución de problemas y prácticas recomendadas de App Mesh
**importante**
Aviso de fin del soporte: el 30 de septiembre de 2026, AWS dejaremos de ofrecer soporte para. AWS App Mesh Después del 30 de septiembre de 2026, ya no podrás acceder a la AWS App Mesh consola ni a AWS App Mesh los recursos. Para obtener más información, visite esta entrada del blog [Migración desde AWS App Mesh a Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
Le recomendamos que siga las prácticas recomendadas de este tema para solucionar problemas al utilizar App Mesh.
## Habilitar la interfaz de administración del proxy de Envoy
El proxy de Envoy incluye una interfaz de administración que se puede utilizar para detectar la configuración y las estadísticas y para realizar otras funciones administrativas, como el drenaje de conexiones. Para obtener más información, consulte [Interfaz de administración](https://www.envoyproxy.io/docs/envoy/latest/operations/admin) en la documentación de Envoy.
Si utiliza la [Imagen de Envoy](envoy.md) administrada, el punto de conexión de administración está habilitado de forma predeterminada en el puerto 9901. Los ejemplos que se proporcionan en [Solución de problemas de configuración de App Mesh](troubleshooting-setup.md) muestran la URL del punto de conexión de administración del ejemplo como `http://my-app.default.svc.cluster.local:9901/`.
**nota**
El punto de conexión de administración nunca debe exponerse públicamente en Internet. Además, recomendamos monitorizar los registros de los puntos de conexión de administración, que la variable de entorno `ENVOY_ADMIN_ACCESS_LOG_FILE` establece en `/tmp/envoy_admin_access.log` de forma predeterminada.
## Habilite la integración de Envoy DogStats D para reducir las métricas
El proxy de Envoy se puede configurar para descargar las estadísticas del tráfico de nivel 4 y 7 de OSI y del estado del proceso interno. Si bien en este tema se muestra cómo utilizar estas estadísticas sin descargar las métricas a sumideros como Metrics CloudWatch y Prometheus, disponer de estas estadísticas en una ubicación centralizada para todas sus aplicaciones puede ayudarle a diagnosticar problemas y confirmar el comportamiento más rápidamente. Para obtener más información, consulte [Uso de Amazon CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) y la documentación de [Prometheus](https://prometheus.io/docs/introduction/overview/).
Puede configurar las métricas DogStats D configurando los parámetros definidos en. [DogStatsVariables D](envoy-config.md#envoy-dogstatsd-config) Para obtener más información sobre DogStats D, consulte la documentación de [DogStatsD.](https://docs.datadoghq.com/developers/dogstatsd/?tab=hostagent) Encontrará una demostración de la transferencia de métricas a AWS CloudWatch las métricas en el tutorial [básico de App Mesh with Amazon ECS.](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-ecs-basics) GitHub
## Habilitación de registros de acceso
Recomendamos que habilite los registros de acceso en sus [Nodos virtuales](virtual_nodes.md) y [Puertas de enlace virtuales](virtual_gateways.md) para tener información sobre el tráfico que circula entre sus aplicaciones. Para obtener más información, consulte [Acceso al registro](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/access_logging) en la documentación de Envoy. Los registros proporcionan información detallada sobre el comportamiento del tráfico de las capas 4 y 7 de OSI. Si utilizas el formato predeterminado de Envoy, puedes analizar los registros de acceso con Logs [Insights mediante la CloudWatch siguiente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) sentencia de análisis.
```
parse @message "[*] \"* * *\" * * * * * * * * * * *" as StartTime, Method, Path, Protocol, ResponseCode, ResponseFlags, BytesReceived, BytesSent, DurationMillis, UpstreamServiceTimeMillis, ForwardedFor, UserAgent, RequestId, Authority, UpstreamHost
```
## Habilitación del registro de depuración de Envoy en los entornos de preproducción
Recomendamos establecer el nivel de registro del proxy de Envoy en `debug` en un entorno de preproducción. Los registros de depuración pueden ayudarlo a identificar los problemas antes de trasladar la configuración de App Mesh asociada a su entorno de producción.
Si utiliza la [imagen de Envoy](envoy.md), puede establecer el nivel de registro en `debug` mediante la variable de entorno `ENVOY_LOG_LEVEL`.
**nota**
No recomendamos utilizar el nivel `debug` en entornos de producción. [Si se establece este nivel, se `debug` aumenta el registro y puede afectar al rendimiento y al coste total de los registros transferidos a soluciones como CloudWatch Logs.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
Si utilizas el formato predeterminado de Envoy, puedes analizar los registros del proceso con CloudWatch Logs [Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) mediante la siguiente declaración de análisis:
```
parse @message "[*][*][*][*] [*] *" as Time, Thread, Level, Name, Source, Message
```
## Monitorización de la conectividad de Envoy Proxy con el plano de control de App Mesh
Recomendamos monitorizar las métricas de Envoy `control_plane.connected_state` para asegurarse de que el proxy de Envoy se comunica con el plano de control de App Mesh para obtener los recursos de configuración dinámica. Para obtener más información, consulte [Servidor de administración](https://www.envoyproxy.io/docs/envoy/latest/configuration/overview/mgmt_server.html).
# Solución de problemas de configuración de App Mesh
**importante**
Aviso de fin de soporte: el 30 de septiembre de 2026, AWS dejaremos de ofrecer soporte para AWS App Mesh. Después del 30 de septiembre de 2026, ya no podrás acceder a la AWS App Mesh consola ni a AWS App Mesh los recursos. Para obtener más información, visite esta entrada del blog [Migración desde AWS App Mesh a Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
En este tema se explican los problemas comunes que pueden ocurrir con la configuración de App Mesh.
## No se puede extraer la imagen del contenedor de Envoy
**Síntomas**
Recibe el siguiente mensaje de error en una tarea de Amazon ECS. El Amazon ECR *account ID* y *Region* el mensaje siguiente pueden ser diferentes, según el repositorio de Amazon ECR del que haya extraído la imagen del contenedor.
```
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'
```
**Resolución**
Este error indica que el rol de ejecución de tareas que se utiliza no tiene permiso para comunicar con Amazon ECR y no puede extraer la imagen del contenedor de Envoy del repositorio. El rol de ejecución de tareas asignado a su tarea de Amazon ECS necesita una política de IAM con las siguientes instrucciones:
```
{
"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 el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## No se puede conectar con el servicio de administración de Envoy de App Mesh
**Síntomas**
Su proxy de Envoy no puede conectar con el servicio de administración de Envoy de App Mesh. Está viendo:
+ Errores de conexión rechazada
+ Tiempos de espera de conexión
+ Errores al resolver el punto de conexión del servicio de administración de Envoy de App Mesh
+ Errores gRPC
**Resolución**
Asegúrese de que su proxy de Envoy tenga acceso a Internet o a un [punto de conexión de VPC](vpc-endpoints.md) privado y de que sus [grupos de seguridad](https://docs.aws.amazon.com//vpc/latest/userguide/VPC_SecurityGroups.html) permitan el tráfico saliente en el puerto 443. Los puntos de conexión del servicio de administración de Envoy público de App Mesh siguen el formato de nombre de dominio completo (FQDN).
```
# App Mesh Production Endpoint
appmesh-envoy-management.Region-code.amazonaws.com
# App Mesh Preview Endpoint
appmesh-preview-envoy-management.Region-code.amazonaws.com
```
Puede depurar su conexión a EMS mediante el siguiente comando. Esto envía una solicitud de gRPC válida, pero vacía, al servicio de administración de 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 vuelve a recibir estos mensajes, su conexión con el servicio de administración de Envoy funciona. Para depurar errores relacionados con gRPC, consulte los errores en [Envoy se desconectó del servicio de administración de Envoy de App Mesh mostrando un texto de error](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes).
```
grpc-status: 16
grpc-message: Missing Authentication Token
```
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## Envoy se desconectó del servicio de administración de Envoy de App Mesh mostrando un texto de error
**Síntomas**
Su proxy de Envoy no puede conectarse al servicio de administración de Envoy de App Mesh ni recibir su configuración. Sus registros de proxy de Envoy contienen una entrada de registro como la siguiente.
```
gRPC config stream closed: gRPC status code, message
```
**Resolución**
En la mayoría de los casos, la parte del mensaje del registro debería indicar el problema. En la siguiente tabla se enumeran los códigos de estado de gRPC más comunes que se pueden ver, sus causas y sus resoluciones.
| Código de estado de gRPC | Causa | Resolución |
| --- | --- | --- |
| 0 | Desconexión sin problemas del servicio de administración de Envoy. | No hay ningún problema. App Mesh ocasionalmente desconecta los proxies de Envoy con este código de estado. Envoy volverá a conectar y seguirá recibiendo actualizaciones. |
| 3 | No se pudo encontrar el punto de conexión de malla (nodo virtual o puerta de enlace virtual) o uno de sus recursos asociados. | Compruebe la configuración de Envoy para asegurarse de que tiene el nombre adecuado del recurso App Mesh que representa. Si tu recurso de App Mesh está integrado con otros AWS recursos, como AWS Cloud Map espacios de nombres o certificados ACM, asegúrate de que esos recursos existan. |
| 7 | El proxy de Envoy no está autorizado para realizar una acción, como conectarse al servicio de administración de Envoy o recuperar los recursos asociados. | Asegúrese de [crear una política de IAM](proxy-authorization.md#create-iam-policy) que contenga las declaraciones de políticas adecuadas para App Mesh y otros servicios y asocie dicha política al rol o usuario de IAM que su proxy de Envoy utiliza para conectarse al servicio de administración de Envoy. |
| 8 | La cantidad de proxies de Envoy de un recurso de App Mesh determinado supera la cuota de servicio en el nivel de cuenta. | Consulte [Cuotas de servicio de App Mesh](service-quotas.md) para obtener más información acerca de las cuotas de la cuenta predeterminado y cómo solicitar un aumento de cuotas. |
| 16 | El proxy de Envoy no tiene credenciales de autenticación válidas para AWS. | Asegúrese de que el Envoy tenga las credenciales adecuadas para conectarse a los servicios de AWS a través de un rol o usuario de IAM. Existe un problema conocido, el [\$124136](https://github.com/envoyproxy/envoy/issues/24136), en la versión v1.24 de Envoy y en las versiones anteriores, por el que no se obtienen las credenciales si el proceso de Envoy utiliza más de 1024 descriptores archivos. Esto sucede cuando Envoy atiende un volumen de tráfico elevado. Puede confirmar este problema buscando el texto "A libcurl function was given a bad argument" en los registros de Envoy en el nivel de depuración. Para mitigar este problema, actualice a la versión v1.25.1.0-prod o posterior de Envoy. |
Puedes observar los códigos de estado y los mensajes de tu proxy de Envoy con [Amazon CloudWatch Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) mediante la siguiente consulta:
```
filter @message like /gRPC config stream closed/
| parse @message "gRPC config stream closed: *, *" as StatusCode, Message
```
Si el mensaje de error proporcionado no fue útil o tu problema sigue sin resolverse, considera abrir un [GitHub problema](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 comprobación de estado del contenedor de Envoy, la sonda de disponibilidad o la sonda de vivacidad producen errores
**Síntomas**
Su proxy de Envoy no pasa las comprobaciones de estado en una tarea de Amazon ECS, en una instancia de Amazon EC2 o en un pod de Kubernetes. Por ejemplo, consulta la interfaz de administración de Envoy con el siguiente comando y recibe un estado distinto de `LIVE`.
```
curl -s http://my-app.default.svc.cluster.local:9901/server_info | jq '.state'
```
**Resolución**
A continuación se muestra una lista de pasos de corrección en función del estado devuelto por el proxy de Envoy.
+ `PRE_INITIALIZING` o `INITIALIZING`: el proxy de Envoy aún no ha recibido la configuración o no puede conectarse y obtener la configuración del servicio de administración de Envoy de App Mesh. Es posible que el Envoy esté recibiendo un error del servicio de administración de Envoy al intentar conectarse. Para obtener más información, consulte los errores en [Envoy se desconectó del servicio de administración de Envoy de App Mesh mostrando un texto de error](#ts-setup-grpc-error-codes).
+ `DRAINING`: el proxy de Envoy ha empezado a agotar las conexiones en respuesta a una solicitud `/healthcheck/fail` o `/drain_listeners` en la interfaz de administración de Envoy. No recomendamos invocar estas rutas en la interfaz de administración a menos que esté a punto de finalizar su tarea de Amazon ECS, instancia de Amazon EC2 o pod de Kubernetes.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## La comprobación de estado desde el equilibrador de carga hasta el punto de conexión de malla está fallando
**Síntomas**
La comprobación de estado del contenedor o la sonda de disponibilidad consideran que el punto de conexión de malla está en buen estado, pero la comprobación de estado desde el equilibrador de carga hasta el punto de conexión de malla está fallando.
**Resolución**
Para resolver el problema, realice las siguientes tareas.
+ Asegúrese de que el [grupo de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) asociado a su punto de conexión de malla acepte el tráfico entrante en el puerto que configuró para la comprobación de estado.
+ Asegúrese de que la comprobación de estado se realice correctamente cuando se solicite manualmente; por ejemplo, desde un [host bastión de su VPC](https://aws.amazon.com/quickstart/architecture/linux-bastion/).
+ Si va a configurar una comprobación de estado para un nodo virtual, recomendamos que implemente un punto de conexión de comprobación de estado en su aplicación; por ejemplo, /ping para HTTP. Esto garantiza que tanto el proxy de Envoy como su aplicación se puedan enrutar desde el equilibrador de carga.
+ Puede usar cualquier tipo de equilibrador de carga elástico para el nodo virtual, según las características que necesite. Para obtener más información, consulte [Características del equilibrador de carga elástico](https://aws.amazon.com/elasticloadbalancing/features/#compare).
+ Si va a configurar una comprobación de estado para una [puerta de enlace virtual](virtual_gateways.md), recomendamos que utilice un [equilibrador de carga de red](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html) con una comprobación de estado de TCP o TLS en el puerto del oyente de la puerta de enlace virtual. De este modo, se asegura de que el oyente de la puerta de enlace virtual se haya iniciado y esté preparado para aceptar conexiones.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## La puerta de enlace virtual no acepta tráfico en los puertos 1024 o inferiores
**Síntomas**
Su puerta de enlace virtual no acepta tráfico en el puerto 1024 o inferiores, pero sí acepta tráfico en un número de puerto superior a 1024. Por ejemplo, consulta las estadísticas de Envoy con el siguiente comando y obtiene un valor distinto de cero.
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "update_rejected"
```
Es posible que vea un texto similar al siguiente en sus registros que describe un error al conectarse a un puerto privilegiado:
```
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
```
**Resolución**
Para resolver el problema, el usuario especificado para la puerta de enlace debe tener la capacidad `CAP_NET_BIND_SERVICE` de Linux. Para obtener más información, consulte [Capacidades](https://www.man7.org/linux/man-pages/man7/capabilities.7.html) en el Manual del programador de Linux, [Parámetros de Linux](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_linuxparameters) en los parámetros de definición de tareas de ECS y [Establecer capacidades para un contenedor](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) en la documentación de Kubernetes.
**importante**
Fargate debe usar un valor de puerto superior a 1024.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
# Solución de problemas de conectividad de App Mesh
**importante**
Aviso de fin del soporte: el 30 de septiembre de 2026, AWS dejaremos de ofrecer soporte para AWS App Mesh. Después del 30 de septiembre de 2026, ya no podrás acceder a la AWS App Mesh consola ni a AWS App Mesh los recursos. Para obtener más información, visite esta entrada del blog [Migración desde AWS App Mesh a Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
En este tema se explican los problemas comunes que pueden ocurrir con la conectividad de App Mesh.
## No se puede resolver el nombre DNS de un servicio virtual
**Síntomas**
La aplicación no puede resolver el nombre DNS de un servicio virtual al que intenta conectarse.
**Resolución**
Se trata de un problema conocido. Para obtener más información, consulte el tema del [nombre VirtualServices junto a cualquier nombre de host o FQDN](https://github.com/aws/aws-app-mesh-roadmap/issues/65) GitHub . Los servicios virtuales de App Mesh pueden tener cualquier nombre. Siempre que haya un registro `A` DNS para el nombre del servicio virtual y la aplicación pueda resolver el nombre del servicio virtual, Envoy redirigirá la solicitud mediante un proxy y la dirigirá al destino correspondiente. Para resolver el problema, añada un registro `A` DNS a cualquier dirección IP que no sea de bucle invertido, por ejemplo `10.10.10.10`, para el nombre del servicio virtual. El registro `A` DNS se puede agregar en las siguientes condiciones:
+ En Amazon Route 53, si el nombre tiene el sufijo del nombre de la zona alojada privada
+ Dentro del archivo `/etc/hosts` del contenedor de aplicaciones
+ En un servidor DNS de terceros que usted administre
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## No se puede conectar a un backend de servicio virtual
**Síntomas**
Su aplicación no puede establecer una conexión a un servicio virtual definido como backend en su nodo virtual. Al intentar establecer una conexión, esta puede fallar por completo, o la solicitud desde la perspectiva de la aplicación puede fallar mostrando un código de respuesta `HTTP 503`.
**Resolución**
Si la aplicación no se conecta en absoluto (no se devuelve ningún código de respuesta `HTTP 503`), haga lo siguiente:
+ Asegúrese de que su entorno informático esté configurado para funcionar con App Mesh.
+ Para Amazon ECS, asegúrese de que tiene habilitada la [configuración de proxy](proxy-authorization.md) adecuada. Para ver un end-to-end tutorial, consulte [Introducción a App Mesh y Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/appmesh-getting-started.html).
+ Para Kubernetes, incluido Amazon EKS, asegúrese de que tiene instalado el controlador de App Mesh más reciente a través de Helm. Para obtener más información, consulte [Controlador de App Mesh](https://hub.helm.sh/charts/aws/appmesh-controller) en Helm Hub o [Tutorial: Configurar la integración de App Mesh con Kubernetes](https://docs.aws.amazon.com/app-mesh/latest/userguide/mesh-k8s-integration.html).
+ En el caso de Amazon EC2, asegúrese de que ha configurado su instancia de Amazon EC2 para el tráfico de App Mesh mediante proxy. Para obtener más información, consulte [Actualizar servicios](https://docs.aws.amazon.com/app-mesh/latest/userguide/appmesh-getting-started.html#update-services).
+ Asegúrese de que el contenedor de Envoy que se ejecuta en su servicio informático se haya conectado correctamente al servicio de administración de Envoy de App Mesh. Puede confirmarlo consultando las estadísticas de Envoy correspondientes al campo `control_plane.connected_state`. Para obtener más información acerca de `control_plane.connected_state`, consulte [Monitorizar la conectividad del proxy de Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-best-practices.html#ts-bp-enable-envoy-control-plane-connected-state) en nuestras **Prácticas recomendadas para la resolución de problemas**.
Si Envoy pudo establecer la conexión inicialmente, pero luego se desconectó y nunca se volvió a conectar, consulte [Envoy se desconectó del servicio de administración de Envoy de App Mesh mostrando un texto de error](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes) para solucionar el motivo de la desconexión.
Si la aplicación se conecta pero la solicitud produce un error y aparece un código de respuesta `HTTP 503`, intente lo siguiente:
+ Asegúrese de que el servicio virtual al que se está conectando existe en la malla.
+ Asegúrese de que el servicio virtual tenga un proveedor (un enrutador virtual o un nodo virtual).
+ Cuando utilice Envoy como proxy HTTP, si en las estadísticas de Envoy comprueba que en `cluster.cds_egress_*_mesh-allow-all` entra tráfico de salida en lugar del destino correcto, lo más probable es que Envoy no enrute las solicitudes correctamente a través de `filter_chains`. Esto puede deberse al uso de un nombre de servicio virtual no cualificado. Recomendamos que utilice el nombre de detección de servicios del servicio real como nombre del servicio virtual, ya que el proxy de Envoy se comunica con otros servicios virtuales a través de sus nombres.
Para obtener más información, consulte [servicios virtuales](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_services.html).
+ Examine los registros del proxy de Envoy para ver si hay alguno de los siguientes mensajes de error:
+ `No healthy upstream`: el nodo virtual al que el proxy de Envoy intenta enrutar no tiene ningún punto de conexión resuelto o no tiene ningún punto de conexión en buen estado. Asegúrese de que el nodo virtual de destino tenga la configuración correcta de detección de servicios y comprobación de estado.
Si las solicitudes al servicio producen un error durante la implementación o el escalado del servicio virtual de backend, siga las instrucciones que se indican en [Algunas solicitudes producen un error con el código de estado HTTP `503` cuando un servicio virtual tiene un proveedor de nodos virtuales](#ts-connectivity-virtual-node-provider).
+ `No cluster match for URL`: lo más probable es que esto se deba a que se envía una solicitud a un servicio virtual que no cumple los criterios definidos por ninguna de las rutas definidas por un proveedor de enrutadores virtuales. Asegúrese de que las solicitudes de la aplicación se envíen a una ruta compatible, comprobando que la ruta y los encabezados de las solicitudes HTTP sean correctos.
+ `No matching filter chain found`: lo más probable es que esto se deba a que se envía una solicitud a un servicio virtual en un puerto no válido. Asegúrese de que las solicitudes de la aplicación utilicen el mismo puerto especificado en el enrutador virtual.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## No se puede conectar a un servicio externo
**Síntomas**
Su aplicación no puede conectarse a un servicio fuera de la malla, por ejemplo `amazon.com`.
**Resolución**
De forma predeterminada, App Mesh no permite el tráfico saliente de las aplicaciones dentro de la malla a ningún destino fuera de la malla. Para habilitar la comunicación con un servicio externo, hay dos opciones:
+ Establezca el [filtro de salida](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html) en el recurso de malla en `ALLOW_ALL`. Esta configuración permitirá que cualquier aplicación dentro de la malla se comunique con cualquier dirección IP de destino dentro o fuera de la malla.
+ Modele el servicio externo en la malla mediante un servicio virtual, enrutador virtual, ruta y nodo virtual. Por ejemplo, para modelar el servicio externo `example.com`, puede crear un servicio virtual denominado `example.com` con un enrutador y una ruta virtuales que envíen todo el tráfico a un nodo virtual con un nombre de host de detección de servicios DNS de `example.com`.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## No se puede conectar a un servidor MySQL o SMTP
**Síntomas**
Al permitir el tráfico saliente a todos los destinos (Malla `EgressFilter type`=`ALLOW_ALL`), por ejemplo, un servidor SMTP o una base de datos MySQL mediante una definición de nodo virtual, se produce un error en la conexión de la aplicación. A modo de ejemplo, el siguiente es un mensaje de error al intentar conectarse a un servidor MySQL.
```
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
```
**Resolución**
Se trata de un problema conocido que se resuelve con la versión 1.15.0 o posterior de la imagen de App Mesh. Para obtener más información, consulta el GitHub problema [No se puede conectar a MySQL con App Mesh](https://github.com/aws/aws-app-mesh-roadmap/issues/62). Este error se produce porque el oyente saliente de Envoy configurado por App Mesh añade el filtro de oyente de TLS Inspector de Envoy. Para obtener más información, consulte [TLS Inspector](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/tls_inspector#config-listener-filters-tls-inspector) en la documentación de Envoy. Este filtro evalúa si una conexión utiliza o no TLS inspeccionando el primer paquete enviado desde el cliente. Sin embargo, con MySQL y SMTP, el servidor envía el primer paquete después de la conexión. Para obtener más información acerca de MySQL, consulte [Protocolo de enlace inicial](https://dev.mysql.com/doc/internals/en/initial-handshake.html) en la documentación de MySQL. Como el servidor envía el primer paquete, se produce un error en la inspección del filtro.
**Solución de este problema según la versión de Envoy:**
+ Si la versión de Envoy para imágenes de App Mesh es la 1.15.0 o posterior, no modele servicios externos como **MySQL**, **SMTP**, **MSSQL**, etc. como un backend para el nodo virtual de su aplicación.
+ Si la versión de Envoy para imágenes de App Mesh es anterior a la 1.15.0, añada el puerto `3306` a la lista de valores de `APPMESH_EGRESS_IGNORED_PORTS` en sus servicios para **MySQL** y como el puerto que va a utilizar para **STMP**.
**importante**
Si bien los puertos SMTP estándar son `25`, `587` y`465`, solo debe añadir el puerto que está utilizando a `APPMESH_EGRESS_IGNORED_PORTS` y no los tres.
Para obtener más información, consulte [Servicios de actualización](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-kubernetes.html#create-update-services) para Kubernetes, [Servicios de actualización](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ecs.html#update-services) para Amazon ECS o [Servicios de actualización](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ec2.html#update-services) para Amazon EC2.
Si tu problema sigue sin resolverse, puedes proporcionarnos detalles sobre lo que estás experimentando con el [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/62) existente o ponerte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## No se puede conectar a un servicio modelado como un nodo virtual TCP o enrutador virtual en App Mesh
**Síntomas**
Tu aplicación no puede conectarse a un backend que utilice la configuración del protocolo TCP en la [PortMapping](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_PortMapping.html)definición de App Mesh.
**Resolución**
Se trata de un problema conocido. Para obtener más información, consulta [Cómo enrutar a varios destinos TCP en el mismo puerto](https://github.com/aws/aws-app-mesh-roadmap/issues/195). GitHub Actualmente, App Mesh no permite que varios destinos de backend modelados como TCP compartan el mismo puerto debido a las restricciones de la información proporcionada al proxy de Envoy en la capa 4 de OSI. Para asegurarse de que el tráfico de TCP se pueda enrutar de manera adecuada para todos los destinos de backend, haga lo siguiente:
+ Asegúrese de que todos los destinos utilicen un puerto único. Si utiliza un proveedor de enrutadores virtuales para el servicio virtual de backend, puede cambiar el puerto del enrutador virtual sin cambiar el puerto de los nodos virtuales a los que se enruta. Esto permite que las aplicaciones abran conexiones en el puerto del router virtual mientras el proxy de Envoy sigue utilizando el puerto definido en el nodo virtual.
+ Si el destino modelado como TCP es un servidor MySQL o cualquier otro protocolo basado en TCP en el que el servidor envía los primeros paquetes después de la conexión, consulte [No se puede conectar a un servidor MySQL o SMTP](#ts-connectivity-troubleshooting-mysql-and-smtp).
Si tu problema sigue sin resolverse, puedes proporcionarnos detalles sobre lo que estás experimentando con el [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/195) existente o ponerte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## La conectividad es correcta para un servicio que no figura como backend de servicio virtual de un nodo virtual
**Síntomas**
Su aplicación puede conectarse y enviar tráfico a un destino que no esté especificado como backend de servicio virtual en su nodo virtual.
**Resolución**
Si las solicitudes llegan sucesivamente a un destino que no se ha modelado en App Mesh APIs, la causa más probable es que el tipo de [filtro de salida](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html) de la malla se haya establecido en. `ALLOW_ALL` Si el filtro de salida está configurado en `ALLOW_ALL`, una solicitud de salida de su aplicación que no coincida con un destino modelado (backend) se enviará a la dirección IP de destino establecida por la aplicación.
Si desea impedir el tráfico a destinos no modelados en la malla, considere la posibilidad de establecer el valor del filtro de salida en `DROP_ALL`.
**nota**
La configuración del valor del filtro de salida de la malla afecta a todos los nodos virtuales de la malla.
La configuración `egress_filter` `DROP_ALL` y la activación de TLS no están disponibles para el tráfico saliente que no se dirija a un dominio. AWS
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## Algunas solicitudes producen un error con el código de estado HTTP `503` cuando un servicio virtual tiene un proveedor de nodos virtuales
**Síntomas**
Una parte de las solicitudes de la aplicación no se envía a un backend de servicios virtuales que utiliza un proveedor de nodos virtuales en lugar de un proveedor de enrutadores virtuales. Cuando se utiliza un proveedor de enrutadores virtuales para el servicio virtual, las solicitudes no producen errores.
**Resolución**
Se trata de un problema conocido. Para obtener más información, consulte la [política de reintentos del proveedor de nodos virtuales para instalar un servicio virtual](https://github.com/aws/aws-app-mesh-roadmap/issues/194) en GitHub. Cuando usa un nodo virtual como proveedor de un servicio virtual, no puede especificar la política de reintentos predeterminada que desea que usen los clientes de su servicio virtual. En cambio, los proveedores de enrutadores virtuales permiten especificar políticas de reintentos porque son una propiedad de los recursos de ruta secundarios.
Para reducir los errores en las solicitudes a los proveedores de nodos virtuales, utilice un proveedor de enrutadores virtuales en su lugar y especifique una política de reintentos en sus rutas. Para saber otras formas de reducir los errores en las solicitudes de sus aplicaciones, consulte [Prácticas recomendadas para App Mesh](best-practices.md).
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## No se puede conectar a un sistema de archivos de Amazon EFS
**Síntomas**
Al configurar una tarea de Amazon ECS con un sistema de archivos de Amazon EFS como volumen, la tarea no se inicia y aparece el siguiente error.
```
ResourceInitializationError: failed to invoke EFS utils commands to set up EFS volumes: stderr: mount.nfs4: Connection refused : unsuccessful EFS utils command execution; code: 32
```
**Resolución**
Se trata de un problema conocido. Este error se produce porque la conexión de NFS a Amazon EFS se produce antes de que se inicie ningún contenedor de la tarea. La configuración del proxy enruta este tráfico a Envoy, que no se ejecuta en este momento. Debido al orden de inicio, el cliente NFS no se conecta al sistema de archivos de Amazon EFS y la tarea no se inicia. Para resolver el problema, añada el puerto `2049` a la lista de valores del parámetro `EgressIgnoredPorts` de la configuración del proxy de la definición de la tarea de Amazon ECS. Para más información, consulte [Configuración del proxy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#proxyConfiguration).
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## La conectividad funciona correctamente, pero la solicitud entrante no aparece en los registros, rastreos o métricas de acceso de Envoy
**Síntomas**
Aunque su aplicación puede conectarse y enviar solicitudes a otra aplicación, no podrá ver las solicitudes entrantes en los registros de acceso ni en la información de rastreo del proxy de Envoy.
**Resolución**
Se trata de un problema conocido. Para obtener más información, consulte el problema [configuración de las reglas de iptables](https://github.com/aws/aws-app-mesh-roadmap/issues/166) en Github. El proxy de Envoy solo intercepta el tráfico entrante al puerto al que está conectado su nodo virtual correspondiente. Las solicitudes a cualquier otro puerto omitirán el proxy de Envoy y llegarán directamente al servicio que está detrás de él. Para que el proxy de Envoy intercepte el tráfico entrante de su servicio, debe configurar el servicio y el nodo virtual para que escuchen en el mismo puerto.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## Establecer las variables de entorno `HTTP_PROXY`/`HTTPS_PROXY` a nivel de contenedor no funciona como se esperaba.
**Síntomas**
Cuando HTTP\$1PROXY/HTTPS\$1PROXY se establece como variable de entorno en el:
+ Contenedor de aplicaciones en la definición de tareas con App Mesh habilitado, las solicitudes que se envíen al espacio de nombres de los servicios de App Mesh recibirán respuestas de error `HTTP 500` del sidecar de Envoy.
+ Contenedor de Envoy en la definición de tareas con App Mesh habilitado, las solicitudes que salgan del sidecar de Envoy no pasarán por el servidor proxy `HTTP`/`HTTPS` y la variable de entorno no funcionará.
**Resolución**
Para el contenedor de aplicaciones:
App Mesh funciona haciendo que el tráfico de su tarea pase por el proxy de Envoy. La configuración `HTTP_PROXY`/`HTTPS_PROXY` anula este comportamiento al configurar el tráfico del contenedor para que pase por un proxy externo diferente. Envoy seguirá interceptando el tráfico, pero no es compatible con el envío a través de un proxy externo del tráfico de malla.
Si desea utilizar un proxy para todo el tráfico que no sea de malla, configure `NO_PROXY` para que incluya el CIDR o el espacio de nombres de la malla, el host local y los puntos de conexión de la credencial, como en el siguiente ejemplo.
```
NO_PROXY=localhost,127.0.0.1,169.254.169.254,169.254.170.2,10.0.0.0/16
```
Para el contenedor Envoy:
Envoy no admite un proxy genérico. No recomendamos configurar estas variables.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## Se agotan los tiempos de espera de las solicitudes ascendentes incluso después de configurar el tiempo de espera de las rutas.
**Síntomas**
Ha definido el tiempo de espera de:
+ Las rutas, pero sigue apareciendo un error de tiempo de espera en la solicitud ascendente.
+ El oyente del nodo virtual y el tiempo de espera de reintento de las rutas, pero sigue apareciendo un error de tiempo de espera de la solicitud ascendente.
**Resolución**
Para que las solicitudes de alta latencia superiores a 15 segundos se completen correctamente, debe especificar un tiempo de espera tanto en el nivel de ruta como en el de oyente del nodo virtual.
Si especifica un tiempo de espera de la ruta superior al valor predeterminado de 15 segundos, asegúrese de que el tiempo de espera también esté especificado para el oyente en todos los nodos virtuales que participen. Sin embargo, si reduce el tiempo de espera a un valor inferior al predeterminado; opcionalmente, puede actualizar los tiempos de espera en los nodos virtuales. Para obtener más información sobre las opciones a la hora de configurar nodos virtuales y rutas, consulte [nodos virtuales](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html) y [rutas](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html).
Si especificó una **política de reintentos**, la duración que indique para el tiempo de espera de la solicitud siempre debe ser mayor o igual al *tiempo de espera de reintentos* multiplicado por los *reintentos máximos* que haya definido en la **política de reintentos**. Esto permite que la solicitud, con todos los reintentos, se complete correctamente. Para obtener más información, consulte [rutas](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html).
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## Envoy responde con una solicitud HTTP incorrecta.
**Síntomas**
Envoy responde con una **solicitud HTTP 400 incorrecta** para todas las solicitudes enviadas a través del Equilibrador de carga de red (NLB). Cuando comprobamos los registros de Envoy, vemos lo siguiente:
+ Registros de depuración:
```
dispatch error: http/1.1 protocol error: HPE_INVALID_METHOD
```
+ Registros de acceso:
```
"- - HTTP/1.1" 400 DPE 0 11 0 - "-" "-" "-" "-" "-"
```
**Resolución**
La solución consiste en deshabilitar la versión 2 (PPv2) del protocolo proxy en los [atributos del grupo objetivo](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-group-attributes) de su NLB.
A día de hoy, no PPv2 es compatible con la puerta de enlace virtual ni el nodo virtual Envoy, que se ejecutan mediante el plano de control App Mesh. Si despliegas NLB mediante un controlador de equilibrio de AWS carga en Kubernetes, desactívalo PPv2 configurando el siguiente atributo en: `false`
```
service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: proxy_protocol_v2.enabled
```
Consulte [Anotaciones del controlador del equilibrador de carga de AWS](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/#resource-attributestrue) para obtener más información sobre los atributos de los recursos del NLB.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## No se ha podido configurar correctamente el tiempo de espera.
**Síntomas**
Su solicitud agota el tiempo de espera en 15 segundos, incluso después de configurar el tiempo de espera en el oyente del nodo virtual y el tiempo de espera en la ruta hacia el backend del nodo virtual.
**Resolución**
Asegúrese de que se incluye el servicio virtual correcto en la lista de backend.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
# Solución de problemas de escalado de App Mesh
**importante**
Aviso de fin del soporte: el 30 de septiembre de 2026, AWS dejaremos de ofrecer soporte para AWS App Mesh. Después del 30 de septiembre de 2026, ya no podrás acceder a la AWS App Mesh consola ni a AWS App Mesh los recursos. Para obtener más información, visite esta entrada del blog [Migración desde AWS App Mesh a Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
En este tema se describen los problemas comunes que pueden ocurrir con el escalado de App Mesh.
## La conectividad falla y las comprobaciones de estado de los contenedores fallan al escalar más de 50 réplicas para una puerta de enlace virtual node/virtual
**Síntomas**
Cuando se amplía el número de réplicas, como tareas de Amazon ECS, pods de Kubernetes o instancias de Amazon EC2, para una node/virtual puerta de enlace virtual superior a 50, las comprobaciones de estado de los contenedores de Envoy para detectar Envoys nuevos y en ejecución comienzan a fallar. Las aplicaciones intermedias que envían tráfico a la node/virtual puerta de enlace virtual comienzan a detectar errores en las solicitudes con el código de estado HTTP. `503`
**Resolución**
La cuota predeterminada de App Mesh para el número de enviados por node/virtual puerta de enlace virtual es de 50. Cuando el número de Envoys en ejecución supera esta cuota, los Envoys nuevos y los que se están ejecutando actualmente no pueden conectarse al servicio de administración de Envoy de App Mesh con el código de estado gRPC `8` (`RESOURCE_EXHAUSTED`). Esta cuota se puede aumentar. Para obtener más información, consulte [Cuotas de servicio de App Mesh](service-quotas.md).
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## Las solicitudes producen un error `503` cuando el backend de un servicio virtual se escala vertical u horizontalmente
**Síntomas**
Cuando un servicio virtual de backend se escala vertical u horizontalmente, las solicitudes de las aplicaciones descendentes producen un error con un código de estado `HTTP 503`.
**Resolución**
App Mesh recomienda varios métodos para mitigar los casos de error y, al mismo tiempo, escalar las aplicaciones horizontalmente. Para obtener información detallada acerca de cómo evitar estos errores, consulte [Prácticas recomendadas para App Mesh](best-practices.md).
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## El contenedor de Envoy se bloquea debido a un error de segmentación al aumentar la carga
**Síntomas**
Cuando hay mucha carga de tráfico, el proxy de Envoy se bloquea debido a un error de segmentación (código de salida de Linux `139`). Los registros del proceso de Envoy contienen una instrucción como la siguiente.
```
Caught Segmentation fault, suspect faulting address 0x0"
```
**Resolución**
Es probable que el proxy de Envoy haya superado el valor de nofile ulimit predeterminado del sistema operativo, es decir, el límite del número de archivos que un proceso puede tener abiertos a la vez. Esta infracción se debe a que el tráfico genera más conexiones, lo que consume más sockets del sistema operativo. Para resolver este problema, aumente el valor de ulimit nofile en el sistema operativo host. Si utiliza Amazon ECS, este límite se puede cambiar mediante la [configuración de Ulimit](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html) en la [configuración de límites de recursos](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_limits) de la definición de la tarea.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## El aumento de los recursos predeterminados no se refleja en los límites de servicio
**Síntomas**
Tras aumentar el límite predeterminado de los recursos de App Mesh, el nuevo valor no se refleja al comprobar los límites de servicio.
**Resolución**
Si bien los nuevos límites no se muestran actualmente, los clientes aún pueden aplicarlos.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## La aplicación se bloquea debido a la gran cantidad de llamadas de comprobación de estado.
**Síntomas**
Tras habilitar las comprobaciones de estado activas de un nodo virtual, se produce un aumento del número de llamadas de comprobación de estado. La aplicación se bloquea debido al aumento considerable del volumen de llamadas de comprobación de estado que se realizan a la aplicación.
**Resolución**
Cuando la comprobación de estado activa está habilitada, cada punto de conexión de Envoy del clúster descendente (cliente) envía solicitudes de estado a cada punto de conexión del clúster ascendente (servidor) para tomar decisiones de enrutamiento. Como resultado, el número total de solicitudes de comprobación de estado sería `number of client Envoys` \$1 `number of server Envoys` \$1 `active health check frequency`.
Para resolver este problema, modifique la frecuencia del sondeo de comprobación de estado, lo que reduciría el volumen total de los sondeos de comprobación de estado. Además de las comprobaciones de estado activas, App Mesh permite configurar la [detección de valores atípicos](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_OutlierDetection.html) como un medio de comprobación de estado pasiva. Utilice la detección de valores atípicos para configurar cuándo eliminar un host en particular en función de las respuestas `5xx` consecutivas.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
# Solución de problemas de observabilidad de App Mesh
**importante**
Aviso de fin del soporte: el 30 de septiembre de 2026, AWS dejaremos de ofrecer soporte para AWS App Mesh. Después del 30 de septiembre de 2026, ya no podrás acceder a la AWS App Mesh consola ni a AWS App Mesh los recursos. Para obtener más información, visite esta entrada del blog [Migración desde AWS App Mesh a Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
En este tema se describen los problemas comunes que pueden ocurrir con la observabilidad de App Mesh.
## No puedo ver los AWS X-Ray rastros de mis aplicaciones
**Síntomas**
Su aplicación en App Mesh no muestra información de rastreo de rayos X en la consola de X-Ray o APIs.
**Resolución**
Para usar X-Ray en App Mesh, debe configurar correctamente los componentes para permitir la comunicación entre la aplicación, los contenedores sidecar y el servicio de X-Ray. Realice los pasos siguientes para confirmar que X-Ray se ha configurado correctamente:
+ Asegúrese de que el protocolo de oyente del nodo virtual de App Mesh no esté establecido en `TCP`.
+ Asegúrese de que el contenedor de X-Ray que se implementa con la aplicación muestre el puerto UDP `2000` y se ejecute como usuario `1337`. Para obtener más información, consulte el [ejemplo de Amazon ECS X-Ray](https://github.com/aws/aws-app-mesh-examples/blob/main/walkthroughs/howto-ecs-basics/deploy/2-meshify.yaml#L374-L386) en GitHub.
+ Asegúrese de que el contenedor de Envoy tenga habilitado el rastreo. Si utiliza la [imagen de App Mesh Envoy](envoy.md), puede habilitar X-Ray estableciendo la variable de entorno `ENABLE_ENVOY_XRAY_TRACING` en un valor de `1` y la variable de entorno `XRAY_DAEMON_PORT` en un valor de `2000`.
+ Si ha instrumentado X-Ray en el código de su aplicación con uno de los [idiomas específicos SDKs ](https://docs.aws.amazon.com/xray/index.html), asegúrese de que esté configurado correctamente siguiendo las guías de su idioma.
+ Si todos los elementos anteriores están configurados correctamente, revise los registros del contenedor de X-Ray para ver si hay errores y siga las instrucciones de [Solución de problemas de AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-troubleshooting.html). Puede encontrar una explicación más detallada de la integración de X-Ray en App Mesh en [Integración de X-Ray con App Mesh](https://aws.amazon.com/blogs/compute/integrating-aws-x-ray-with-aws-app-mesh/).
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## No puedo ver las métricas de Envoy para mis aplicaciones en las CloudWatch métricas de Amazon
**Síntomas**
Tu aplicación en App Mesh no emite las métricas generadas por el proxy de Envoy a CloudWatch las métricas.
**Resolución**
Cuando utilizas CloudWatch métricas en App Mesh, debes configurar correctamente varios componentes para permitir la comunicación entre el proxy de Envoy, el sidecar del CloudWatch agente y el servicio de CloudWatch métricas. Siga los siguientes pasos para confirmar que CloudWatch las métricas del proxy de Envoy se han configurado correctamente:
+ Asegúrese de utilizar la imagen del CloudWatch agente para App Mesh. Para obtener más información, consulte el [ CloudWatchagente App Mesh](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent) en GitHub.
+ Asegúrese de haber configurado el CloudWatch agente para App Mesh de forma adecuada siguiendo las instrucciones de uso específicas de la plataforma. Para obtener más información, consulte el [ CloudWatchagente App Mesh](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent#usage) en GitHub.
+ Si todos los elementos anteriores están configurados correctamente, revise los registros del contenedor del CloudWatch agente para ver si hay errores y siga las instrucciones que se proporcionan en [Solución de problemas con el CloudWatch agente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html).
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## No se pueden configurar reglas de muestreo personalizadas para las AWS X-Ray trazas
**Síntomas**
Su aplicación utiliza el rastreo de X-Ray, pero no puede configurar las reglas de muestreo de sus rastreos.
**Resolución**
Dado que App Mesh Envoy no admite actualmente la **configuración de muestreo dinámico de X-Ray**, existen las siguientes soluciones alternativas.
Si su versión de Envoy es `1.19.1` o posterior, tiene las siguientes opciones.
+ Para establecer únicamente la frecuencia de muestreo, utilice la variable de entorno `XRAY_SAMPLING_RATE` en el contenedor de Envoy. El valor debe especificarse como un decimal entre `0` y `1.00` (100 %). Para obtener más información, consulte [AWS X-Ray variables](envoy-config.md#envoy-xray-config).
+ Para configurar las reglas de muestreo personalizadas y localizadas para el rastreador de X-Ray, utilice la variable de entorno `XRAY_SAMPLING_RULE_MANIFEST` para especificar una ruta de archivo del sistema de archivos del contenedor de Envoy. Para obtener más información, consulte [Reglas de muestreo](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling) en la *Guía para desarrolladores de AWS X-Ray *.
Si su versión de Envoy es anterior a la `1.19.1`, haga lo siguiente.
+ Utilice la variable de entorno `ENVOY_TRACING_CFG_FILE` para cambiar la frecuencia de muestreo. Para obtener más información, consulte [Variables de configuración de Envoy](envoy-config.md). Especifique una configuración de rastreo personalizada y defina las reglas de muestreo locales. Para obtener más información, consulte [Configuración de X-Ray para Envoy](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/trace/v3/xray.proto.html#config-trace-v3-xrayconfig).
+ Ejemplo de configuración de rastreo personalizada para la variable de entorno `ENVOY_TRACING_CFG_FILE`:
```
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
```
+ Para obtener más información sobre la configuración del manifiesto de reglas de muestreo en la propiedad `samplingRuleManifest`, consulte [Configuración del SDK de X-Ray para Go](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling).
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
# Solución de problemas de seguridad de App Mesh
**importante**
Aviso de fin del soporte: el 30 de septiembre de 2026, AWS dejaremos de ofrecer soporte para AWS App Mesh. Después del 30 de septiembre de 2026, ya no podrás acceder a la AWS App Mesh consola ni a AWS App Mesh los recursos. Para obtener más información, visite esta entrada del blog [Migración desde AWS App Mesh a Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
En este tema se describen los problemas comunes que pueden ocurrir con la seguridad de App Mesh.
## No se puede conectar a un servicio virtual de backend con una política de cliente TLS
**Síntomas**
Al agregar una política de cliente TLS a un backend de servicio virtual en un nodo virtual, se produce un error de conectividad de dicho backend. Al intentar enviar tráfico al servicio de backend, las solicitudes producen un error con un código de respuesta `HTTP 503` y el mensaje de error: `upstream connect error or disconnect/reset before headers. reset reason: connection failure`.
**Resolución**
Para determinar la causa raíz del problema, recomendamos que utilice los registros del proceso del proxy de Envoy para ayudarlo a diagnosticar el problema. Para obtener más información, consulte [Habilitación del registro de depuración de Envoy en los entornos de preproducción](troubleshooting-best-practices.md#ts-bp-enable-envoy-debug-logging). Utilice la siguiente lista para determinar la causa del error de conexión:
+ Asegúrese de que la conectividad con el backend es correcta descartando los errores mencionados en [No se puede conectar a un backend de servicio virtual](troubleshooting-connectivity.md#ts-connectivity-virtual-service-backend).
+ En los registros del proceso de Envoy, busque los siguientes errores (registrados en el nivel de depuración).
```
TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
```
Este error se debe a una o varias de las siguientes razones:
+ El certificado no lo firmó ninguna de las autoridades de certificación definidas en la agrupación de confianza de políticas de cliente de TLS.
+ El certificado ya no es válido (ha caducado).
+ El nombre alternativo del asunto (SAN) no coincide con el nombre de host DNS solicitado.
+ Asegúrese de que el certificado ofrecido por el servicio de backend sea válido, de que esté firmado por una de las autoridades de certificación de la agrupación de confianza de políticas de cliente de TLS y de que cumpla los criterios definidos en [seguridad de la capa de transporte (TLS)](tls.md).
+ Si el error que recibe es como el que se muestra a continuación, significa que la solicitud omite el proxy de Envoy y llega directamente a la aplicación. Al enviar tráfico, las estadísticas de Envoy no cambian, lo que indica que Envoy no está en vías de descifrar el tráfico. En la configuración de proxy del nodo virtual, asegúrese de que `AppPorts` contiene el valor correcto que escucha la aplicación.
```
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 el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue-bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/). Si cree que ha encontrado una vulnerabilidad de seguridad o tiene dudas sobre la seguridad de App Mesh, consulte las [Directrices de notificación de vulnerabilidades de AWS](https://aws.amazon.com/security/vulnerability-reporting/).
## No se puede conectar a un servicio virtual de backend cuando la aplicación es el origen de TLS
**Síntomas**
Cuando una aplicación es el origen de una sesión de TLS, en lugar del proxy de Envoy, se produce un error en la conectividad con un servicio virtual de backend.
**Resolución**
Se trata de un problema conocido. Para obtener más información, consulta la [solicitud de función: problema con la negociación de TLS entre la aplicación descendente y el proxy ascendente](https://github.com/aws/aws-app-mesh-roadmap/issues/162). GitHub En App Mesh, el origen de TLS se admite actualmente desde el proxy de Envoy, pero no desde la aplicación. Para usar la compatibilidad con el origen de TLS en Envoy, deshabilite el origen de TLS en la aplicación. Esto permite al Envoy leer los encabezados de las solicitudes salientes y reenviar la solicitud al destino correspondiente mediante una sesión de TLS. Para obtener más información, consulte [seguridad de la capa de transporte (TLS)](tls.md).
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/). Si cree que ha encontrado una vulnerabilidad de seguridad o tiene dudas sobre la seguridad de App Mesh, consulte las [Directrices de notificación de vulnerabilidades de AWS](https://aws.amazon.com/security/vulnerability-reporting/).
## No se puede asegurar que la conectividad entre los proxies de Envoy utilice TLS
**Síntomas**
Su aplicación ha habilitado la terminación de TLS en el nodo virtual o el oyente de puerta de enlace virtual, o el origen de TLS en la política del cliente de TLS del backend, pero no puede asegurar que la conectividad entre los proxies de Envoy se produzca durante una sesión negociada mediante TLS.
**Resolución**
Los pasos definidos en esta resolución utilizan la interfaz de administración de Envoy y las estadísticas de Envoy. Si necesita ayuda para configurarlos, consulte [Habilitar la interfaz de administración del proxy de Envoy](troubleshooting-best-practices.md#ts-bp-enable-proxy-admin-interface) y [Habilite la integración de Envoy DogStats D para reducir las métricas](troubleshooting-best-practices.md#ts-bp-enable-envoy-statsd-integration). Los siguientes ejemplos de estadísticas utilizan la interfaz de administración para simplificar.
+ Para el proxy de Envoy que realiza la terminación de TLS:
+ Asegúrese de que el certificado TLS se haya iniciado en la configuración de Envoy con el siguiente comando.
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
En el resultado devuelto debería ver al menos una entrada bajo `certificates[].cert_chain` para el certificado utilizado en la terminación de TLS.
+ Asegúrese de que el número de conexiones entrantes correctas al oyente del proxy sea exactamente el mismo que el número de protocolos de enlace SSL más el número de sesiones SSL reutilizadas, como se muestra en los siguientes ejemplos de comandos y resultados.
```
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)
```
+ Para el proxy de Envoy que establece el origen de TLS:
+ Asegúrese de que el almacén de confianza de TLS se haya iniciado en la configuración de Envoy con el siguiente comando.
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
Debería ver al menos una entrada bajo `certificates[].ca_certs` para los certificados utilizados para validar el certificado del backend al establecer el origen de TLS.
+ Asegúrese de que el número de conexiones salientes correctas al clúster de backend sea exactamente el mismo que el número de protocolos de enlace SSL más el número de sesiones SSL reutilizadas, como se muestra en los siguientes ejemplos de comandos y resultados.
```
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 el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/). Si cree que ha encontrado una vulnerabilidad de seguridad o tiene dudas sobre la seguridad de App Mesh, consulte las [Directrices de notificación de vulnerabilidades de AWS](https://aws.amazon.com/security/vulnerability-reporting/).
## Solución de problemas de TLS con el equilibrador de carga elástico
**Síntomas**
Al intentar configurar un Equilibrador de carga de aplicación o Equilibrador de carga de red para cifrar el tráfico a un nodo virtual, las comprobaciones de estado del equilibrador de carga y la conectividad pueden producir errores.
**Resolución**
Para determinar la causa raíz del problema, debe comprobar lo siguiente:
+ Para el proxy de Envoy que realiza la terminación de TLS, debe descartar cualquier error de configuración. Siga los pasos que se indicaron anteriormente en [No se puede conectar a un servicio virtual de backend con una política de cliente TLS](#ts-security-tls-client-policy).
+ Para el equilibrador de carga, debe revisar la configuración de `TargetGroup:`
+ Asegúrese de que el puerto `TargetGroup` coincida con el puerto del oyente definido para el nodo virtual.
+ En el caso de los equilibradores de carga de aplicación que son el origen de conexiones TLS a través de HTTP con su servicio, asegúrese de que el protocolo `TargetGroup` esté establecido en `HTTPS`. Si se utilizan comprobaciones de estado, asegúrese de que `HealthCheckProtocol` esté establecido en `HTTPS`.
+ En el caso de los equilibradores de carga de red que son el origen de conexiones TLS a través de TCP con su servicio, asegúrese de que el `TargetGroup` protocolo esté configurado en `TLS`. Si se utilizan comprobaciones de estado, asegúrese de que `HealthCheckProtocol` esté establecido en `TCP`.
**nota**
Cualquier actualización de `TargetGroup` requiere cambiar el nombre `TargetGroup`.
Con esta configuración correcta, el equilibrador de carga debería proporcionar una conexión segura a su servicio mediante el certificado proporcionado al proxy de Envoy.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/). Si cree que ha encontrado una vulnerabilidad de seguridad o tiene dudas sobre la seguridad de App Mesh, consulte las [Directrices de notificación de vulnerabilidades de AWS](https://aws.amazon.com/security/vulnerability-reporting/).
# Solución de problemas de App Mesh para Kubernetes
**importante**
Aviso de fin del soporte: el 30 de septiembre de 2026, AWS dejaremos de ofrecer soporte para AWS App Mesh. Después del 30 de septiembre de 2026, ya no podrás acceder a la AWS App Mesh consola ni a AWS App Mesh los recursos. Para obtener más información, visite esta entrada del blog [Migración desde AWS App Mesh a Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
En este tema se describen los problemas comunes que pueden ocurrir al usar App Mesh con Kubernetes.
## Los recursos de App Mesh creados en Kubernetes no se encuentran en App Mesh
**Síntomas**
Has creado los recursos de App Mesh con la definición de recursos personalizada (CRD) de Kubernetes, pero los recursos que has creado no están visibles en App Mesh cuando utilizas o. Consola de administración de AWS APIs
**Resolución**
La causa probable es un error del controlador de Kubernetes para App Mesh. [Para obtener más información, consulte Solución de problemas en.](https://github.com/aws/aws-app-mesh-controller-for-k8s/blob/master/docs/guide/troubleshooting.md) GitHub Compruebe los registros del controlador para ver si hay errores o advertencias que indiquen que el controlador no ha podido crear ningún recurso.
```
kubectl logs -n appmesh-system -f \
$(kubectl get pods -n appmesh-system -o name | grep controller)
```
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## Las comprobaciones de disponibilidad y vivacidad de los pods tienen errores después de inyectar el sidecar de Envoy
**Síntomas**
Los pods de su aplicación se ejecutaban correctamente anteriormente, pero una vez que se inyecta el sidecar de Envoy en un pod, las comprobaciones de disponibilidad y vivacidad comienzan a producir errores.
**Resolución**
Asegúrese de que el contenedor de Envoy que se inyectó en el pod se haya iniciado con el servicio de administración de Envoy de App Mesh. Puede verificar cualquier error consultando los códigos de error en [Envoy se desconectó del servicio de administración de Envoy de App Mesh mostrando un texto de error](troubleshooting-setup.md#ts-setup-grpc-error-codes). Puede usar el siguiente comando para examinar los registros de Envoy del pod correspondiente.
```
kubectl logs -n appmesh-system -f \
$(kubectl get pods -n appmesh-system -o name | grep controller) \
| grep "gRPC config stream closed"
```
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## Los pods no se registran o se dan de baja como instancias AWS Cloud Map
**Síntomas**
Tus pods de Kubernetes no se registran ni se cancelan del registro AWS Cloud Map como parte de su ciclo de vida. Es posible que un pod se inicie correctamente y esté listo para enviar tráfico, pero no para recibirlo. Cuando se cierra un pod, es posible que los clientes aún conserven su dirección IP e intenten enviarle tráfico, lo cual no funciona.
**Resolución**
Se trata de un problema conocido. Para obtener más información, consulta los [pods no se vuelven automáticos registered/deregistered en Kubernetes](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/159) con problemas. AWS Cloud Map GitHub Debido a la relación entre los pods, los nodos virtuales de App Mesh y los AWS Cloud Map recursos, el [controlador App Mesh para Kubernetes](https://github.com/aws/aws-app-mesh-controller-for-k8s) puede desincronizarse y perder recursos. Por ejemplo, esto puede suceder si se elimina un recurso de nodo virtual de Kubernetes antes de cerrar los pods asociados.
Para mitigar este problema:
+ Asegúrese de ejecutar la última versión del controlador de App Mesh para Kubernetes.
+ Asegúrese de que las letras AWS Cloud Map `namespaceName` y `serviceName` sean correctas en la definición de su nodo virtual.
+ Asegúrese de eliminar todos los pods asociados antes de eliminar la definición de su nodo virtual. Si necesita ayuda para identificar qué pods están asociados a un nodo virtual, consulte [No es posible determinar dónde se ejecuta un pod para un recurso de App Mesh](#ts-kubernetes-where-pod-running).
+ Si el problema persiste, ejecute el siguiente comando para examinar los registros del controlador en busca de errores que puedan ayudar a descubrir el problema subyacente.
```
kubectl logs -n appmesh-system \
$(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)
```
+ Considere la posibilidad de usar el comando siguiente para reiniciar los pods de su controlador. Esto podría solucionar problemas de sincronización.
```
kubectl delete -n appmesh-system \
$(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)
```
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## No es posible determinar dónde se ejecuta un pod para un recurso de App Mesh
**Síntomas**
Cuando ejecuta App Mesh en un clúster de Kubernetes, un operador no puede determinar dónde se ejecuta una carga de trabajo, o pod, para un recurso de App Mesh determinado.
**Resolución**
Los recursos del pod de Kubernetes se anotan con la malla y el nodo virtual a los que están asociados. Puede consultar qué pods se están ejecutando para un nombre de nodo virtual determinado con el siguiente comando.
```
kubectl get pods --all-namespaces -o json | \
jq '.items[] | { metadata } | select(.metadata.annotations."appmesh.k8s.aws/virtualNode" == "virtual-node-name")'
```
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## No se puede determinar cómo qué recurso de App Mesh se está ejecutando un pod
**Síntomas**
Al ejecutar App Mesh en un clúster de Kubernetes, un operador no puede determinar cómo qué recurso de App Mesh se está ejecutando un pod determinado.
**Resolución**
Los recursos del pod de Kubernetes se anotan con la malla y el nodo virtual a los que están asociados. Puede generar los nombres de la malla y de los nodos virtuales consultando el pod directamente con el siguiente comando.
```
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 el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## Los enviados del cliente no pueden comunicarse con App Mesh Envoy Management Service si está deshabilitado IMDSv1
**Síntomas**
Cuando `IMDSv1` está deshabilitado, los Envoys del cliente no pueden comunicar con el plano de control de App Mesh (servicio de administración de Envoy). `IMDSv2` no es compatible con la versión de App Mesh Envoy anterior a la `v1.24.0.0-prod`.
**Resolución**
Para resolver este problema, puede elegir una de estas tres soluciones.
+ Actualice a la versión `v1.24.0.0-prod` o posterior de App Mesh Envoy, que es compatible con `IMDSv2`.
+ Vuelva a habilitar `IMDSv1` en la instancia en la que se esté ejecutando Envoy. Para obtener instrucciones sobre la restauración de `IMDSv1`, consulte [Configurar las opciones de metadatos de la instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html).
+ Si sus servicios se ejecutan en Amazon EKS, se recomienda utilizar roles de IAM para cuentas de servicio (IRSA) para obtener las credenciales. Para obtener instrucciones sobre cómo habilitar IRSA, consulte [Roles de IAM para cuentas de servicio](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html).
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## IRSA no funciona en el contenedor de aplicaciones cuando App Mesh está habilitada y Envoy está inyectado
**Síntomas**
Cuando App Mesh está habilitada en un clúster de Amazon EKS con la ayuda del controlador App Mesh para Amazon EKS, Envoy y los contenedores `proxyinit` se inyectan en el pod de la aplicación. La aplicación no puede asumir `IRSA` y, en su lugar, asume `node role`. Cuando describimos los detalles del pod, vemos que la variable de entorno `AWS_WEB_IDENTITY_TOKEN_FILE` o `AWS_ROLE_ARN` no está incluida en el contenedor de la aplicación.
**Resolución**
Si se define alguna de las variables de entorno `AWS_WEB_IDENTITY_TOKEN_FILE` o `AWS_ROLE_ARN`, el webhook omitirá el pod. No proporcione ninguna de estas variables y el webhook se encargará de inyectarlas por usted.
```
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 el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).