Risoluzione dei problemi di scalabilità di App Mesh - AWS App Mesh

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 scalabilità di App Mesh

Questo argomento descrive i problemi più comuni che potresti riscontrare con il ridimensionamento di App Mesh.

La connettività fallisce e i controlli sullo stato dei container falliscono quando si scalano oltre 50 repliche per un nodo virtuale/gateway virtuale

Sintomi

Quando si ridimensiona il numero di repliche, come task Amazon ECS, pod Kubernetes o istanze Amazon EC2, per un nodo virtuale/gateway virtuale oltre 50, i controlli di salute dei container Envoy per Envoys nuovi e attualmente in esecuzione iniziano a fallire. Le applicazioni downstream che inviano traffico al nodo virtuale/gateway virtuale iniziano a vedere gli errori di richiesta con il codice di stato HTTP503.

Risoluzione

La quota predefinita di App Mesh per il numero di inviati per nodo virtuale/gateway virtuale è 50. Quando il numero di Envoy in esecuzione supera questa quota, gli Envoys nuovi e attualmente in esecuzione non riescono a connettersi al servizio di gestione Envoy di App Mesh con il codice di stato gRPC8(RESOURCE_EXHAUSTED). Questa quota può essere aumentata. Per ulteriori informazioni, consulta la pagina Service App Mesh .

Se il problema non è ancora stato risolto, prendi in considerazione l'apertura di unGitHub problemaContattaciAWSSupport.

Le richieste falliscono con503quando il backend di un servizio virtuale è scalabile orizzontalmente o in entrata

Sintomi

Quando un servizio virtuale di backend viene ridimensionato o inserito orizzontalmente, le richieste provenienti dalle applicazioni downstream falliscono con unHTTP 503codice di stato.

Risoluzione

App Mesh consiglia diversi approcci per mitigare i casi di errore ridimensionando al contempo le applicazioni orizzontalmente. Per informazioni dettagliate su come prevenire questi errori, consultaBest practice per App Mesh.

Se il problema non è ancora stato risolto, prendi in considerazione l'apertura di unGitHub problemaContattaciAWSSupport.

Il contenitore Envoy si blocca con segfault sotto carico aumentato

Sintomi

Con un carico di traffico elevato, il proxy Envoy si blocca a causa di un errore di segmentazione (codice di uscita Linux)139). I log del processo 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 aperti da un processo alla volta. Questa violazione è dovuta al traffico che causa più connessioni, che consumano socket aggiuntivi del sistema operativo. Per risolvere il problema, aumentare il valore ulimit nofile nel sistema operativo host. Se utilizzi Amazon ECS, questo limite può essere modificato tramite ilImpostazioni Ulimitsulla definizione dell'attivitàimpostazioni dei limiti delle risorse.

Se il problema non è ancora stato risolto, prendi in considerazione l'apertura di unGitHub problemaContattaciAWSSupport.

L'aumento delle risorse predefinite non si riflette nei limiti di servizio

Sintomi

Dopo aver aumentato il limite predefinito delle risorse di App Mesh, il nuovo valore non viene visualizzato quando si esaminano i limiti del servizio.

Risoluzione

Sebbene i nuovi limiti non siano attualmente visualizzati, i clienti possono comunque esercitarli.

Se il problema non è ancora stato risolto, prendi in considerazione l'apertura di unGitHub problemaContattaciAWSSupport.

L'applicazione si blocca a causa di un numero enorme di chiamate di controllo sanitario.

Sintomi

Dopo aver abilitato i controlli di integrità attivi per un nodo virtuale, si verifica un aumento del numero di chiamate di controllo dello stato. L'applicazione si blocca a causa del notevole aumento del volume di chiamate di controllo sanitario effettuate all'applicazione.

Risoluzione

Quando il controllo dello stato attivo è 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 sanitario sarebbenumber of client Envoys*number of server Envoys*active health check frequency.

Per risolvere questo problema, modificate la frequenza della sonda di controllo dello stato, in modo da ridurre il volume totale delle sonde di controllo dello stato. Oltre ai controlli di salute attivi, App Mesh consente la configurazionerilevamento di outliercome mezzo di controllo sanitario passivo. Usa il rilevamento dei valori anomali per configurare quando rimuovere un determinato host in base a una sequenza5xxRisposta.

Se il problema non è ancora stato risolto, prendi in considerazione l'apertura di unGitHub problemaContattaciAWSSupport.