Informazioni sui servizi LoadBalancer

Questa pagina fornisce una panoramica generale di come Google Kubernetes Engine (GKE) crea e gestisce i bilanciatori del carico quando applichi un manifest dei servizi LoadBalancer di Kubernetes. Trusted Cloud by S3NS Descrive i tipi di LoadBalancer, i parametri di configurazione e fornisce consigli sulle best practice.

Prima di leggere questa pagina, assicurati di avere familiarità con i concetti di networking di GKE.

Panoramica

Quando crei un servizio LoadBalancer, GKE configura un Trusted Cloud bilanciatore del carico pass-through le cui caratteristiche dipendono dai parametri del manifest del servizio.

Personalizzare il servizio LoadBalancer

Quando scegli la configurazione del servizio LoadBalancer da utilizzare, considera i seguenti aspetti:

• Tipo di bilanciatore del carico: interno o esterno
• Policy del traffico esterno
• Bilanciamento del carico ponderato
• Affinità a livello di zona

Tipo di bilanciatore del carico: interno o esterno

Quando crei un servizio LoadBalancer in GKE, specifichi se il bilanciatore del carico ha un indirizzo interno o esterno:

• I servizi LoadBalancer esterni vengono implementati utilizzando i bilanciatori del carico di rete passthrough esterni. I client che si trovano al di fuori della tua rete VPC e le VM con accesso a internet possono accedere a un servizio LoadBalancer esterno. Trusted Cloud

  Quando crei un servizio LoadBalancer e non specifichi impostazioni personalizzate, viene utilizzata questa configurazione per impostazione predefinita.

  Come best practice, quando crei un servizio LoadBalancer esterno, includi l'annotazione cloud.google.com/l4-rbs: "enabled" nel manifest del servizio. L'inclusione di questa annotazione nel manifest del servizio crea un bilanciatore del carico di rete passthrough esterno basato sui servizi di backend.

  I manifest del servizio LoadBalancer che omettono l'annotazione cloud.google.com/l4-rbs: "enabled" creano un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione. L'utilizzo dei bilanciatori del carico di rete passthrough esterni basati su pool target non è più consigliato.

• I servizi LoadBalancer interni vengono implementati utilizzando i bilanciatori del carico di rete passthrough interni. I client che si trovano nella stessa rete VPC o in una rete connessa alla rete VPC del cluster possono accedere a un servizio di bilanciatore del carico interno.

  Per creare un servizio LoadBalancer interno:

  • Come best practice, assicurati che il sottoinsieme GKE sia abilitato in modo che GKE possa raggruppare in modo efficiente i nodi utilizzando i gruppi di endpoint di rete (NEG) GCE_VM_IP. Il sottoinsieme GKE non è obbligatorio, ma è fortemente consigliato.

  • Includi l'annotazione networking.gke.io/load-balancer-type: "Internal" nel manifest del servizio.

Effetto di externalTrafficPolicy

Il parametro externalTrafficPolicy controlla quanto segue:

• Quali nodi ricevono i pacchetti dal bilanciatore del carico
• Se i pacchetti possono essere instradati tra i nodi del cluster dopo che il bilanciatore del carico li ha inviati a un nodo
• Se l'indirizzo IP client originale viene conservato o perso

externalTrafficPolicy può essere Local o Cluster:

• Utilizza externalTrafficPolicy: Local per assicurarti che i pacchetti vengano recapitati solo a un nodo con almeno un pod di pubblicazione pronto e non terminato, preservando l'indirizzo IP di origine del client originale. Questa opzione è ideale per i carichi di lavoro con un numero relativamente costante di nodi con pod di servizio, anche se il numero complessivo di nodi nel cluster varia. Questa opzione è necessaria per supportare il bilanciamento del carico ponderato.

• Utilizza externalTrafficPolicy: Cluster nelle situazioni in cui il numero complessivo di nodi nel cluster è relativamente costante, ma il numero di nodi con pod di servizio varia. Questa opzione non conserva gli indirizzi IP di origine del client originali e può aggiungere latenza perché i pacchetti potrebbero essere indirizzati a un pod di servizio su un altro nodo dopo essere stati inviati a un nodo dal bilanciatore del carico. Questa opzione non è compatibile con il bilanciamento del carico ponderato.

Per ulteriori informazioni su come externalTrafficPolicy influisce sul routing dei pacchetti all'interno dei nodi, consulta Elaborazione dei pacchetti.

Bilanciamento del carico ponderato

I servizi LoadBalancer esterni supportano il bilanciamento del carico ponderato, che consente ai nodi con più pod di servizio pronti e non terminati di ricevere una percentuale maggiore di nuove connessioni rispetto ai nodi con meno pod. Per ulteriori informazioni su come cambiano le configurazioni del bilanciatore del carico con il bilanciamento del carico ponderato, consulta Effetto del bilanciamento del carico ponderato.

Come illustrato nel diagramma, i servizi con bilanciamento del carico ponderato abilitato distribuiscono le nuove connessioni in proporzione al numero di pod pronti su ogni nodo, garantendo che i nodi con più pod ricevano una quota maggiore di nuove connessioni.

Per utilizzare il bilanciamento del carico ponderato, devi soddisfare tutti i seguenti requisiti:

• Il cluster GKE deve utilizzare la versione 1.31.0-gke.1506000 o successive.

• Il componente aggiuntivo HttpLoadBalancing deve essere attivato per il cluster. Questo componente aggiuntivo è attivato per impostazione predefinita. Consente al cluster di gestire i bilanciatori del carico che utilizzano i servizi di backend.

• Devi includere l'annotazione cloud.google.com/l4-rbs: "enabled" nel manifest del servizio LoadBalancer in modo che GKE crei un bilanciatore del carico di rete passthrough esterno basato sul servizio di backend. I bilanciatori del carico di rete passthrough esterni basati su pool di destinazione non supportano il bilanciamento del carico ponderato.

• Per abilitare la funzionalità di bilanciamento del carico ponderato, devi includere l'annotazione networking.gke.io/weighted-load-balancing: pods-per-node nel manifest del servizio LoadBalancer.

• Il manifest del servizio LoadBalancer deve utilizzare externalTrafficPolicy: Local. GKE non ti impedisce di utilizzare externalTrafficPolicy: Cluster, ma externalTrafficPolicy: Cluster disattiva efficacemente il bilanciamento del carico ponderato perché il pacchetto potrebbe essere instradato, dopo il bilanciatore del carico, a un nodo diverso.

Per utilizzare il bilanciamento del carico ponderato, vedi Abilitare il bilanciamento del carico ponderato.

Affinità a livello di zona

I servizi LoadBalancer interni supportano l'affinità di zona (anteprima), che può instradare le nuove connessioni ai nodi con pod di servizio nella stessa zona di un client. Mantenere il traffico all'interno di una zona può ridurre al minimo il traffico tra zone, il che riduce i costi e la latenza.

Per utilizzare l'affinità zonale, consulta la sezione Utilizzo dell'affinità zonale. Per ulteriori informazioni su come cambiano le configurazioni del bilanciatore del carico con l'affinità di zona, incluso quando puoi mantenere il traffico all'interno di una zona, consulta Effetto dell'affinità di zona. Per ulteriori informazioni su come l'affinità di zona e externalTrafficPolicy influiscono sul routing dei pacchetti sulle VM nodo, consulta Source Network Address Translation e routing sui nodi.

Considerazioni speciali per i servizi LoadBalancer interni

Questa sezione descrive l'opzione di sottoinsieme GKE, univoca per i servizi LoadBalancer interni, e il modo in cui il sottoinsieme GKE interagisce con externalTrafficPolicy per influire sul numero massimo di nodi con bilanciamento del carico.

Impostazione secondaria GKE

Best practice:

Abilita l'impostazione secondaria di GKE per migliorare la scalabilità dei servizi LoadBalancer interni.

L'impostazione secondaria di GKE, chiamata anche impostazione secondaria di GKE per i bilanciatori del carico interni di livello 4, è un'opzione di configurazione a livello di cluster che migliora la scalabilità dei bilanciatori del carico di rete passthrough interni raggruppando in modo più efficiente gli endpoint dei nodi in gruppi di endpoint di rete (NEG) GCE_VM_IP. I NEG vengono utilizzati come backend del bilanciatore del carico.

Il seguente diagramma mostra due servizi in un cluster zonale con tre nodi. Il cluster ha l'impostazione secondaria di GKE abilitata. Ogni servizio ha due pod. GKE crea un NEG GCE_VM_IP per ogni servizio. Gli endpoint in ogni NEG sono i nodi con i pod di servizio per il servizio corrispondente.

Puoi abilitare l'impostazione secondaria di GKE quando crei un cluster o aggiornando un cluster esistente. Una volta abilitato, non puoi disattivare il sottoinsieme GKE. L'impostazione secondaria GKE richiede:

• GKE 1.18.19-gke.1400 o versioni successive e
• Il componente aggiuntivo HttpLoadBalancing è abilitato per il cluster. Questo componente aggiuntivo è attivato per impostazione predefinita. Consente al cluster di gestire i bilanciatori del carico che utilizzano servizi di backend.

Conteggio nodi

Un cluster con l'impostazione secondaria GKE disabilitata può riscontrare problemi con i servizi LoadBalancer interni se il cluster ha più di 250 nodi totali (tra tutti i pool di nodi). Ciò accade perché i bilanciatori del carico di rete passthrough interni creati da GKE possono distribuire pacchetti solo a un massimo di 250 VM nodo di backend. Questa limitazione esiste per i seguenti due motivi:

• GKE non utilizza il sottoinsieme del backend del bilanciatore del carico.
• Un bilanciatore del carico di rete passthrough interno è limitato alla distribuzione dei pacchetti a 250 o meno backend quando l'impostazione secondaria del backend del bilanciatore del carico è disattivata.

Un cluster con il sottoinsieme GKE supporta i servizi LoadBalancer interni nei cluster con più di 250 nodi totali.

• Un servizio LoadBalancer interno che utilizza externalTrafficPolicy: Local in un cluster in cui è abilitata l'impostazione secondaria GKE supporta fino a 250 nodi con pod di servizio che supportano questo servizio.

• Un servizio LoadBalancer interno che utilizza externalTrafficPolicy: Cluster in un cluster in cui è abilitata la suddivisione di GKE non impone alcuna limitazione al numero di nodi con pod di servizio, perché GKE configura non più di 25 endpoint nodo nei NEG GCE_VM_IP. Per saperne di più, consulta Appartenenza dei nodi ai backend NEG di GCE_VM_IP.

Distribuzione del traffico

Per impostazione predefinita, i servizi LoadBalancer interni ed esterni creano bilanciatori del carico di rete passthrough con l&#39affinità sessionee impostata su NONE. I bilanciatori del carico di rete passthrough utilizzano l'affinità di sessione, le informazioni sull'integrità e, in determinate circostanze, dettagli come il peso per identificare e selezionare un backend del nodo idoneo per una nuova connessione.

Le nuove connessioni creano voci nella tabella di monitoraggio delle connessioni, che vengono utilizzate per instradare rapidamente i pacchetti successivi per la connessione al backend del nodo idoneo selezionato in precedenza. Per saperne di più su come i bilanciatori del carico di rete pass-through identificano e selezionano i backend idonei e utilizzano il monitoraggio delle connessioni, consulta quanto segue:

• Distribuzione del traffico per i bilanciatori del carico di rete passthrough interni

• Distribuzione del traffico per i bilanciatori del carico di rete passthrough esterni

Effetto del bilanciamento del carico ponderato

Quando configuri il bilanciamento del carico ponderato per un servizio LoadBalancer esterno, GKE abilita il bilanciamento del carico ponderato sul bilanciatore del carico di rete passthrough esterno corrispondente. GKE configura il software kube-proxy o cilium-agent in modo da includere un'intestazione di risposta nella risposta al controllo di integrità del bilanciatore del carico. Questa intestazione della risposta definisce un peso proporzionale al numero di pod di pubblicazione, pronti e non terminati su ciascun nodo.

Il bilanciatore del carico utilizza le informazioni sul peso nel seguente modo:

• L'insieme di backend dei nodi idonei del bilanciatore del carico è costituito da tutti i nodi integri con peso diverso da zero.

• Il bilanciatore del carico tiene conto del peso quando seleziona uno dei backend dei nodi idonei. Quando il servizio utilizza externalTrafficPolicy: Local (obbligatorio per l'efficacia del bilanciamento del carico ponderato), è più probabile che venga selezionato un backend di nodi idoneo che dispone di più pod di pubblicazione, pronti e non terminanti rispetto a un backend di nodi idoneo con meno pod.

Effetto dell'affinità zonale

Quando configuri l'affinità di zona per un servizio Load Balancer interno, GKE configura il bilanciatore del carico di rete passthrough interno corrispondente con l'opzione ZONAL_AFFINITY_SPILL_CROSS_ZONE e un rapporto di overflow pari a zero.

Con questa configurazione di affinità di zona, il bilanciatore del carico restringe l'insieme originale di backend dei nodi idonei solo ai backend dei nodi idonei che si trovano nella stessa zona del client quando tutte le seguenti condizioni sono vere:

• Il client è compatibile con l'affinità a livello di zona.

• Almeno un backend del nodo idoneo e integro si trova nella zona del client.

In tutte le altre situazioni, il bilanciatore del carico continua a utilizzare il set originale di backend dei nodi idonei, senza applicare alcuna ottimizzazione dell'affinità di zona.

Per ulteriori dettagli su come la configurazione dell'affinità zonale influisce sul comportamento del bilanciatore del carico, consulta la documentazione sull'affinità zonale.

Raggruppamento dei nodi

La versione di GKE, le annotazioni del manifest del servizio e, per i servizi Internal LoadBalancer, l'opzione Sottoinsieme GKE determinano il bilanciatore del carico risultante e il tipo di backend. Trusted Cloud Il bilanciatore del carico e il tipo di backend determinano la modalità di raggruppamento dei nodi in NEG, gruppi di istanze o pool di destinazione.GCE_VM_IP In tutte le circostanze, Trusted Cloud i bilanciatori del carico pass-through identificano l'interfaccia di rete (NIC) del nodo GKE, non un particolare indirizzo IP di nodo o pod.

Servizio LoadBalancer GKE	Bilanciatore del carico Trusted Cloud risultante	Metodo di raggruppamento dei nodi
Servizio LoadBalancer interno creato in un cluster con l'impostazione secondaria GKE abilitata1	Un bilanciatore del carico di rete passthrough interno il cui servizio di backend utilizza i backend del gruppo di endpoint di rete (NEG) GCE_VM_IP	Le VM dei nodi sono raggruppate a livello di zona in NEG GCE_VM_IP in base al servizio secondo il externalTrafficPolicy del servizio e al numero di nodi nel cluster. externalTrafficPolicy del servizio controlla anche quali nodi superano il controllo di integrità del bilanciatore del carico e l'elaborazione dei pacchetti.
Servizio LoadBalancer interno creato in un cluster con l'impostazione secondaria di GKE disabilitata	Un bilanciatore del carico di rete passthrough interno il cui servizio di backend utilizza backend di gruppi di istanze non gestite zonali	Tutte le VM dei nodi vengono inserite in gruppi di istanze non gestite a livello di zona che GKE utilizza come backend per il servizio di backend del bilanciatore del carico di rete passthrough interno. externalTrafficPolicy dei controlli di servizio quali nodi superano il controllo di integrità del bilanciatore del carico e l'elaborazione dei pacchetti. Gli stessi gruppi di istanze non gestite vengono utilizzati per altri servizi di backend del bilanciatore del carico creati nel cluster a causa della limitazione di un singolo gruppo di istanze con bilanciamento del carico.
Servizio LoadBalancer esterno con l'annotazione cloud.google.com/l4-rbs: "enabled"2 applicata a un cluster che esegue GKE versione 1.32.2-gke.1652000 o successive4	Un bilanciatore del carico di rete passthrough esterno basato sui servizi di backend il cui servizio di backend utilizza backend di gruppi di endpoint di rete (NEG) GCE_VM_IP	Le VM dei nodi sono raggruppate a livello di zona in NEG GCE_VM_IP in base al servizio secondo il externalTrafficPolicy del servizio e al numero di nodi nel cluster. externalTrafficPolicy del servizio controlla anche quali nodi superano il controllo di integrità del bilanciatore del carico e l'elaborazione dei pacchetti.
Servizio LoadBalancer esterno con l'annotazione cloud.google.com/l4-rbs: "enabled"2 applicata a un cluster che esegue una versione di GKE precedente alla 1.32.2-gke.16520004	Un bilanciatore del carico di rete passthrough esterno basato sui servizi di backend il cui servizio di backend utilizza backend di gruppi di istanze non gestite a livello di zona	Tutte le VM dei nodi vengono inserite in gruppi di istanze non gestite a livello di zona che GKE utilizza come backend per il servizio di backend del bilanciatore del carico di rete passthrough esterno. externalTrafficPolicy dei controlli di servizio quali nodi superano il controllo di integrità del bilanciatore del carico e l'elaborazione dei pacchetti. Gli stessi gruppi di istanze non gestite vengono utilizzati per altri servizi di backend del bilanciatore del carico creati nel cluster a causa della limitazione di un singolo gruppo di istanze con bilanciamento del carico.
Servizio LoadBalancer esterno senza l'annotazione cloud.google.com/l4-rbs: "enabled"3	Un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione il cui pool di destinazione contiene tutti i nodi del cluster	Il pool di destinazione è un'API legacy che non si basa su gruppi di istanze. Tutti i nodi sono membri diretti del pool di destinazione. externalTrafficPolicy dei controlli di servizio quali nodi superano il controllo di integrità del bilanciatore del carico e l'elaborazione dei pacchetti.

Appartenenza dei nodi ai backend NEG GCE_VM_IP

Quando l'impostazione secondaria GKE è abilitata per un cluster o sono stati creati bilanciatori del carico di rete passthrough esterni con cloud.google.com/l4-rbs: "enabled" su GKE versione 1.32.2-gke.1652000 o successive, GKE crea un NEG GCE_VM_IP univoco in ogni zona per ogni servizio LoadBalancer. A differenza dei gruppi di istanze, i nodi possono essere membri di più di un NEG GCE_VM_IP con bilanciamento del carico. Il externalTrafficPolicy del servizio e il numero di nodi nel cluster determinano quali nodi vengono aggiunti come endpoint ai NEG GCE_VM_IP del servizio.

Il control plane del cluster aggiunge i nodi come endpoint ai NEG GCE_VM_IP in base al valore di externalTrafficPolicy del servizio e al numero di nodi nel cluster, come riassunto nelle tabelle seguenti.

Nodi nel bilanciatore del carico di rete passthrough interno

externalTrafficPolicy	Numero di nodi nel cluster	Appartenenza all'endpoint
Cluster	Da 1 a 25 nodi	GKE utilizza tutti i nodi del cluster come endpoint per i NEG del servizio, anche se un nodo non contiene un pod di servizio per il servizio.
Cluster	più di 25 nodi	GKE utilizza un sottoinsieme casuale di un massimo di 25 nodi come endpoint per i NEG del servizio, anche se un nodo non contiene un pod di servizio per il servizio.
Local	un numero qualsiasi di nodi1	GKE utilizza solo i nodi che hanno almeno uno dei pod di servizio come endpoint per i NEG del servizio.

Nodi nel bilanciatore del carico di rete passthrough esterno

externalTrafficPolicy	Numero di nodi nel cluster	Appartenenza all'endpoint
Cluster	Da 1 a 250 nodi	GKE utilizza tutti i nodi del cluster come endpoint per i NEG del servizio, anche se un nodo non contiene un pod di servizio per il servizio.
Cluster	più di 250 nodi	GKE utilizza un sottoinsieme casuale di un massimo di 250 nodi come endpoint per i NEG del servizio, anche se un nodo non contiene un pod di servizio per il servizio.
Local	un numero qualsiasi di nodi1	GKE utilizza solo i nodi che hanno almeno uno dei pod di servizio come endpoint per i NEG del servizio.

Limitazione di un singolo gruppo di istanze con bilanciamento del carico

L'API Compute Engine impedisce alle VM di essere membri di più di un gruppo di istanze con bilanciamento del carico. I nodi GKE sono soggetti a questo vincolo.

Quando utilizzi i backend dei gruppi di istanze non gestite, GKE crea o aggiorna i gruppi di istanze non gestite contenenti tutti i nodi di tutti i node pool in ogni zona utilizzata dal cluster. Questi gruppi di istanze non gestite vengono utilizzati per:

• Bilanciatori del carico di rete passthrough interni creati per i servizi LoadBalancer interni quando l'impostazione secondaria di GKE è disattivata.
• Bilanciatori del carico di rete passthrough esterni basati sui servizi di backend creati per i servizi LoadBalancer esterni con l'annotazione cloud.google.com/l4-rbs: "enabled".
• Bilanciatori del carico delle applicazioni esterni creati per risorse GKE Ingress esterne, utilizzando il controller GKE Ingress, ma non utilizzando il bilanciamento del carico nativo dei container.

Poiché le VM dei nodi non possono essere membri di più di un gruppo di istanze con bilanciamento del carico, GKE non può creare e gestire bilanciatori del carico di rete passthrough interni, bilanciatori del carico di rete passthrough esterni basati su servizi di backend e bilanciatori del carico delle applicazioni esterni creati per le risorse Ingress di GKE se una delle seguenti condizioni è vera:

• Al di fuori di GKE, hai creato almeno un bilanciatore del carico basato su un servizio di backend e hai utilizzato i gruppi di istanze gestite del cluster come backend per il servizio di backend del bilanciatore del carico.
• Al di fuori di GKE, crea un gruppo di istanze non gestite personalizzato che contenga alcuni o tutti i nodi del cluster, quindi collega questo gruppo di istanze non gestite personalizzato a un servizio di backend per un bilanciatore del carico.

Per ovviare a questa limitazione, puoi indicare a GKE di utilizzare i backend NEG ove possibile:

• Abilita il sottoinsieme GKE. Di conseguenza, i nuovi servizi LoadBalancer interni utilizzano invece i NEG GCE_VM_IP.
• Configura le risorse GKE Ingress esterne per utilizzare il bilanciamento del carico nativo dei container. Per ulteriori informazioni, consulta Bilanciamento del carico nativo dei container di GKE.

Controlli di integrità del bilanciatore del carico

Tutti i servizi LoadBalancer di GKE implementano un controllo di integrità del bilanciatore del carico. Il sistema di controllo di integrità del bilanciatore del carico opera al di fuori del cluster ed è diverso da un probe di idoneità, attività o avvio del pod.

Ai pacchetti di controllo di integrità del bilanciatore del carico rispondono il software kube-proxy (piano dati legacy) o cilium-agent (GKE Dataplane V2) in esecuzione su ogni nodo. I controlli di integrità del bilanciatore del carico per i servizi LoadBalancer non possono essere eseguiti dai pod.

Il externalTrafficPolicy del servizio determina quali nodi superano il controllo di integrità del bilanciatore del carico. Per ulteriori informazioni su come il bilanciatore del carico utilizza le informazioni controllo di integrità, consulta Distribuzione del traffico.

externalTrafficPolicy	Quali nodi superano il controllo di integrità	Quale porta viene utilizzata
Cluster	Tutti i nodi del cluster superano il controllo di integrità, inclusi i nodi senza pod di gestione. Se su un nodo esiste almeno un pod di servizio, il nodo supera il controllo di integrità del bilanciatore del carico indipendentemente dallo stato del pod.	La porta del controllo di integrità del bilanciatore del carico deve essere la porta TCP 10256. Non può essere personalizzato.
Local	Il controllo di integrità del bilanciatore del carico considera un nodo integro se sul nodo esiste almeno un pod di servizio pronto e non in fase di terminazione, indipendentemente dallo stato di qualsiasi altro pod. I nodi senza un pod di servizio, i nodi i cui pod di servizio non superano i probe di idoneità e i nodi i cui pod di servizio sono tutti in fase di terminazione non superano il controllo di integrità del bilanciatore del carico. Durante le transizioni di stato, un nodo supera comunque il controllo di integrità del bilanciatore del carico finché non viene raggiunta la soglia di non integrità del controllo di integrità del bilanciatore del carico. Lo stato di transizione si verifica quando tutti i pod di pubblicazione su un nodo iniziano a non superare i probe di idoneità o quando tutti i pod di pubblicazione su un nodo sono in fase di terminazione. Il modo in cui il pacchetto viene elaborato in questa situazione dipende dalla versione di GKE. Per ulteriori dettagli, consulta la sezione successiva, Elaborazione dei pacchetti.	Il control plane Kubernetes assegna la porta del controllo di integrità dall'intervallo di porte del nodo, a meno che non specifichi una porta del controllo di integrità personalizzata.

Quando il bilanciamento del carico ponderato è attivato, il bilanciatore del carico utilizza sia le informazioni sull'integrità sia quelle sul peso per identificare l'insieme di backend dei nodi idonei. Per ulteriori informazioni, consulta Effetto del bilanciamento del carico ponderato.

Quando l'affinità di zona è abilitata, il bilanciatore del carico potrebbe perfezionare l'insieme di backend dei nodi idonei. Per saperne di più, vedi Effetto dell'affinità zonale.

Elaborazione dei pacchetti

Le sezioni seguenti descrivono in dettaglio il funzionamento del bilanciatore del carico e dei nodi del cluster per instradare i pacchetti ricevuti per i servizi LoadBalancer.

Bilanciamento del carico pass-through

I bilanciatori del carico di rete passthrough instradano i pacchetti all'interfaccia nic0 dei nodi del cluster GKE. Ogni pacchetto bilanciato del carico ricevuto su un nodo ha le seguenti caratteristiche:

• L'indirizzo IP di destinazione del pacchetto corrisponde all'indirizzo IP della regola di forwarding del bilanciatore del carico.
• Il protocollo e la porta di destinazione del pacchetto corrispondono a entrambi questi valori:
  • un protocollo e una porta specificati in spec.ports[] del manifest del servizio
  • un protocollo e una porta configurati nella regola di forwarding del bilanciatore del carico

Network Address Translation di destinazione sui nodi

Dopo aver ricevuto il pacchetto, il nodo esegue un'ulteriore elaborazione del pacchetto. Nei cluster GKE che utilizzano il dataplane legacy, i nodi utilizzano iptables per elaborare i pacchetti bilanciati del carico. Nei cluster GKE con GKE Dataplane V2 abilitato, i nodi utilizzano eBPF. L'elaborazione dei pacchetti a livello di nodo include sempre le seguenti azioni:

• Il nodo esegue la Network Address Translation di destinazione (DNAT) sul pacchetto, impostando il relativo indirizzo IP di destinazione su un indirizzo IP del pod di pubblicazione.
• Il nodo modifica la porta di destinazione del pacchetto in targetPort del spec.ports[] del servizio corrispondente.

Network Address Translation e routing di origine sui nodi

La tabella seguente mostra la relazione tra externalTrafficPolicy e se il nodo che ha ricevuto i pacchetti bilanciati del carico esegue la conversione dell'indirizzo di rete di origine (SNAT) prima di inviarli a un pod:

externalTrafficPolicy	Comportamento SNAT
Cluster	Nei cluster GKE che utilizzano il piano dati legacy, ogni nodo che ha ricevuto pacchetti bilanciati del carico modifica sempre l'indirizzo IP di origine di questi pacchetti in modo che corrisponda all'indirizzo IP del nodo, indipendentemente dal fatto che il nodo indirizzi i pacchetti a un pod locale o a un pod su un nodo diverso. Nei cluster GKE che utilizzano GKE Dataplane V2, ogni nodo che ha ricevuto pacchetti bilanciati dal carico modifica l'indirizzo IP di origine di questi pacchetti in modo che corrisponda all'indirizzo IP del nodo solo se il nodo ricevente indirizza i pacchetti a un pod su un nodo diverso. Se il nodo che ha ricevuto i pacchetti bilanciati del carico li indirizza a un pod locale, non modifica l'indirizzo IP di origine di questi pacchetti.
Local	Ogni nodo che ha ricevuto pacchetti bilanciati dal carico instrada i pacchetti esclusivamente a un pod locale e il nodo non modifica l'indirizzo IP di origine di questi pacchetti.

La tabella seguente mostra in che modo externalTrafficPolicy controlla il routing dei pacchetti con bilanciamento del carico e dei pacchetti di risposta da parte dei nodi:

externalTrafficPolicy	Routing dei pacchetti con bilanciamento del carico	Routing dei pacchetti di risposta
Cluster	Di seguito è riportato il comportamento di base per il routing dei pacchetti con bilanciamento del carico: Se il nodo che ha ricevuto i pacchetti con bilanciamento del carico non ha un pod in servizio, pronto e non in fase di terminazione, il nodo indirizza i pacchetti a un altro nodo che ha un pod in servizio, pronto e non in fase di terminazione. Se il nodo che ha ricevuto pacchetti con bilanciamento del carico ha un pod di servizio pronto e non in fase di terminazione, il nodo potrebbe instradare i pacchetti a uno dei seguenti elementi: Un pod locale. Un nodo diverso con un pod di servizio pronto e non in fase di terminazione. Nei cluster regionali, se il nodo che ha ricevuto i pacchetti bilanciati instrada i pacchetti a un nodo diverso, l'affinità di zona ha il seguente effetto: Se l'affinità di zona non è attivata, il nodo diverso potrebbe trovarsi in qualsiasi zona. Se l'affinità a livello di zona è abilitata, il nodo che ha ricevuto i pacchetti con bilanciamento del carico tenta di instradarli a un altro nodo nella stessa zona. Se non è possibile, il nodo diverso può trovarsi in qualsiasi zona. Come ultima risorsa, se non sono presenti pod di servizio, pronti e non in fase di terminazione per il servizio su tutti i nodi del cluster, si verifica quanto segue: Se gli endpoint di terminazione proxy sono abilitati1, il nodo che ha ricevuto i pacchetti bilanciati del carico li indirizza a un pod di pubblicazione, ma di terminazione, se possibile. Se gli endpoint di terminazione del proxy sono disattivati o non sono presenti pod nell'intero cluster, il nodo che ha ricevuto i pacchetti bilanciati del carico chiude la connessione con un ripristino TCP.	I pacchetti di risposta vengono sempre inviati da un nodo utilizzando Direct Server Return: Se il nodo con il pod di servizio non è il nodo che ha ricevuto i pacchetti con bilanciamento del carico corrispondenti, il nodo di servizio invia i pacchetti di risposta al nodo ricevente. Il nodo ricevente invia i pacchetti di risposta utilizzando il ritorno diretto del server. Se il nodo con il pod di pubblicazione è il nodo che ha ricevuto i pacchetti bilanciati del carico, questo nodo invia i pacchetti di risposta utilizzando il ritorno diretto del server.
Local	Di seguito è riportato il comportamento di base per il routing dei pacchetti con bilanciamento del carico: il nodo che ha ricevuto i pacchetti con bilanciamento del carico in genere ha un pod di servizio pronto e non in fase di terminazione (perché è necessario un pod di questo tipo per superare il controllo di integrità del bilanciatore del carico). Il nodo instrada i pacchetti con bilanciamento del carico a un pod locale. Nei cluster regionali, l'affinità di zona non modifica il comportamento di base per il routing dei pacchetti bilanciati del carico. Come ultima risorsa, se non sono presenti pod di servizio, pronti e non terminati per il servizio sul nodo che ha ricevuto pacchetti con bilanciamento del carico, si verifica quanto segue: Se gli endpoint di terminazione proxy sono abilitati1, il nodo che ha ricevuto i pacchetti bilanciati del carico li indirizza a un pod di servizio locale, ma di terminazione, se possibile. Se gli endpoint di terminazione del proxy sono disattivati o il nodo che ha ricevuto pacchetti bilanciati del carico non ha alcun pod di servizio, il nodo chiude la connessione con un ripristino TCP.	Il nodo con il pod di servizio è sempre il nodo che ha ricevuto i pacchetti bilanciati del carico e questo nodo invia i pacchetti di risposta utilizzando il ritorno diretto del server.

Quote

Il numero di regole di forwarding che puoi creare è controllato dalle quote del bilanciatore del carico:

• I bilanciatori del carico di rete passthrough interni utilizzano la quota per progetto dei servizi di backend, la quota per progetto dei controlli di integrità e la quota per progetto delle regole di forwarding del bilanciatore del carico di rete passthrough interno per rete Virtual Private Cloud.
• I bilanciatori del carico di rete passthrough esterni basati sui servizi di backend utilizzano la quota per progetto dei servizi di backend, la quota per progetto dei controlli di integrità e la quota per progetto delle regole di forwarding del bilanciatore del carico di rete passthrough esterno.
• I bilanciatori del carico di rete passthrough esterni basati su pool di destinazione utilizzano la quota di pool di destinazione per progetto, la quota di controlli di integrità per progetto e la quota di regole di forwarding del bilanciatore del carico di rete passthrough esterno per progetto.

Passaggi successivi

• Scopri di più sui parametri del servizio di bilanciamento del carico GKE.
• Scopri di più sui servizi Kubernetes.