Risolvere i problemi di distribuzione del traffico non uniforme

Autopilot Standard

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

Identificare i sintomi di una distribuzione del traffico non uniforme

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

I sintomi più comuni includono:

• Colli di bottiglia delle prestazioni: gli utenti potrebbero riscontrare timeout intermittenti, errori HTTP 5xx o perdita di pacchetti su connessioni di rete sovrautilizzate.
• Esaurimento delle risorse: pod o nodi specifici mostrano un utilizzo di CPU o memoria significativamente superiore rispetto al resto del parco macchine.
• Pattern di squilibrio del traffico:
  • Squilibrio per pod: il traffico raggiunge solo un piccolo sottoinsieme di pod disponibili, anche se tutti i pod vengono segnalati come integri e pronti.
  • Sbilanciamento per nodo: uno o più nodi ricevono molti più pacchetti o richieste 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 indirizzate in modo coerente 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 più 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 nelle prestazioni, esaurimento delle risorse su determinati pod e una ridotta disponibilità delle applicazioni, con alcuni pod che ricevono molto più traffico di altri, mentre altri ne ricevono pochissimo o nessuno.

L'affinità di sessione causa una distribuzione non uniforme

Il seguente problema si verifica quando i bilanciatori del carico con l'affinità sessione abilitata instradano costantemente le richieste dello stesso client allo stesso pod di backend. Se un client specifico genera un volume elevato di traffico, il pod viene 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 Service di 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 instradate in modo coerente allo stesso pod di backend. In questo modo, viene fornita l'affinità sessione basata sull'IP client reale.

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

Per saperne di più, consulta Affinità di sessione.

Per gateway GKE, la CRD GCPTrafficDistributionPolicy configura l'affinità sessione. Per saperne di più, consulta Configura le risorse Gateway utilizzando le policy.

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

Per saperne di più, consulta Affinità di 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 pooling delle 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 di lunga durata o gestiscono un numero di richieste significativamente maggiore rispetto ad altre. In questo modo, il traffico si concentra su determinati pod, in modo simile all'affinità sessione, creando hotspot in cui questi pod diventano sovraccarichi, mentre altri pod 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 viene gestito correttamente, il pool di connessioni può causare una distribuzione del traffico non uniforme, soprattutto con applicazioni che mantengono connessioni di lunga durata.

Per mitigare la distribuzione non uniforme causata dal pooling delle 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, configura le applicazioni o i relativi client in modo che chiudano e riaprano periodicamente le connessioni. Sebbene ciò comporti un leggero sovraccarico di ristabilimento della connessione, offre al bilanciatore del carico nuove opportunità per 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 interrotti.

• Implementa lo 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 una riduzione delle dimensioni), 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ò spostarsi su altri pod in modo più fluido e si evita che si concentri sui pod 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 di molti bilanciatori del carico di livello 4 quando non configuri esplicitamente l&#39affinità sessionee. Se molte connessioni provengono dallo stesso client o utilizzano le stesse combinazioni di porte, la distribuzione non è uniforme.

Per risolvere gli squilibri causati dall'hashing, considera 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 tra più pod di backend.

• Regola 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 a un sovraccarico di alcuni nodi mentre altri sono sottoutilizzati.

Questo problema è particolarmente rilevante quando utilizzi externalTrafficPolicy: Local.

Le impostazioni della policy 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 del cluster. Utilizza l'impostazione Cluster per la distribuzione più uniforme in tutti i nodi e i pod disponibili.
• Locale: indirizza il traffico solo ai pod in esecuzione sullo stesso nodo che ha ricevuto il traffico. Ciò può portare a una distribuzione non uniforme se non distribuisci i pod in modo uniforme tra i nodi.

L'affinità dei nodi causa una distribuzione non uniforme

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

Assicurati che i pod non siano bloccati su nodi specifici.