Risolvere i problemi di distribuzione del traffico non uniforme

Questo documento mostra come risolvere i problemi relativi alla distribuzione non uniforme del traffico ai servizi Kubernetes.

Identificare i sintomi di una distribuzione non uniforme del traffico

La distribuzione non uniforme del traffico, spesso definita hotspot, si verifica quando un sottoinsieme di pod o nodi gestisce una quantità sproporzionata del carico di lavoro totale, mentre altri rimangono sottoutilizzati.

I sintomi comuni includono:

• Colli di bottiglia delle prestazioni: gli utenti potrebbero riscontrare timeout intermittenti, errori HTTP 5xx o perdita di pacchetti sulle connessioni di rete sovrautilizzate.
• Esaurimento delle risorse: pod o nodi specifici mostrano un utilizzo della CPU o della memoria significativamente più elevato rispetto al resto della flotta.
• Pattern di squilibrio del traffico:
  • Squilibrio per pod: il traffico raggiunge solo un piccolo sottoinsieme di pod disponibili, anche se tutti i pod sono segnalati come integri e pronti.
  • Squilibrio per nodo: uno o più nodi ricevono un numero di pacchetti o richieste significativamente maggiore rispetto ad altri, spesso quando si utilizza externalTrafficPolicy: Local con un posizionamento dei pod non uniforme.
  • Sessioni client permanenti: tutte le richieste di un singolo client ad alto volume vengono costantemente indirizzate allo stesso pod di backend.

Diagnosi con Cloud Monitoring

Per confermare questi sintomi, visualizza i pattern di traffico utilizzando le seguenti metriche:

• Per il livello 7 (Ingress/Gateway): traccia loadbalancing.googleapis.com/backend/request_count e raggruppa per backend_target per confrontare i volumi di richieste tra diversi backend.

Comprendere le cause comuni della distribuzione non uniforme del traffico

Questa sezione descrive le cause comuni della distribuzione non uniforme del traffico ai servizi Kubernetes. Questo squilibrio può causare colli di bottiglia delle prestazioni, esaurimento delle risorse su determinati pod e riduzione della disponibilità delle applicazioni, con alcuni pod che ricevono un traffico significativamente maggiore rispetto ad altri, mentre alcuni ne ricevono pochissimo o nessuno.

L'affinità sessione causa una distribuzione non uniforme

Il seguente problema si verifica quando i bilanciatori del carico con l'affinità sessione abilitata indirizzano costantemente le richieste dello stesso client allo stesso pod di backend. Se un client specifico genera un volume elevato di traffico, il pod diventa sovraccarico, creando un hotspot in cui riceve un carico significativamente maggiore rispetto ad altri, mentre altri pod rimangono sottoutilizzati.

Puoi configurare l'affinità sessione negli oggetti del servizio Kubernetes utilizzando il campo sessionAffinity.

Quando sessionAffinity è impostato su ClientIP, il servizio si assicura che tutte le connessioni provenienti dallo stesso indirizzo IP client vengano indirizzate costantemente allo stesso pod di backend. In questo modo si ottiene una vera affinità sessione basata sull'IP client.

Quando sessionAffinity è impostato su None (il comportamento predefinito), i bilanciatori del carico di livello 4 in genere distribuiscono le connessioni utilizzando un hash di vari parametri di rete, ad esempio una quadrupla (indirizzo IP client, indirizzo IP di destinazione, porta di destinazione, protocollo) o una quintupla (inclusa la porta di origine). Sebbene questo hashing possa fornire una certa "permanenza" della connessione indirizzando costantemente le connessioni con valori di tuple identici allo stesso backend, non garantisce che tutte le connessioni da un indirizzo IP client specifico vadano sempre allo stesso pod se altri elementi della tupla cambiano.

Per saperne di più, consulta Affinità sessione.

Per GKE Gateway, il CRD GCPTrafficDistributionPolicy configura l'affinità sessione. Per saperne di più, consulta Configurare le risorse Gateway utilizzando i criteri.

Per i bilanciatori del carico di rete passthrough esterni regionali, puoi utilizzare l'affinità sessione per mantenere la permanenza della connessione a un backend specifico. Tuttavia, tieni presente che l'affinità sessione può causare una distribuzione non uniforme se alcuni client generano più traffico di altri.

Per saperne di più, consulta Affinità sessione e Panoramica del bilanciatore del carico di rete passthrough esterno basato sui servizi di backend.

L'esempio seguente mostra un manifest del servizio con sessionAffinity: ClientIP:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  sessionAffinity: ClientIP  # This can cause uneven distribution
  ports:
  -   port: 80
    targetPort: 8080
  selector:
    app: my-app

Il pool di connessioni causa una distribuzione non uniforme

Il pool di connessioni si verifica quando i bilanciatori del carico riutilizzano le connessioni esistenti a pod specifici, anche se altri pod hanno capacità disponibile. Questo comportamento può causare uno squilibrio se alcune connessioni sono più durature o gestiscono un numero di richieste significativamente maggiore rispetto ad altre. Ciò concentra il traffico su determinati pod, in modo simile all'affinità sessione, creando hotspot in cui questi pod diventano sovraccarichi mentre altri rimangono sottoutilizzati.

I bilanciatori del carico implementano il pool di connessioni per migliorare le prestazioni riducendo l'overhead della creazione di nuove connessioni. Tuttavia, se non gestito correttamente, il pool di connessioni può causare una distribuzione non uniforme del traffico, soprattutto con le applicazioni che mantengono connessioni di lunga durata.

Per mitigare la distribuzione non uniforme causata dal pool di connessioni, implementa strategie a livello di applicazione o client:

• Configura i client in modo che utilizzino più connessioni: anziché fare affidamento su una singola connessione di lunga durata, configura i client in modo che aprano e gestiscano un pool di più connessioni al bilanciatore del carico. In questo modo, il bilanciatore del carico può distribuire i nuovi tentativi di connessione tra i pod di backend disponibili, migliorando la distribuzione complessiva del traffico.

• Chiudi e riapri periodicamente le connessioni: per le applicazioni che mantengono naturalmente connessioni di lunga durata, configurale o configura i relativi client in modo che chiudano e riaprano periodicamente le connessioni. Sebbene ciò comporti un leggero overhead di ristabilimento della connessione, il bilanciatore del carico ha nuove opportunità di distribuire i tentativi di connessione successivi a pod di backend diversi e meno utilizzati. Questo approccio è particolarmente efficace per i servizi in cui la terminazione e il ristabilimento della connessione non sono eccessivamente dirompenti.

• Implementa uno svuotamento aggressivo della connessione: assicurati che i pod siano configurati per l'arresto normale e lo svuotamento della connessione. Quando un pod viene terminato normalmente (ad esempio, durante un deployment o uno scale down), il bilanciatore del carico deve interrompere l'invio di nuove connessioni e consentire il completamento o lo svuotamento delle connessioni esistenti. In questo modo, il traffico può passare ad altri pod in modo più fluido e si evita che si concentri sui pod in fase di terminazione.

Gestendo attivamente il comportamento della connessione, puoi aiutare i bilanciatori del carico a distribuire il traffico in modo più uniforme, anche con connessioni di lunga durata.

L'hashing a 5 tuple causa una distribuzione non uniforme

Questo è il comportamento predefinito per molti bilanciatori del carico di livello 4 quando non configuri esplicitamente l'affinità sessione. Se molte connessioni provengono dallo stesso client o utilizzano le stesse combinazioni di porte, si verifica una distribuzione non uniforme.

Per risolvere gli squilibri causati dall'hashing, valuta quanto segue:

• Utilizza il bilanciamento del carico di livello 7: GKE Ingress e Gateway operano a livello di richiesta, consentendo loro di distribuire le richieste di un singolo client su più pod di backend.

• Modifica il comportamento del client: configura i client in modo che utilizzino più connessioni o un pool più ampio di porte di origine.

La distribuzione non uniforme dei pod tra i nodi causa una distribuzione non uniforme

Questo problema si verifica quando i pod non sono distribuiti in modo uniforme tra i nodi e il bilanciatore del carico non utilizza il bilanciamento del carico nativo del container. I nodi con più pod ricevono più traffico, il che può portare al sovraccarico di alcuni nodi mentre altri sono sottoutilizzati.

Questo problema è particolarmente rilevante quando utilizzi externalTrafficPolicy: Local.

Le impostazioni dei criteri del traffico esterno causano una distribuzione non uniforme

L'impostazione externalTrafficPolicy del servizio influisce sul modo in cui viene instradato il traffico.

• Cluster: consente al bilanciatore del carico di distribuire il traffico a qualsiasi nodo in del cluster. Utilizza l'impostazione Cluster per la distribuzione più uniforme su tutti i nodi e i pod disponibili.
• Locale: instrada il traffico solo ai pod in esecuzione sullo stesso nodo che ha ricevuto il traffico. Se non distribuisci i pod in modo uniforme tra i nodi, questa impostazione può causare una distribuzione non uniforme.

L'affinità nodo causa una distribuzione non uniforme

L'utilizzo dell'affinità nodo per limitare i pod a un sottoinsieme di nodi può causare il sovraccarico di questi nodi, soprattutto se il carico di lavoro non è ben bilanciato tra loro.

Assicurati che i pod non siano associati a nodi specifici.