Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Risoluzione dei problemi di App Mesh
**Importante**
Avviso di fine del supporto: il 30 settembre 2026, AWS interromperà il supporto per. AWS App Mesh Dopo il 30 settembre 2026, non potrai più accedere alla AWS App Mesh console o alle risorse. AWS App Mesh Per ulteriori informazioni, consulta questo post di blog [Migrazione AWS App Mesh da Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Questo capitolo illustra le best practice per la risoluzione dei problemi e i problemi più comuni che potresti riscontrare durante l'utilizzo di App Mesh. Seleziona una delle seguenti aree per esaminare le migliori pratiche e i problemi comuni relativi a quell'area.
**Topics**
+ [Best practice per la risoluzione dei problemi di App Mesh](troubleshooting-best-practices.md)
+ [Risoluzione dei problemi relativi alla configurazione di App Mesh](troubleshooting-setup.md)
+ [Risoluzione dei problemi di connettività App Mesh](troubleshooting-connectivity.md)
+ [Risoluzione dei problemi di scalabilità dell'App Mesh](troubleshooting-scaling.md)
+ [Risoluzione dei problemi di osservabilità dell'App Mesh](troubleshooting-observability.md)
+ [Risoluzione dei problemi di sicurezza di App Mesh](troubleshooting-security.md)
+ [Risoluzione dei problemi di App Mesh Kubernetes](troubleshooting-kubernetes.md)
# Best practice per la risoluzione dei problemi di App Mesh
**Importante**
Avviso di fine del supporto: il 30 settembre 2026, AWS verrà interrotto il supporto per. AWS App Mesh Dopo il 30 settembre 2026, non potrai più accedere alla AWS App Mesh console o alle risorse. AWS App Mesh Per ulteriori informazioni, consulta questo post di blog [Migrazione AWS App Mesh da Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Ti consigliamo di seguire le best practice riportate in questo argomento per risolvere i problemi relativi all'utilizzo di App Mesh.
## Abilita l'interfaccia di amministrazione del proxy Envoy
Il proxy Envoy viene fornito con un'interfaccia di amministrazione che è possibile utilizzare per rilevare configurazioni e statistiche e per eseguire altre funzioni amministrative come il drenaggio della connessione. Per ulteriori informazioni, vedere [Interfaccia di amministrazione](https://www.envoyproxy.io/docs/envoy/latest/operations/admin) nella documentazione di Envoy.
Se si utilizza l'endpoint gestito[Immagine dell'inviato](envoy.md), l'endpoint di amministrazione è abilitato per impostazione predefinita sulla porta 9901. Gli esempi forniti in [Risoluzione dei problemi relativi alla configurazione di App Mesh](troubleshooting-setup.md) Visualizza l'URL dell'endpoint di amministrazione di esempio come. `http://my-app.default.svc.cluster.local:9901/`
**Nota**
L'endpoint di amministrazione non deve mai essere esposto alla rete Internet pubblica. Inoltre, consigliamo di monitorare i log degli endpoint di amministrazione, che sono impostati dalla variabile di `ENVOY_ADMIN_ACCESS_LOG_FILE` ambiente come impostazione predefinita. `/tmp/envoy_admin_access.log`
## Abilita l'integrazione con Envoy DogStats D per l'offload metrico
Il proxy Envoy può essere configurato per scaricare le statistiche per il traffico OSI Layer 4 e Layer 7 e per lo stato di salute dei processi interni. Sebbene questo argomento mostri come utilizzare queste statistiche senza scaricare le metriche su sink come CloudWatch Metrics e Prometheus., disporre di queste statistiche in una posizione centralizzata per tutte le applicazioni può aiutarti a diagnosticare i problemi e confermare il comportamento più rapidamente. Per ulteriori informazioni, consulta [Using Amazon CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) e la documentazione di [Prometheus](https://prometheus.io/docs/introduction/overview/).
Puoi configurare i parametri DogStats D impostando i parametri definiti in. [DogStatsVariabili D](envoy-config.md#envoy-dogstatsd-config) Per ulteriori informazioni su DogStats D, consulta la documentazione [DogStatsD.](https://docs.datadoghq.com/developers/dogstatsd/?tab=hostagent) Puoi trovare una dimostrazione dell'offload delle metriche alle AWS CloudWatch metriche nella procedura dettagliata App [Mesh with Amazon ECS](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-ecs-basics) basics. GitHub
## Abilitare log di accesso
Ti consigliamo di abilitare i log di accesso sulle tue applicazioni e di scoprire dettagli sul traffico in transito tra [Nodi virtuali](virtual_nodes.md) [Gateway virtuali](virtual_gateways.md) le tue applicazioni. Per ulteriori informazioni, consulta la sezione [Registrazione degli accessi nella documentazione di Envoy](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/access_logging). I log forniscono informazioni dettagliate sul comportamento del traffico OSI Layer 4 e Layer 7. Quando si utilizza il formato predefinito di Envoy, è possibile analizzare i log di accesso con [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) utilizzando la seguente istruzione di analisi.
```
parse @message "[*] \"* * *\" * * * * * * * * * * *" as StartTime, Method, Path, Protocol, ResponseCode, ResponseFlags, BytesReceived, BytesSent, DurationMillis, UpstreamServiceTimeMillis, ForwardedFor, UserAgent, RequestId, Authority, UpstreamHost
```
## Abilita la registrazione di debug di Envoy negli ambienti di preproduzione
Consigliamo di impostare il livello di registro del proxy Envoy su un ambiente di preproduzione. `debug` I log di debug possono aiutarti a identificare i problemi prima di trasferire la configurazione App Mesh associata all'ambiente di produzione.
Se stai usando l'[immagine Envoy](envoy.md), puoi impostare il livello di registro `debug` tramite la variabile di ambiente. `ENVOY_LOG_LEVEL`
**Nota**
Non è consigliabile utilizzare il `debug` livello negli ambienti di produzione. [L'impostazione del livello su `debug` aumenta la registrazione e può influire sulle prestazioni e sul costo complessivo dei log scaricati su soluzioni come Logs. CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
Quando si utilizza il formato predefinito di Envoy, è possibile analizzare i log dei processi con [CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) Insights utilizzando la seguente istruzione di analisi:
```
parse @message "[*][*][*][*] [*] *" as Time, Thread, Level, Name, Source, Message
```
## Monitora la connettività del proxy Envoy con il piano di controllo App Mesh
Ti consigliamo di monitorare le metriche di Envoy `control_plane.connected_state` per assicurarti che il proxy Envoy comunichi con il piano di controllo dell'App Mesh per recuperare le risorse di configurazione dinamica. [Per ulteriori informazioni, vedere Management Server.](https://www.envoyproxy.io/docs/envoy/latest/configuration/overview/mgmt_server.html)
# Risoluzione dei problemi relativi alla configurazione di App Mesh
**Importante**
Avviso di fine del supporto: il 30 settembre 2026, AWS verrà interrotto il supporto per. AWS App Mesh Dopo il 30 settembre 2026, non potrai più accedere alla AWS App Mesh console o alle risorse. AWS App Mesh Per ulteriori informazioni, consulta questo post di blog [Migrazione AWS App Mesh da Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Questo argomento descrive i problemi più comuni che potrebbero verificarsi con la configurazione di App Mesh.
## Impossibile recuperare l'immagine del contenitore Envoy
**Caratteristiche**
Riceverai il seguente messaggio di errore in un'attività Amazon ECS. L'Amazon ECR *account ID* e quello contenuto *Region* nel messaggio seguente potrebbero essere diversi, a seconda del repository Amazon ECR da cui hai estratto l'immagine del contenitore.
```
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'
```
**Risoluzione**
Questo errore indica che il ruolo di esecuzione dell'attività utilizzato non dispone dell'autorizzazione per comunicare con Amazon ECR e non può estrarre l'immagine del contenitore Envoy dal repository. Il ruolo di esecuzione dell'attività assegnato all'attività Amazon ECS richiede una policy IAM con le seguenti istruzioni:
```
{
"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"
}
```
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## Impossibile connettersi al servizio di gestione App Mesh Envoy
**Caratteristiche**
Il proxy Envoy non è in grado di connettersi al servizio di gestione App Mesh Envoy. Stai vedendo:
+ Errori di connessione rifiutata
+ Timeout di connessione.
+ Errori nella risoluzione dell'endpoint del servizio di gestione App Mesh Envoy
+ Errori gRPC
**Risoluzione**
Assicurati che il tuo proxy Envoy abbia accesso a Internet o a un [endpoint VPC](vpc-endpoints.md) privato e che i tuoi [gruppi di sicurezza](https://docs.aws.amazon.com//vpc/latest/userguide/VPC_SecurityGroups.html) consentano il traffico in uscita sulla porta 443. Gli endpoint del servizio di gestione Envoy pubblico di App Mesh seguono il formato FQDN (Fully Qualified Domain Name).
```
# App Mesh Production Endpoint
appmesh-envoy-management.Region-code.amazonaws.com
# App Mesh Preview Endpoint
appmesh-preview-envoy-management.Region-code.amazonaws.com
```
È possibile eseguire il debug della connessione a EMS utilizzando il comando seguente. Questo invia una richiesta gRPC valida ma vuota all'Envoy Management Service.
```
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
```
Se ricevi questi messaggi, la tua connessione all'Envoy Management Service è funzionante. Per il debug degli errori relativi a gRPC, vedere gli errori [in Envoy disconnesso dal servizio di gestione App Mesh Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes) con testo di errore.
```
grpc-status: 16
grpc-message: Missing Authentication Token
```
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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 disconnesso dal servizio di gestione App Mesh Envoy con testo di errore
**Caratteristiche**
Il proxy Envoy non è in grado di connettersi al servizio di gestione App Mesh Envoy e di riceverne la configurazione. I log del proxy Envoy contengono una voce di registro come la seguente.
```
gRPC config stream closed: gRPC status code, message
```
**Risoluzione**
Nella maggior parte dei casi, la parte del registro relativa ai messaggi dovrebbe indicare il problema. La tabella seguente elenca i codici di stato gRPC più comuni che potreste vedere, le loro cause e le relative risoluzioni.
| Codice di stato gRPC | Causa | Risoluzione |
| --- | --- | --- |
| 0 | Graceful disconnect dal servizio di gestione Envoy. | Non c'è nessun problema. App Mesh disconnette occasionalmente i proxy Envoy con questo codice di stato. Envoy si riconnetterà e continuerà a ricevere aggiornamenti. |
| 3 | L'endpoint mesh (nodo virtuale o gateway virtuale) o una delle risorse associate non è stato trovato. | Ricontrolla la configurazione di Envoy per assicurarti che abbia il nome appropriato della risorsa App Mesh che rappresenta. Se la tua risorsa App Mesh è integrata con altre AWS risorse, come AWS Cloud Map namespace o certificati ACM, assicurati che tali risorse esistano. |
| 7 | Il proxy Envoy non è autorizzato a eseguire un'azione, come connettersi al servizio di gestione Envoy o recuperare le risorse associate. | Assicurati di [creare una policy IAM](proxy-authorization.md#create-iam-policy) che contenga le dichiarazioni politiche appropriate per App Mesh e altri servizi e di allegare tale policy all'utente o al ruolo IAM che il tuo proxy Envoy utilizza per connettersi al servizio di gestione Envoy. |
| 8 | Il numero di proxy Envoy per una determinata risorsa App Mesh supera la quota di servizio a livello di account. | Vedi [Quote del servizio App Mesh](service-quotas.md) per informazioni sulle quote predefinite degli account e su come richiedere un aumento della quota. |
| 16 | Il proxy Envoy non dispone di credenziali di autenticazione valide per. AWS | Assicurati che l'Envoy disponga delle credenziali appropriate per connettersi ai AWS servizi tramite un utente o un ruolo IAM. Un problema noto, [\$124136](https://github.com/envoyproxy/envoy/issues/24136), in Envoy per le versioni v1.24 e precedenti non riesce a recuperare le credenziali se il processo Envoy utilizza più descrittori di file. 1024 Ciò accade quando Envoy serve un volume di traffico elevato. Puoi confermare questo problema controllando i log di Envoy a livello di debug per il testo "». A libcurl function was given a bad argument Per mitigare questo problema, esegui l'aggiornamento alla versione di Envoy o successiva. v1.25.1.0-prod |
Puoi osservare i codici di stato e i messaggi del tuo proxy Envoy con [Amazon CloudWatch Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) utilizzando la seguente query:
```
filter @message like /gRPC config stream closed/
| parse @message "gRPC config stream closed: *, *" as StatusCode, Message
```
[Se il messaggio di errore fornito non è stato utile o il problema persiste, valuta la possibilità di aprire 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)
## Controllo dello stato del container Envoy, sonda di prontezza o sonda di vivacità guasto
**Caratteristiche**
Il tuo proxy Envoy non supera i controlli di integrità in un'attività Amazon ECS, un'istanza Amazon EC2 o un pod Kubernetes. Ad esempio, esegui una query sull'interfaccia di amministrazione di Envoy con il seguente comando e ricevi uno stato diverso da. `LIVE`
```
curl -s http://my-app.default.svc.cluster.local:9901/server_info | jq '.state'
```
**Risoluzione**
Di seguito è riportato un elenco di passaggi di riparazione in base allo stato restituito dal proxy Envoy.
+ `PRE_INITIALIZING`oppure `INITIALIZING` — Il proxy Envoy non ha ancora ricevuto la configurazione o non può connettersi e recuperare la configurazione dal servizio di gestione App Mesh Envoy. È possibile che Envoy riceva un errore dal servizio di gestione di Envoy durante il tentativo di connessione. Per ulteriori informazioni, consulta gli errori in. [Envoy disconnesso dal servizio di gestione App Mesh Envoy con testo di errore](#ts-setup-grpc-error-codes)
+ `DRAINING`— Il proxy Envoy ha iniziato a prosciugare le connessioni in risposta a una `/drain_listeners` richiesta `/healthcheck/fail` or sull'interfaccia di amministrazione di Envoy. Non è consigliabile richiamare questi percorsi sull'interfaccia di amministrazione a meno che tu non stia per terminare l'attività Amazon ECS, l'istanza Amazon EC2 o il pod Kubernetes.
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## Il controllo dello stato di salute dal load balancer all'endpoint mesh non riesce
**Caratteristiche**
L'endpoint mesh è considerato integro dal controllo dello stato del contenitore o dalla sonda di prontezza, ma il controllo dello stato dal load balancer all'endpoint mesh non riesce.
**Risoluzione**
Per risolvere il problema, completa le seguenti attività.
+ Assicurati che il [gruppo di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) associato al tuo endpoint mesh accetti il traffico in entrata sulla porta che hai configurato per il controllo dello stato.
+ Assicurati che il controllo dello stato abbia esito positivo in modo coerente quando richiesto manualmente, ad esempio da un [host bastion all'interno del tuo VPC](https://aws.amazon.com/quickstart/architecture/linux-bastion/).
+ Se stai configurando un controllo dello stato di salute per un nodo virtuale, ti consigliamo di implementare un endpoint per il controllo dello stato nell'applicazione, ad esempio /ping per HTTP. Ciò garantisce che sia il proxy Envoy che l'applicazione siano instradabili dal sistema di bilanciamento del carico.
+ È possibile utilizzare qualsiasi tipo di bilanciamento del carico elastico per il nodo virtuale, a seconda delle funzionalità necessarie. Per ulteriori informazioni, consulta le funzionalità di [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/features/#compare).
+ Se stai configurando un controllo dello stato di integrità per un [gateway virtuale](virtual_gateways.md), ti consigliamo di utilizzare un [sistema di bilanciamento del carico di rete](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html) con un controllo dello stato TCP o TLS sulla porta listener del gateway virtuale. Ciò garantisce che il listener del gateway virtuale sia avviato e pronto ad accettare connessioni.
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## Il gateway virtuale non accetta traffico sulle porte 1024 o inferiori
**Caratteristiche**
Il gateway virtuale non accetta traffico sulla porta 1024 o inferiore, ma accetta traffico su un numero di porta maggiore di 1024. Ad esempio, si interrogano le statistiche di Envoy con il seguente comando e si riceve un valore diverso da zero.
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "update_rejected"
```
Nei log potresti visualizzare un testo simile al seguente che descrive un errore di associazione a una porta privilegiata:
```
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
```
**Risoluzione**
Per risolvere il problema, l'utente specificato per il gateway deve disporre della funzionalità linux. `CAP_NET_BIND_SERVICE` Per ulteriori informazioni, consulta [Capabilities](https://www.man7.org/linux/man-pages/man7/capabilities.7.html) nel Linux Programmer's Manual, [Linux parameters](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_linuxparameters) in ECS Task definition parameters e [Set abilities for a container nella documentazione di](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) Kubernetes.
**Importante**
Fargate deve utilizzare un valore di porta maggiore di 1024.
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
# Risoluzione dei problemi di connettività App Mesh
**Importante**
Avviso di fine del supporto: il 30 settembre 2026, AWS verrà interrotto il supporto per. AWS App Mesh Dopo il 30 settembre 2026, non potrai più accedere alla AWS App Mesh console o alle risorse. AWS App Mesh Per ulteriori informazioni, consulta questo post di blog [Migrazione AWS App Mesh da Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Questo argomento descrive i problemi più comuni che potrebbero verificarsi con la connettività App Mesh.
## Impossibile risolvere il nome DNS per un servizio virtuale
**Caratteristiche**
L'applicazione non è in grado di risolvere il nome DNS di un servizio virtuale a cui sta tentando di connettersi.
**Risoluzione**
Si tratta di un problema noto. Per ulteriori informazioni, consulta il problema [Name VirtualServices by any hostname o](https://github.com/aws/aws-app-mesh-roadmap/issues/65) FQDN. GitHub I servizi virtuali in App Mesh possono essere denominati con qualsiasi nome. Finché esiste un `A` record DNS per il nome di servizio virtuale e l'applicazione è in grado di risolvere il nome del servizio virtuale, la richiesta verrà inoltrata da Envoy e indirizzata alla destinazione appropriata. Per risolvere il problema, aggiungi un `A` record DNS a qualsiasi indirizzo IP non di loopback, ad esempio per il nome del servizio virtuale. `10.10.10.10` Il `A` record DNS può essere aggiunto nelle seguenti condizioni:
+ In Amazon Route 53, se il nome ha il suffisso del nome della tua zona ospitata privata
+ All'interno del file del contenitore dell'applicazione `/etc/hosts`
+ In un server DNS di terze parti che gestisci
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## Impossibile connettersi a un backend di servizio virtuale
**Caratteristiche**
L'applicazione non è in grado di stabilire una connessione a un servizio virtuale definito come backend sul nodo virtuale. Quando si tenta di stabilire una connessione, la connessione potrebbe fallire completamente oppure la richiesta dal punto di vista dell'applicazione potrebbe fallire con un codice di `HTTP 503` risposta.
**Risoluzione**
Se l'applicazione non riesce affatto a connettersi (non viene restituito alcun codice di `HTTP 503` risposta), procedi come segue:
+ Assicurati che il tuo ambiente di calcolo sia configurato per funzionare con App Mesh.
+ Per Amazon ECS, assicurati di avere abilitata la [configurazione proxy](proxy-authorization.md) appropriata. Per una end-to-end procedura dettagliata, consulta [Getting Started with App Mesh e Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/appmesh-getting-started.html).
+ Per Kubernetes, incluso Amazon EKS, assicurati di avere il controller App Mesh più recente installato tramite Helm. Per ulteriori informazioni, consulta [App Mesh Controller](https://hub.helm.sh/charts/aws/appmesh-controller) su Helm Hub o [Tutorial: Configura l'integrazione di App Mesh con Kubernetes](https://docs.aws.amazon.com/app-mesh/latest/userguide/mesh-k8s-integration.html).
+ Per Amazon EC2, assicurati di aver configurato l'istanza Amazon EC2 per il trasferimento tramite proxy del traffico App Mesh. [Per ulteriori informazioni, consulta Update services.](https://docs.aws.amazon.com/app-mesh/latest/userguide/appmesh-getting-started.html#update-services)
+ Assicurati che il contenitore Envoy in esecuzione sul tuo servizio di elaborazione si sia connesso correttamente al servizio di gestione App Mesh Envoy. Puoi confermarlo controllando le statistiche di Envoy per il campo. `control_plane.connected_state` **Per ulteriori informazioni`control_plane.connected_state`, consulta [Monitorare la connettività del proxy Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-best-practices.html#ts-bp-enable-envoy-control-plane-connected-state) nelle nostre best practice per la risoluzione dei problemi.**
Se l'Envoy è stato in grado di stabilire la connessione inizialmente, ma in seguito è stato disconnesso e non si è mai ricollegato, vedi [Envoy disconnesso dal servizio di gestione App Mesh Envoy con](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes) testo di errore per risolvere il motivo della disconnessione.
Se l'applicazione si connette ma la richiesta fallisce con un codice di risposta, prova quanto segue: `HTTP 503`
+ Assicurati che il servizio virtuale a cui ti stai connettendo esista nella mesh.
+ Assicurati che il servizio virtuale abbia un provider (un router virtuale o un nodo virtuale).
+ Quando usi Envoy come proxy HTTP, se vedi che il traffico in uscita arriva `cluster.cds_egress_*_mesh-allow-all` invece della destinazione corretta tramite le statistiche di Envoy, molto probabilmente Envoy non sta instradando le richieste correttamente. `filter_chains` Ciò può essere dovuto all'utilizzo di un nome di servizio virtuale non qualificato. Si consiglia di utilizzare il nome di rilevamento del servizio effettivo come nome del servizio virtuale, poiché il proxy Envoy comunica con altri servizi virtuali tramite i rispettivi nomi.
[Per ulteriori informazioni, consulta Servizi virtuali.](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_services.html)
+ Controlla i log del proxy Envoy per verificare la presenza di uno dei seguenti messaggi di errore:
+ `No healthy upstream`— Il nodo virtuale verso cui il proxy Envoy sta tentando di indirizzare non ha endpoint risolti o non ha endpoint integri. Assicurati che il nodo virtuale di destinazione abbia le impostazioni corrette per il rilevamento del servizio e il controllo dello stato di salute.
Se le richieste al servizio non vanno a buon fine durante l'implementazione o il ridimensionamento del servizio virtuale di backend, segui le istruzioni riportate in. [Alcune richieste hanno esito negativo con il codice di stato HTTP `503` quando un servizio virtuale ha un provider di nodi virtuali](#ts-connectivity-virtual-node-provider)
+ `No cluster match for URL`— Ciò è probabilmente causato dall'invio di una richiesta a un servizio virtuale che non corrisponde ai criteri definiti da nessuna delle rotte definite da un provider di router virtuale. Assicurati che le richieste dall'applicazione vengano inviate a un percorso supportato assicurandoti che il percorso e le intestazioni delle richieste HTTP siano corretti.
+ `No matching filter chain found`— Ciò è probabilmente causato dall'invio di una richiesta a un servizio virtuale su una porta non valida. Assicurati che le richieste provenienti dall'applicazione utilizzino la stessa porta specificata sul router virtuale.
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## Impossibile connettersi a un servizio esterno
**Caratteristiche**
L'applicazione non è in grado di connettersi a un servizio esterno alla mesh, ad esempio`amazon.com`.
**Risoluzione**
Per impostazione predefinita, App Mesh non consente il traffico in uscita dalle applicazioni all'interno della mesh verso alcuna destinazione esterna alla mesh. Per abilitare la comunicazione con un servizio esterno, sono disponibili due opzioni:
+ Imposta il [filtro in uscita](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html) sulla risorsa mesh su. `ALLOW_ALL` Questa impostazione consentirà a qualsiasi applicazione all'interno della mesh di comunicare con qualsiasi indirizzo IP di destinazione all'interno o all'esterno della mesh.
+ Modella il servizio esterno nella mesh utilizzando un servizio virtuale, un router virtuale, una route e un nodo virtuale. Ad esempio, per modellare il servizio esterno`example.com`, è possibile creare un servizio virtuale denominato `example.com` con un router e un routing virtuali che invii tutto il traffico a un nodo virtuale con un nome host di rilevamento del servizio DNS di. `example.com`
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## Impossibile connettersi a un server MySQL o SMTP
**Caratteristiche**
Quando si consente il traffico in uscita verso tutte le destinazioni (Mesh `EgressFilter type` =`ALLOW_ALL`), ad esempio un server SMTP o un database MySQL utilizzando una definizione di nodo virtuale, la connessione dall'applicazione non riesce. Ad esempio, il seguente è un messaggio di errore generato dal tentativo di connessione a un server MySQL.
```
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
```
**Risoluzione**
Si tratta di un problema noto che viene risolto utilizzando l'immagine App Mesh versione 1.15.0 o successiva. Per ulteriori informazioni, consulta il [problema Impossibile connettersi a MySQL con App Mesh](https://github.com/aws/aws-app-mesh-roadmap/issues/62). GitHub Questo errore si verifica perché il listener in uscita in Envoy configurato da App Mesh aggiunge il filtro listener Envoy TLS Inspector. Per ulteriori informazioni, consulta [TLS Inspector](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/tls_inspector#config-listener-filters-tls-inspector) nella documentazione di Envoy. Questo filtro valuta se una connessione utilizza o meno TLS ispezionando il primo pacchetto inviato dal client. Con MySQL e SMTP, tuttavia, il server invia il primo pacchetto dopo la connessione. Per ulteriori informazioni su MySQL, [consulta Initial](https://dev.mysql.com/doc/internals/en/initial-handshake.html) Handshake nella documentazione di MySQL. Poiché il server invia il primo pacchetto, l'ispezione del filtro fallisce.
**Per risolvere questo problema a seconda della versione di Envoy in uso:**
+ Se la versione Envoy dell'immagine App Mesh è 1.15.0 o successiva, non modellare servizi esterni come MySQL, **SMTP**, **MSSQL**, **ecc.** come backend per il nodo virtuale dell'applicazione.
+ **Se la versione Envoy dell'immagine App Mesh è precedente alla 1.15.0, aggiungi port `3306` all'elenco di valori per i `APPMESH_EGRESS_IGNORED_PORTS` tuoi servizi per **MySQL** e come porta che stai utilizzando per STMP.**
**Importante**
Sebbene le porte SMTP standard siano`25`, e `587``465`, dovresti aggiungere solo la porta che stai utilizzando e non tutte e tre. `APPMESH_EGRESS_IGNORED_PORTS`
Per ulteriori informazioni, consulta [Update services](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-kubernetes.html#create-update-services) for Kubernetes, [Update services for](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ecs.html#update-services) Amazon ECS o [Update services for Amazon](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ec2.html#update-services) EC2.
Se il problema persiste, puoi fornirci i dettagli su cosa stai riscontrando utilizzando il [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/62) esistente o contattare l'[AWS assistenza](https://aws.amazon.com/premiumsupport/).
## Impossibile connettersi a un servizio modellato come nodo virtuale TCP o router virtuale in App Mesh
**Caratteristiche**
L'applicazione non è in grado di connettersi a un backend che utilizza l'impostazione del protocollo TCP nella definizione App Mesh [PortMapping](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_PortMapping.html).
**Risoluzione**
Si tratta di un problema noto. Per ulteriori informazioni, consulta [Routing verso più destinazioni TCP sulla stessa porta su](https://github.com/aws/aws-app-mesh-roadmap/issues/195). GitHub App Mesh attualmente non consente a più destinazioni di backend modellate come TCP di condividere la stessa porta a causa delle restrizioni nelle informazioni fornite al proxy Envoy su OSI Layer 4. Per assicurarti che il traffico TCP possa essere instradato in modo appropriato per tutte le destinazioni di backend, procedi come segue:
+ Assicurati che tutte le destinazioni utilizzino una porta unica. Se si utilizza un provider di router virtuale per il servizio virtuale di backend, è possibile modificare la porta del router virtuale senza modificare la porta sui nodi virtuali verso cui viene indirizzata. Ciò consente alle applicazioni di aprire connessioni sulla porta del router virtuale mentre il proxy Envoy continua a utilizzare la porta definita nel nodo virtuale.
+ Se la destinazione modellata come TCP è un server MySQL o qualsiasi altro protocollo basato su TCP in cui il server invia i primi pacchetti dopo la connessione, vedere. [Impossibile connettersi a un server MySQL o SMTP](#ts-connectivity-troubleshooting-mysql-and-smtp)
Se il problema persiste, puoi fornirci i dettagli su cosa stai riscontrando utilizzando il [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/195) esistente o contattare l'[AWS assistenza](https://aws.amazon.com/premiumsupport/).
## La connettività riesce al servizio non elencato come backend di servizio virtuale per un nodo virtuale
**Caratteristiche**
L'applicazione è in grado di connettersi e inviare traffico verso una destinazione che non è specificata come backend di servizio virtuale sul nodo virtuale.
**Risoluzione**
Se le richieste hanno esito positivo verso una destinazione che non è stata modellata nell'App Mesh APIs, la causa più probabile è che il tipo di [filtro in uscita](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html) della mesh è stato impostato su. `ALLOW_ALL` Quando il filtro in uscita è impostato su`ALLOW_ALL`, una richiesta in uscita dall'applicazione che non corrisponde a una destinazione modellata (backend) verrà inviata all'indirizzo IP di destinazione impostato dall'applicazione.
Se desideri impedire il traffico verso destinazioni non modellate nella mesh, valuta la possibilità di impostare il valore del filtro in uscita su. `DROP_ALL`
**Nota**
L'impostazione del valore del filtro in uscita della mesh influisce su tutti i nodi virtuali all'interno della mesh.
La configurazione `egress_filter` come `DROP_ALL` e l'abilitazione di TLS non sono disponibili per il traffico in uscita che non è diretto a un dominio. AWS
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## Alcune richieste hanno esito negativo con il codice di stato HTTP `503` quando un servizio virtuale ha un provider di nodi virtuali
**Caratteristiche**
Una parte delle richieste dell'applicazione non viene inviata a un backend di servizi virtuali che utilizza un provider di nodi virtuali anziché un provider di router virtuale. Quando si utilizza un provider di router virtuale per il servizio virtuale, le richieste non hanno esito negativo.
**Risoluzione**
Si tratta di un problema noto. Per ulteriori informazioni, consulta la [politica Riprova sul provider Virtual Node for a Virtual Service](https://github.com/aws/aws-app-mesh-roadmap/issues/194) on GitHub. Quando si utilizza un nodo virtuale come provider per un servizio virtuale, non è possibile specificare la politica di ripetizione dei tentativi predefinita che si desidera che i client del servizio virtuale utilizzino. In confronto, i provider di router virtuali consentono di specificare le politiche di riprova perché sono una proprietà delle risorse del percorso secondario.
Per ridurre gli errori di richiesta ai provider di nodi virtuali, utilizza invece un provider di router virtuale e specifica una politica di riprova sulle relative rotte. Per altri modi per ridurre gli errori nelle richieste delle applicazioni, consulta. [Best practice per App Mesh](best-practices.md)
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## Impossibile connettersi a un file system Amazon EFS
**Caratteristiche**
Quando si configura un'attività Amazon ECS con un file system Amazon EFS come volume, l'attività non inizia con il seguente errore.
```
ResourceInitializationError: failed to invoke EFS utils commands to set up EFS volumes: stderr: mount.nfs4: Connection refused : unsuccessful EFS utils command execution; code: 32
```
**Risoluzione**
Si tratta di un problema noto. Questo errore si verifica perché la connessione NFS ad Amazon EFS si verifica prima dell'avvio dei container inclusi nell'attività. Questo traffico viene indirizzato dalla configurazione del proxy a Envoy, che a questo punto non sarà in esecuzione. A causa dell'ordine di avvio, il client NFS non riesce a connettersi al file system Amazon EFS e l'attività non viene avviata. Per risolvere il problema, aggiungi port `2049` all'elenco di valori per l'`EgressIgnoredPorts`impostazione nella configurazione proxy della definizione dell'attività Amazon ECS. Per ulteriori informazioni, consulta [Configurazione del proxy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#proxyConfiguration).
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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 connettività riesce correttamente al servizio, ma la richiesta in arrivo non viene visualizzata nei log di accesso, nelle tracce o nelle metriche di accesso di Envoy
**Caratteristiche**
Anche se l'applicazione è in grado di connettersi e inviare richieste a un'altra applicazione, non è possibile visualizzare le richieste in arrivo nei registri di accesso o nelle informazioni di tracciamento del proxy Envoy.
**Risoluzione**
Si tratta di un problema noto. Per ulteriori informazioni, consulta il problema di configurazione delle regole di [iptables](https://github.com/aws/aws-app-mesh-roadmap/issues/166) su Github. Il proxy Envoy intercetta solo il traffico in entrata verso la porta su cui è in ascolto il nodo virtuale corrispondente. Le richieste a qualsiasi altra porta bypasseranno il proxy Envoy e raggiungeranno direttamente il servizio dietro di esso. Per consentire al proxy Envoy di intercettare il traffico in entrata del servizio, è necessario impostare il nodo virtuale e il servizio in modo che vengano ascoltati sulla stessa porta.
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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'impostazione delle variabili di `HTTPS_PROXY` ambiente`HTTP_PROXY`/a livello di contenitore non funziona come previsto.
**Caratteristiche**
Quando HTTP\$1PROXY/HTTPS\$1PROXY è impostato come variabile di ambiente in:
+ Contenitore di app nella definizione dell'attività con App Mesh abilitato, le richieste inviate allo spazio dei nomi dei servizi App Mesh riceveranno risposte di `HTTP 500` errore dal sidecar Envoy.
+ Contenitore Envoy nella definizione delle attività con App Mesh abilitato, le richieste provenienti dal sidecar Envoy non passeranno attraverso il server `HTTPS` proxy`HTTP`/e la variabile di ambiente non funzionerà.
**Risoluzione**
Per il contenitore dell'app:
App Mesh funziona facendo sì che il traffico all'interno dell'attività passi attraverso il proxy Envoy. `HTTP_PROXY`/`HTTPS_PROXY`configuration sovrascrive questo comportamento configurando il traffico del contenitore in modo che passi attraverso un proxy esterno diverso. Il traffico verrà comunque intercettato da Envoy, ma non supporta l'inoltro del traffico mesh tramite proxy esterno.
Se desideri utilizzare come proxy tutto il traffico non mesh, imposta `NO_PROXY` in modo da includere il CIDR/namespace della tua mesh, il localhost e gli endpoint della credenziale, come nell'esempio seguente.
```
NO_PROXY=localhost,127.0.0.1,169.254.169.254,169.254.170.2,10.0.0.0/16
```
Per il contenitore Envoy:
Envoy non supporta un proxy generico. Non è consigliabile impostare queste variabili.
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## I timeout delle richieste upstream vengono interrotti anche dopo aver impostato il timeout per le rotte.
**Caratteristiche**
Hai definito il timeout per:
+ I percorsi, ma continui a ricevere un errore di timeout della richiesta upstream.
+ Il listener del nodo virtuale e il timeout e il timeout dei tentativi per le rotte, ma si verifica comunque un errore di timeout della richiesta upstream.
**Risoluzione**
Affinché le richieste ad alta latenza superiori a 15 secondi vengano completate correttamente, è necessario specificare un timeout sia a livello di routing che a livello di listener del nodo virtuale.
Se specificate un timeout del percorso superiore ai 15 secondi predefiniti, assicuratevi che il timeout sia specificato anche per il listener per tutti i nodi virtuali partecipanti. Tuttavia, se riduci il timeout a un valore inferiore a quello predefinito, è facoltativo aggiornare i timeout nei nodi virtuali. [Per ulteriori informazioni sulle opzioni per la configurazione di nodi e percorsi virtuali, consulta nodi e percorsi [virtuali](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html).](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html)
**Se hai specificato una **politica per i nuovi tentativi**, la durata specificata per il timeout della richiesta deve essere sempre maggiore o uguale al *timeout dei tentativi* moltiplicato per il *numero massimo di tentativi definito nella politica di nuovi tentativi*.** Ciò consente di completare correttamente la richiesta con tutti i tentativi. Per ulteriori informazioni, consulta [percorsi](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html).
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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 risponde con una richiesta HTTP Bad.
**Caratteristiche**
Envoy risponde con **HTTP 400 Bad request** per tutte le richieste inviate tramite Network Load Balancer (NLB). Quando controlliamo i log di Envoy, vediamo:
+ Registri di debug:
```
dispatch error: http/1.1 protocol error: HPE_INVALID_METHOD
```
+ Registri di accesso:
```
"- - HTTP/1.1" 400 DPE 0 11 0 - "-" "-" "-" "-" "-"
```
**Risoluzione**
La risoluzione è disabilitare la versione 2 del protocollo proxy sugli attributi PPv2 del gruppo [target](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-group-attributes) del vostro NLB.
Ad oggi non PPv2 è supportato dal gateway virtuale e dal nodo virtuale Envoy che vengono eseguiti utilizzando il piano di controllo App Mesh. Se distribuisci NLB utilizzando il controller di AWS bilanciamento del carico su Kubernetes, disabilita impostando il seguente attributo su: PPv2 `false`
```
service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: proxy_protocol_v2.enabled
```
Vedi [AWS Load Balancer Controller Annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/#resource-attributestrue) per maggiori dettagli sugli attributi delle risorse NLB.
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## Impossibile configurare correttamente il timeout.
**Caratteristiche**
Il timeout della richiesta scade entro 15 secondi anche dopo aver configurato il timeout sul listener del nodo virtuale e il timeout sul percorso verso il backend del nodo virtuale.
**Risoluzione**
Assicurati che il servizio virtuale corretto sia incluso nell'elenco dei backend.
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
# Risoluzione dei problemi di scalabilità dell'App Mesh
**Importante**
Avviso di fine del supporto: il 30 settembre 2026, AWS verrà interrotto il supporto per. AWS App Mesh Dopo il 30 settembre 2026, non potrai più accedere alla AWS App Mesh console o alle risorse. AWS App Mesh Per ulteriori informazioni, consulta questo post di blog [Migrazione AWS App Mesh da Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Questo argomento descrive i problemi più comuni che potrebbero verificarsi con il ridimensionamento di App Mesh.
## La connettività fallisce e i controlli di integrità dei container falliscono quando si scalano oltre 50 repliche per un gateway virtuale node/virtual
**Caratteristiche**
Quando si ridimensiona il numero di repliche, ad esempio attività Amazon ECS, pod Kubernetes o istanze Amazon EC2, per un gateway node/virtual virtuale oltre 50, i controlli dello stato dei container Envoy per Envoy nuovi e attualmente in esecuzione iniziano a fallire. Le applicazioni downstream che inviano traffico al gateway virtuale iniziano a registrare errori nelle richieste con codice di stato HTTP. node/virtual `503`
**Risoluzione**
La quota predefinita di App Mesh per il numero di Envoys per gateway virtuale node/virtual è 50. Quando il numero di Envoy in esecuzione supera questa quota, gli Envoy nuovi e attualmente in esecuzione non riescono a connettersi al servizio di gestione Envoy di App Mesh con il codice di stato gRPC (). `8` `RESOURCE_EXHAUSTED` Questa quota può essere aumentata. Per ulteriori informazioni, consulta [Quote del servizio App Mesh](service-quotas.md).
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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 richieste hanno esito negativo `503` quando il backend di un servizio virtuale viene scalato orizzontalmente o verticalmente
**Caratteristiche**
Quando un servizio virtuale di backend viene scalato orizzontalmente o internamente, le richieste provenienti dalle applicazioni downstream hanno esito negativo e viene assegnato un codice di stato. `HTTP 503`
**Risoluzione**
App Mesh consiglia diversi approcci per mitigare i casi di errore scalando le applicazioni orizzontalmente. Per informazioni dettagliate su come prevenire questi errori, consulta. [Best practice per App Mesh](best-practices.md)
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## Il contenitore Envoy si blocca con segfault in caso di carico aumentato
**Caratteristiche**
In caso di carico di traffico elevato, il proxy Envoy si blocca a causa di un errore di segmentazione (codice di uscita di Linux). `139` I log dei processi di Envoy contengono un'istruzione come la seguente.
```
Caught Segmentation fault, suspect faulting address 0x0"
```
**Risoluzione**
Il proxy Envoy ha probabilmente violato il nofile ulimit predefinito del sistema operativo, il limite al numero di file che un processo può avere aperti alla volta. Questa violazione è dovuta al traffico che causa un maggior numero di connessioni, che consumano socket aggiuntivi del sistema operativo. Per risolvere questo problema, aumentate il valore ulimit nofile sul sistema operativo host. Se utilizzi Amazon ECS, questo limite può essere modificato tramite le impostazioni [Ulimit nelle impostazioni](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html) dei limiti delle [risorse](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_limits) della definizione dell'attività.
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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'aumento delle risorse predefinite non si riflette nei limiti del servizio
**Caratteristiche**
Dopo aver aumentato il limite predefinito delle risorse App Mesh, il nuovo valore non si riflette quando si esaminano i limiti del servizio.
**Risoluzione**
Sebbene i nuovi limiti non siano attualmente indicati, i clienti possono comunque esercitarli.
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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'applicazione si arresta in modo anomalo a causa di un numero enorme di chiamate per i controlli sanitari.
**Caratteristiche**
Dopo aver abilitato i controlli sanitari attivi per un nodo virtuale, si verifica un aumento del numero di chiamate ai controlli sanitari. L'applicazione si arresta in modo anomalo a causa del notevole aumento del volume di chiamate per il controllo dello stato di salute effettuate all'applicazione.
**Risoluzione**
Quando il controllo attivo dello stato è abilitato, ogni endpoint Envoy del downstream (client) invia richieste di integrità a ciascun endpoint del cluster upstream (server) per prendere decisioni di routing. Di conseguenza, il numero totale di richieste di controllo dello stato sarebbe \$1 \$1. `number of client Envoys` `number of server Envoys` `active health check frequency`
Per risolvere questo problema, modificate la frequenza della sonda per i controlli sanitari, in modo da ridurre il volume totale delle sonde per i controlli sanitari. Oltre ai controlli sanitari attivi, App Mesh consente di configurare il [rilevamento dei valori anomali](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_OutlierDetection.html) come mezzo di controllo passivo dello stato. Utilizza il rilevamento dei valori anomali per configurare quando rimuovere un determinato host in base a risposte consecutive. `5xx`
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
# Risoluzione dei problemi di osservabilità dell'App Mesh
**Importante**
Avviso di fine del supporto: il 30 settembre 2026, AWS verrà interrotto il supporto per. AWS App Mesh Dopo il 30 settembre 2026, non potrai più accedere alla AWS App Mesh console o alle risorse. AWS App Mesh Per ulteriori informazioni, consulta questo post di blog [Migrazione AWS App Mesh da Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Questo argomento descrive i problemi più comuni che potresti riscontrare con l'osservabilità di App Mesh.
## Impossibile visualizzare le AWS X-Ray tracce delle mie applicazioni
**Caratteristiche**
L'applicazione in App Mesh non visualizza le informazioni di tracciamento a raggi X nella console X-Ray o. APIs
**Risoluzione**
Per utilizzare X-Ray in App Mesh, è necessario configurare correttamente i componenti per abilitare la comunicazione tra l'applicazione, i contenitori sidecar e il servizio X-Ray. Effettua le seguenti operazioni per confermare che X-Ray sia stato impostato correttamente:
+ Assicurati che il protocollo listener App Mesh Virtual Node non sia impostato come`TCP`.
+ Assicurati che il contenitore X-Ray distribuito con l'applicazione esponga la porta `2000` UDP e funzioni come utente. `1337` Per ulteriori informazioni, consulta l'esempio di [Amazon ECS X-Ray](https://github.com/aws/aws-app-mesh-examples/blob/main/walkthroughs/howto-ecs-basics/deploy/2-meshify.yaml#L374-L386) su. GitHub
+ Assicurati che il contenitore Envoy abbia il tracciamento abilitato. Se si utilizza l'[immagine App Mesh Envoy](envoy.md), è possibile abilitare X-Ray impostando la variabile di `ENABLE_ENVOY_XRAY_TRACING` ambiente su un valore di `1` e la `XRAY_DAEMON_PORT` variabile di ambiente su. `2000`
+ Se hai inserito X-Ray nel codice dell'applicazione con uno [dei SDKs ](https://docs.aws.amazon.com/xray/index.html) linguaggi specifici, assicurati che sia configurato correttamente seguendo le guide per la tua lingua.
+ [Se tutti gli elementi precedenti sono configurati correttamente, esaminate i registri del contenitore X-Ray per individuare eventuali errori e seguire le istruzioni riportate in Risoluzione dei problemi. AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-troubleshooting.html) Una spiegazione più dettagliata dell'integrazione di X-Ray in App Mesh è disponibile in [Integrating X-Ray with](https://aws.amazon.com/blogs/compute/integrating-aws-x-ray-with-aws-app-mesh/) App Mesh.
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## Impossibile visualizzare i parametri di Envoy per le mie applicazioni nei parametri di Amazon CloudWatch
**Caratteristiche**
La tua applicazione in App Mesh non emette metriche generate dal proxy Envoy nelle metriche. CloudWatch
**Risoluzione**
Quando utilizzi le CloudWatch metriche in App Mesh, devi configurare correttamente diversi componenti per abilitare la comunicazione tra il proxy Envoy, il sidecar CloudWatch dell'agente e il servizio di metrica. CloudWatch Segui i passaggi seguenti per confermare che le CloudWatch metriche per il proxy Envoy siano state configurate correttamente:
+ Assicurati di utilizzare l'immagine dell' CloudWatch agente per App Mesh. Per ulteriori informazioni, consulta [App Mesh CloudWatch agent](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent) on GitHub.
+ Assicurati di aver configurato l' CloudWatch agente per App Mesh in modo appropriato seguendo le istruzioni d'uso specifiche della piattaforma. Per ulteriori informazioni, consulta [App Mesh CloudWatch agent](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent#usage) on GitHub.
+ Se tutti gli elementi precedenti sono configurati correttamente, esamina i registri del contenitore dell' CloudWatch agente per individuare eventuali errori e segui le indicazioni fornite in [Risoluzione dei problemi dell' CloudWatch agente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html).
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## Impossibile configurare regole di campionamento personalizzate per le tracce AWS X-Ray
**Caratteristiche**
L'applicazione utilizza il tracciamento a raggi X, ma non è possibile configurare le regole di campionamento per le tracce.
**Risoluzione**
Poiché App Mesh Envoy attualmente non supporta la **configurazione del campionamento a raggi X dinamici**, sono disponibili le seguenti soluzioni alternative.
Se la tua versione di Envoy è `1.19.1` o successiva, hai le seguenti opzioni.
+ Per impostare solo la frequenza di campionamento, usa la variabile di `XRAY_SAMPLING_RATE` ambiente sul contenitore Envoy. Il valore deve essere specificato come decimale tra `0` e (100%). `1.00` Per ulteriori informazioni, consulta [AWS X-Ray variabili](envoy-config.md#envoy-xray-config).
+ Per configurare le regole di campionamento personalizzate localizzate per il tracciante X-Ray, utilizzate la variabile di `XRAY_SAMPLING_RULE_MANIFEST` ambiente per specificare un percorso del file nel file system contenitore Envoy. *Per ulteriori informazioni, consulta le regole di [campionamento](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling) nella Guida per gli sviluppatori.AWS X-Ray *
Se la tua versione di Envoy è precedente alla`1.19.1`, procedi come segue.
+ Utilizzate la variabile di `ENVOY_TRACING_CFG_FILE` ambiente per modificare la frequenza di campionamento. Per ulteriori informazioni, consulta [Variabili di configurazione di Envoy](envoy-config.md). Specificate una configurazione di tracciamento personalizzata e definite le regole di campionamento locali. Per ulteriori informazioni, vedere [Envoy X-Ray](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/trace/v3/xray.proto.html#config-trace-v3-xrayconfig) config.
+ Esempio di configurazione di tracciamento personalizzata per la variabile di ambiente: `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
```
+ Per i dettagli sulla configurazione per il manifesto delle regole di campionamento nella `samplingRuleManifest` proprietà, vedere [Configurazione dell'X-Ray SDK for](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling) Go.
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
# Risoluzione dei problemi di sicurezza di App Mesh
**Importante**
Avviso di fine del supporto: il 30 settembre 2026, AWS verrà interrotto il supporto per. AWS App Mesh Dopo il 30 settembre 2026, non potrai più accedere alla AWS App Mesh console o alle risorse. AWS App Mesh Per ulteriori informazioni, consulta questo post di blog [Migrazione AWS App Mesh da Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Questo argomento descrive i problemi più comuni che potresti riscontrare con la sicurezza App Mesh.
## Impossibile connettersi a un servizio virtuale di backend con una politica client TLS
**Caratteristiche**
Quando si aggiunge una policy client TLS a un backend di servizio virtuale in un nodo virtuale, la connettività a quel backend fallisce. Quando si tenta di inviare traffico al servizio di backend, le richieste falliscono con un codice di `HTTP 503` risposta e il messaggio di errore:. `upstream connect error or disconnect/reset before headers. reset reason: connection failure`
**Risoluzione**
Per determinare la causa principale del problema, ti consigliamo di utilizzare i registri dei processi del proxy Envoy per aiutarti a diagnosticare il problema. Per ulteriori informazioni, consulta [Abilita la registrazione di debug di Envoy negli ambienti di preproduzione](troubleshooting-best-practices.md#ts-bp-enable-envoy-debug-logging). Utilizza il seguente elenco per determinare la causa dell'errore di connessione:
+ Assicurati che la connettività al backend funzioni correttamente escludendo gli errori menzionati in. [Impossibile connettersi a un backend di servizio virtuale](troubleshooting-connectivity.md#ts-connectivity-virtual-service-backend)
+ Nei log dei processi di Envoy, cerca i seguenti errori (registrati a livello di debug).
```
TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
```
Questo errore è causato da uno o più dei seguenti motivi:
+ Il certificato non è stato firmato da una delle autorità di certificazione definite nel TLS Client Policy Trust Bundle.
+ Il certificato non è più valido (scaduto).
+ Il nome alternativo del soggetto (SAN) non corrisponde al nome host DNS richiesto.
+ Assicurati che il certificato offerto dal servizio di backend sia valido, che sia firmato da una delle autorità di certificazione incluse nel tuo TLS Client Policies Trust Bundle e che soddisfi i criteri definiti in. [Transport Layer Security (TLS)](tls.md)
+ Se l'errore che ricevi è simile a quello riportato di seguito, significa che la richiesta sta ignorando il proxy Envoy e sta raggiungendo direttamente l'applicazione. Quando si invia traffico, le statistiche su Envoy non cambiano, il che indica che Envoy non è sulla strada giusta per decrittografare il traffico. Nella configurazione proxy del nodo virtuale, assicurati che `AppPorts` contenga il valore corretto che l'applicazione sta ascoltando.
```
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
```
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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) Se ritieni di aver trovato una vulnerabilità di sicurezza o hai domande sulla sicurezza di App Mesh, consulta le linee guida per la [segnalazione delle AWS vulnerabilità](https://aws.amazon.com/security/vulnerability-reporting/).
## Impossibile connettersi a un servizio virtuale di backend quando l'applicazione sta originando TLS
**Caratteristiche**
Quando si origina una sessione TLS da un'applicazione, anziché dal proxy Envoy, la connettività a un servizio virtuale di backend non funziona.
**Risoluzione**
Si tratta di un problema noto. Per ulteriori informazioni, consulta il problema relativo alla [richiesta di funzionalità: negoziazione TLS tra l'applicazione downstream e il](https://github.com/aws/aws-app-mesh-roadmap/issues/162) proxy upstream. GitHub In App Mesh, l'origine TLS è attualmente supportata dal proxy Envoy ma non dall'applicazione. Per utilizzare il supporto di origine TLS su Envoy, disabilita l'origine TLS nell'applicazione. Ciò consente all'Envoy di leggere le intestazioni delle richieste in uscita e inoltrare la richiesta alla destinazione appropriata tramite una sessione TLS. Per ulteriori informazioni, consulta [Transport Layer Security (TLS)](tls.md).
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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) Se ritieni di aver trovato una vulnerabilità di sicurezza o hai domande sulla sicurezza di App Mesh, consulta le linee guida per la [segnalazione delle AWS vulnerabilità](https://aws.amazon.com/security/vulnerability-reporting/).
## Impossibile affermare che la connettività tra i proxy Envoy utilizzi TLS
**Caratteristiche**
L'applicazione ha abilitato la terminazione TLS sul nodo virtuale o sul listener del gateway virtuale o l'origine TLS sulla policy del client TLS di backend, ma non è possibile affermare che la connettività tra i proxy Envoy avvenga su una sessione negoziata con TLS.
**Risoluzione**
Le fasi definite in questa risoluzione utilizzano l'interfaccia di amministrazione di Envoy e le statistiche di Envoy. Per informazioni sulla configurazione di questi, consulta e. [Abilita l'interfaccia di amministrazione del proxy Envoy](troubleshooting-best-practices.md#ts-bp-enable-proxy-admin-interface) [Abilita l'integrazione con Envoy DogStats D per l'offload metrico](troubleshooting-best-practices.md#ts-bp-enable-envoy-statsd-integration) I seguenti esempi di statistiche utilizzano l'interfaccia di amministrazione per semplicità.
+ Per il proxy Envoy che esegue la terminazione TLS:
+ Assicurati che il certificato TLS sia stato avviato nella configurazione di Envoy con il seguente comando.
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
Nell'output restituito, dovresti vedere almeno una voce sotto il certificato utilizzato nella terminazione `certificates[].cert_chain` TLS.
+ Assicurati che il numero di connessioni in entrata riuscite al listener del proxy sia esattamente uguale al numero di handshake SSL più il numero di sessioni SSL riutilizzate, come mostrato dai comandi e dall'output di esempio seguenti.
```
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)
```
+ Per il proxy Envoy che esegue l'origine TLS:
+ Assicurati che il trust store TLS sia stato avviato nella configurazione di Envoy con il seguente comando.
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
Dovresti vedere almeno una voce sotto `certificates[].ca_certs` per i certificati utilizzati per convalidare il certificato del backend durante l'origine del TLS.
+ Assicurati che il numero di connessioni in uscita riuscite al cluster di backend sia esattamente lo stesso del numero di handshake SSL più il numero di sessioni SSL riutilizzate, come mostrato dai seguenti comandi e output di esempio.
```
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)
```
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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) Se ritieni di aver trovato una vulnerabilità di sicurezza o hai domande sulla sicurezza di App Mesh, consulta le linee guida per la [segnalazione delle AWS vulnerabilità](https://aws.amazon.com/security/vulnerability-reporting/).
## Risoluzione dei problemi relativi al TLS con Elastic Load Balancing
**Caratteristiche**
Quando si tenta di configurare un Application Load Balancer o un Network Load Balancer per crittografare il traffico verso un nodo virtuale, i controlli di connettività e di integrità del load balancer possono fallire.
**Risoluzione**
Per determinare la causa principale del problema, è necessario verificare quanto segue:
+ Affinché il proxy Envoy esegua la terminazione TLS, è necessario escludere eventuali errori di configurazione. Segui i passaggi indicati sopra in. [Impossibile connettersi a un servizio virtuale di backend con una politica client TLS](#ts-security-tls-client-policy)
+ Per il bilanciamento del carico, è necessario esaminare la configurazione di `TargetGroup:`
+ Assicurati che la `TargetGroup` porta corrisponda alla porta listener definita dal nodo virtuale.
+ Per gli Application Load Balancer che originano connessioni TLS tramite HTTP al tuo servizio, assicurati che il `TargetGroup` protocollo sia impostato su. `HTTPS` Se vengono utilizzati i controlli sanitari, assicurati che sia impostato su. `HealthCheckProtocol` `HTTPS`
+ Per i Network Load Balancer che originano connessioni TLS tramite TCP al tuo servizio, assicurati che il protocollo sia impostato su. `TargetGroup` `TLS` Se vengono utilizzati controlli sanitari, assicurati che sia impostato su. `HealthCheckProtocol` `TCP`
**Nota**
Eventuali aggiornamenti che `TargetGroup` richiedono la modifica del `TargetGroup` nome.
Se configurato correttamente, il sistema di bilanciamento del carico dovrebbe fornire una connessione sicura al servizio utilizzando il certificato fornito al proxy Envoy.
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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) Se ritieni di aver trovato una vulnerabilità di sicurezza o hai domande sulla sicurezza di App Mesh, consulta le linee guida per la [segnalazione delle AWS vulnerabilità](https://aws.amazon.com/security/vulnerability-reporting/).
# Risoluzione dei problemi di App Mesh Kubernetes
**Importante**
Avviso di fine del supporto: il 30 settembre 2026, AWS verrà interrotto il supporto per. AWS App Mesh Dopo il 30 settembre 2026, non potrai più accedere alla AWS App Mesh console o alle risorse. AWS App Mesh Per ulteriori informazioni, consulta questo post di blog [Migrazione AWS App Mesh da Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Questo argomento descrive i problemi più comuni che potresti riscontrare quando utilizzi App Mesh con Kubernetes.
## Le risorse App Mesh create in Kubernetes non possono essere trovate in App Mesh
**Caratteristiche**
Hai creato le risorse App Mesh utilizzando la definizione delle risorse personalizzate (CRD) di Kubernetes, ma le risorse che hai creato non sono visibili in App Mesh quando usi o. Console di gestione AWS APIs
**Risoluzione**
La causa probabile è un errore nel controller Kubernetes per App Mesh. [Per ulteriori informazioni, consulta Risoluzione dei problemi su.](https://github.com/aws/aws-app-mesh-controller-for-k8s/blob/master/docs/guide/troubleshooting.md) GitHub Controlla i log del controller per eventuali errori o avvisi che indicano che il controller non è riuscito a creare alcuna risorsa.
```
kubectl logs -n appmesh-system -f \
$(kubectl get pods -n appmesh-system -o name | grep controller)
```
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## Dopo l'iniezione del sidecar Envoy, i pod non sono stati sottoposti ai controlli di prontezza e vivacità
**Caratteristiche**
I pod della tua applicazione funzionavano correttamente in precedenza, ma dopo l'iniezione del sidecar Envoy in un pod, i controlli di prontezza e vivacità iniziano a fallire.
**Risoluzione**
Assicurati che il contenitore Envoy che è stato iniettato nel pod sia stato avviato con il servizio di gestione Envoy di App Mesh. Puoi verificare eventuali errori facendo riferimento ai codici di errore in. [Envoy disconnesso dal servizio di gestione App Mesh Envoy con testo di errore](troubleshooting-setup.md#ts-setup-grpc-error-codes) È possibile utilizzare il seguente comando per ispezionare i log di Envoy per il relativo pod.
```
kubectl logs -n appmesh-system -f \
$(kubectl get pods -n appmesh-system -o name | grep controller) \
| grep "gRPC config stream closed"
```
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## I pod non vengono registrati o annullati come istanze AWS Cloud Map
**Caratteristiche**
I tuoi pod Kubernetes non vengono registrati o cancellati durante il loro ciclo di vita. AWS Cloud Map Un pod può avviarsi correttamente ed essere pronto a servire il traffico, ma non a riceverne. Quando un pod viene terminato, i client possono comunque conservare il relativo indirizzo IP e tentare di inviargli traffico, ma senza successo.
**Risoluzione**
Si tratta di un problema noto. Per ulteriori informazioni, consulta la sezione [Pods don't get auto registered/deregistered in Kubernetes](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/159) with issue. AWS Cloud Map GitHub A causa della relazione tra pod, nodi virtuali App Mesh e AWS Cloud Map risorse, il [controller App Mesh per Kubernetes](https://github.com/aws/aws-app-mesh-controller-for-k8s) potrebbe desincronizzarsi e perdere risorse. Ad esempio, ciò può accadere se una risorsa di nodo virtuale viene eliminata da Kubernetes prima di terminare i pod associati.
Per mitigare questo problema:
+ Assicurati di utilizzare la versione più recente del controller App Mesh per Kubernetes.
+ Assicurati che i AWS Cloud Map `namespaceName` e `serviceName` siano corretti nella definizione del nodo virtuale.
+ Assicurati di eliminare tutti i pod associati prima di eliminare la definizione del nodo virtuale. Se hai bisogno di aiuto per identificare quali pod sono associati a un nodo virtuale, consulta. [Impossibile determinare dove è in esecuzione un pod per una risorsa App Mesh](#ts-kubernetes-where-pod-running)
+ Se il problema persiste, esegui il comando seguente per controllare i log del controller alla ricerca di errori che potrebbero aiutare a scoprire il problema sottostante.
```
kubectl logs -n appmesh-system \
$(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)
```
+ Valuta la possibilità di utilizzare il seguente comando per riavviare i pod del controller. Questo può risolvere i problemi di sincronizzazione.
```
kubectl delete -n appmesh-system \
$(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)
```
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## Impossibile determinare dove è in esecuzione un pod per una risorsa App Mesh
**Caratteristiche**
Quando esegui App Mesh su un cluster Kubernetes, un operatore non può determinare dove è in esecuzione un carico di lavoro, o pod, per una determinata risorsa App Mesh.
**Risoluzione**
Le risorse del pod Kubernetes sono annotate con la mesh e il nodo virtuale a cui sono associate. Puoi interrogare quali pod sono in esecuzione per un determinato nome di nodo virtuale con il seguente comando.
```
kubectl get pods --all-namespaces -o json | \
jq '.items[] | { metadata } | select(.metadata.annotations."appmesh.k8s.aws/virtualNode" == "virtual-node-name")'
```
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## Impossibile determinare su quale risorsa App Mesh sia in esecuzione un pod
**Caratteristiche**
Quando si esegue App Mesh su un cluster Kubernetes, un operatore non può determinare su quale risorsa App Mesh è in esecuzione un determinato pod.
**Risoluzione**
Le risorse del pod Kubernetes sono annotate con la mesh e il nodo virtuale a cui sono associate. Puoi generare i nomi della mesh e dei nodi virtuali interrogando direttamente il pod utilizzando il seguente 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" }'
```
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## I Client Envoy non sono in grado di comunicare con App Mesh Envoy Management Service se sono disattivati IMDSv1
**Caratteristiche**
Quando `IMDSv1` è disabilitato, gli Envoy client non sono in grado di comunicare con il piano di controllo App Mesh (Envoy Management Service). `IMDSv2`il supporto non era disponibile nella versione precedente di App Mesh Envoy. `v1.24.0.0-prod`
**Risoluzione**
Per risolvere questo problema, puoi fare una di queste tre cose.
+ Esegui l'aggiornamento alla versione App Mesh Envoy `v1.24.0.0-prod` o successiva, che `IMDSv2` supporta.
+ Riattiva `IMDSv1` sull'istanza in cui è in esecuzione Envoy. Per istruzioni sul ripristino`IMDSv1`, consulta [Configurare le opzioni dei metadati dell'](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html)istanza.
+ Se i tuoi servizi sono in esecuzione su Amazon EKS, ti consigliamo di utilizzare i ruoli IAM per gli account di servizio (IRSA) per recuperare le credenziali. Per istruzioni su come abilitare IRSA, consulta i [ruoli IAM](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) per gli account di servizio.
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)
## IRSA non funziona sul contenitore dell'applicazione quando App Mesh è abilitato e Envoy viene iniettato
**Caratteristiche**
Quando App Mesh è abilitato su un cluster Amazon EKS con l'aiuto del controller App Mesh per Amazon EKS, Envoy e `proxyinit` i contenitori vengono iniettati nel pod dell'applicazione. L'applicazione non è in grado di assumere `IRSA` e invece presuppone il. `node role` Quando descriviamo i dettagli del pod, vediamo che la variabile di `AWS_ROLE_ARN` ambiente `AWS_WEB_IDENTITY_TOKEN_FILE` o la variabile di ambiente non sono incluse nel contenitore dell'applicazione.
**Risoluzione**
Se una delle due `AWS_WEB_IDENTITY_TOKEN_FILE` variabili di `AWS_ROLE_ARN` ambiente è definita, il webhook salterà il pod. Non fornite nessuna di queste variabili e il webhook si occuperà di iniettarle per voi.
```
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
}
```
[Se il problema persiste, valuta la possibilità di aprirne uno GitHub o di contattare l'[AWS assistenza](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)