Durante il normale funzionamento degli applicativi, un cliente segnala degli errori randomici di socket timeout e un aumento dei tempi di risposta in maniera apparentemente casuale tra un applicativo on-premises e un secondo applicativo ospitato su Amazon EKS. Entrambe le componenti lavorano all'interno dello stesso contesto applicativo, con il compito di generare un messaggio contenente notifiche e metadati da inviare a un endpoint di dispatcher, e ricevere e consumare i messaggi ricevuti per inoltrare notifiche verso endpoint aziendali o altri client. In questo sintetico case study raccontiamo come siamo venuti a capo del problema.

Il Contesto. L'infrastruttura

L'infrastruttura del cliente si basa su Amazon EKS, ed è distribuita su più Availability Zones per garantire alta disponibilità. Gli ingress controller sono deployati come DaemonSet su ogni nodo worker, mentre i microservizi di backend sono distribuiti dinamicamente sui vari worker node. Il traffico in ingresso transita attraverso vari componenti: Direct Connect, Transit Gateway, Network Load Balancer (NLB) AWS, e infine l'Ingress Controller di EKS.
Il tutto è protetto da firewall on-premises e da Security Group e Firewall AWS. La gestione dei DNS è condivisa tra l'infrastruttura on-premises e alcuni record esistenti configurati su AWS.

 

Il Problema: il socket timeout

Analizzando il problema, constatiamo che l'applicativo A (client) che effettua richieste verso il servizio B (server) riscontra frequenti socket timeout e tempi di risposta elevati, impedendo il completamento delle connessioni TCP. Gli errori si verificano in modo apparentemente casuale, senza tuttavia compromettere il funzionamento generale grazie a meccanismi di retry previsti nell’applicativo. I primi sospetti si concentrano sulla connettività di rete e sulla risoluzione DNS, estendendo progressivamente l'analisi a tutte le componenti AWS e Kubernetes coinvolte.

Gli Obiettivi

L'obiettivo a questo punto è identificare con precisione la causa dei socket timeout e ristabilire la stabilità delle connessioni TCP per gli applicativi esterni al cluster EKS.

La Soluzione

Il troubleshooting si è, dunque, articolato nelle seguenti fasi.

1. Analisi DNS: sono stati analizzati i record CNAME e i relativi TTL. Sono stati effettuati test diretti verso il DNS del bilanciatore AWS, senza evidenziare anomalie.
2. Verifica di Firewall AWS e on-premises: sono state verificate le policy di rete e il traffico filtrato da firewall on-premises e AWS, senza riscontrare blocchi o perdite anomale.
3. Verifica del Network Load Balancer: sono state escluse anomalie di bilanciamento tra Availability Zone e perdite di pacchetti a livello NLB. È stato verificato che il cross-zone load balancing fosse disabilitato e, nonostante l’impiego di nodi spot, è stato confermato che la copertura delle Availability Zone è sempre stata garantita, anche durante la terminazione delle istanze spot.
4. Debug di rete su EKS: a seguito dell'esclusione di cause esterne, l'attenzione si è spostata all'interno del cluster EKS. Utilizzando tcpdump sui worker node, abbiamo osservato che, sebbene il traffico TCP in ingresso arrivasse correttamente, in alcuni casi la risposta SYN-ACK non veniva restituita, interrompendo il corretto handshake TCP.

Per rendere l'analisi più mirata, sono stati effettuati test forzando la risoluzione DNS verso endpoint NLB di una specifica Availability Zone.

A quel punto si sono osservate chiaramente:

• alcune richieste ricevevano correttamente il SYN-ACK;
• altre richieste, invece, fallivano poiché il SYN-ACK veniva generato da nodi diversi rispetto a quello che aveva ricevuto la richiesta, rompendo la simmetria TCP.

Questa anomalia è stata ricondotta alla configurazione del service dell’ingress controller impostato con externalTrafficPolicy: Cluster. Questa modalità ottimizza la distribuzione del carico tra i pod, ma altera la gestione dell’IP sorgente e può causare problemi su connessioni TCP end-to-end, specialmente su traffico esterno.

Soluzione Applicata

Una volta ottenuta l’evidenza chiara del problema, si è provveduto a modificare la configurazione dell’ingress controller impostando externalTrafficPolicy: Local. Questa modifica ha permesso di ottenere diversi vantaggi:

• il traffico in entrata viene gestito direttamente dal pod locale presente sul nodo che riceve la connessione, evitando inoltri interni tra i nodi e mantenendo il traffico confinato localmente.
• Si garantisce la piena simmetria del traffico TCP, assicurando la corretta esecuzione dell'handshake (SYN, SYN-ACK, ACK) senza rischi di perdita o alterazione dei pacchetti.
• Viene preservato l'indirizzo IP sorgente del client, requisito fondamentale per attività di audit, tracciamento, sicurezza e analisi dei log.
   

I Risultati

Con l'applicazione della modifica:

• i socket timeout sono scomparsi;
• la comunicazione tra le componenti dell'anagrafe regionale è tornata stabile e affidabile;
• nessun impatto negativo è stato registrato sulle altre applicazioni del cluster;
• i test successivi, validati anche tramite tcpdump, hanno confermato la corretta gestione dei pacchetti TCP (SYN, SYN-ACK, ACK).

Le Raccomandazioni Conclusive

Questo caso evidenzia alcune lezioni importanti da cui possiamo ricavare delle raccomandazioni.

1. Configurare con attenzione l'architettura di rete e i parametri di Kubernetes

È fondamentale valutare l’impatto delle scelte di configurazione come externalTrafficPolicy sugli ingress controller. L’impostazione su Local, pur preservando l’IP sorgente e garantendo la simmetria TCP, richiede che il traffico arrivi su nodi che abbiano effettivamente un pod disponibile. Se l’ingress non fosse stato deployato in modalità DaemonSet, questa scelta avrebbe potuto causare timeout o errori HTTP 503 in caso di assenza di pod sui nodi. Questo tipo di configurazione si dimostra efficace nel nostro contesto, in quanto non evidenzia problemi di sbilanciamento del traffico, grazie alla presenza di un singolo pod NGINX per nodo. È NGINX stesso a farsi carico del bilanciamento delle richieste verso i pod applicativi, garantendo una distribuzione coerente del carico all’interno del cluster.  Inoltre, è stato necessario analizzare con attenzione le subnet dei nodi EKS e dei servizi chiamanti per prevenire overlap IP che avrebbero potuto generare problemi di routing o instabilità delle connessioni.

2. Adottare un approccio strutturato e sistematico nel troubleshooting

L'abilità di isolare progressivamente il problema, eliminando via via le possibili cause, si è rivelata essenziale per individuare la radice del malfunzionamento. Questo aspetto dimostra quanto sia importante affidarsi ad un buon partner tecnologico.

Queste competenze, unite a un metodo di lavoro strutturato, sono ciò che rende Miriade un alleato competente e strategico per affrontare anche le sfide più complesse: affidabile, attento e sempre orientato a costruire soluzioni stabili, scalabili e pensate su misura per gli obiettivi dei clienti.