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.

Personalizza il servizio LoadBalancer per una rete

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

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 la sezione 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 di ricevere una percentuale maggiore di nuove connessioni rispetto ai nodi con meno pod di servizio.

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 abilitato 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.

Per saperne di più sul bilanciamento del carico ponderato dal punto di vista del bilanciatore del carico, consulta Bilanciamento del carico ponderato nel bilanciatore del carico di rete passthrough esterno basato sul servizio di backend.

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 disattivata 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 250 o meno 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 un massimo di 250 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 ulteriori informazioni, consulta Iscrizione dei nodi ai backend NEG di GCE_VM_IP.

Affinità sessione e distribuzione del traffico

L'affinità sessione ti consente di controllare il modo in cui il bilanciatore del carico assegna una richiesta di un client a un backend e garantisce che tutte le richieste successive del client vengano reindirizzate allo stesso backend.

Quando utilizzi un bilanciatore del carico di rete passthrough interno con l'affinità sessione impostata su CLIENT_IP, potresti notare una distribuzione del traffico non uniforme ai backend. Questo perché il bilanciatore del carico invia sempre il traffico da un determinato indirizzo IP client allo stesso backend. Se hai un numero ridotto di client con un volume di traffico elevato, alcuni backend potrebbero essere sovraccarichi, mentre altri sottoutilizzati.

Per saperne di più, consulta Opzioni di affinità di sessione.

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 Trusted Cloud risultante e il tipo di backend. 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 del nodo o del 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. Il 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. Il externalTrafficPolicy del servizio controlla 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 del 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. Il 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 gestiti a livello di zona	Tutte le VM dei nodi vengono inserite in gruppi di istanze non gestiti a livello di zona che GKE utilizza come backend per il servizio di backend del bilanciatore del carico di rete passthrough esterno. Il externalTrafficPolicy del servizio controlla 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 del 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 del servizio controlla 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 il subsetting GKE è abilitato per un cluster o sono stati creati bilanciatori del carico di rete pass-through 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 pubblicazione 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 pool di nodi 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 il sottoinsieme GKE è disattivato.
• 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, crei un gruppo di istanze non gestite personalizzato che contiene alcuni o tutti i nodi del cluster, quindi colleghi 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 di 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, vedi 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 (legacy dataplane) 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:

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 stato non integro 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 tu non specifichi una porta del controllo di integrità personalizzata.

Quando il bilanciamento del carico ponderato è abilitato, il software kube-proxy o cilium-agent include 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 terminanti sul nodo. Il bilanciatore del carico instrada le nuove connessioni ai pod di gestione in base a questo peso.

Elaborazione dei pacchetti

Le sezioni seguenti descrivono in dettaglio il funzionamento del bilanciatore del carico e dei nodi del cluster per indirizzare 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 di origine sui nodi

externalTrafficPolicy determina se l'elaborazione dei pacchetti a livello di nodo esegue anche la Network Address Translation dell'origine (SNAT) e il percorso che il pacchetto segue dal nodo al pod:

externalTrafficPolicy	Comportamento SNAT del nodo	Comportamento di routing
Cluster	Nei cluster GKE senza GKE Dataplane V2, il nodo modifica l'indirizzo IP di origine dei pacchetti con bilanciamento del carico in modo che corrisponda all'indirizzo IP del nodo che lo ha ricevuto dal bilanciatore del carico. Nei cluster GKE con GKE Dataplane V2, il nodo non modifica l'indirizzo IP di origine dei pacchetti bilanciati del carico quando inoltra il traffico a un pod di servizio sullo stesso nodo. Tuttavia, viene eseguito SNAT se il traffico viene inoltrato a un pod su un nodo diverso.	Il nodo instrada i pacchetti a qualsiasi pod di pubblicazione. Il pod di pubblicazione potrebbe trovarsi o meno sullo stesso nodo. Se il nodo che riceve i pacchetti dal bilanciatore del carico non dispone di un pod pronto e in servizio, il nodo indirizza i pacchetti a un nodo diverso che contiene un pod pronto e in servizio. I pacchetti di risposta del pod vengono instradati dal nodo al nodo che ha ricevuto i pacchetti di richiesta dal bilanciatore del carico. Il primo nodo invia quindi i pacchetti di risposta al client originale utilizzando Direct Server Return.
Local	Il nodo non modifica l'indirizzo IP di origine dei pacchetti con bilanciamento del carico.	Nella maggior parte dei casi, il nodo indirizza il pacchetto a un pod di servizio in esecuzione sul nodo che ha ricevuto il pacchetto dal bilanciatore del carico. Questo nodo invia pacchetti di risposta al client originale utilizzando Direct Server Return. Questo è l'intento principale di questo tipo di criterio sul traffico. In alcune situazioni, un nodo riceve pacchetti dal bilanciatore del carico anche se non dispone di un pod di servizio pronto e non terminante per il servizio. Questa situazione si verifica quando il controllo di integrità del bilanciatore del carico non ha ancora raggiunto la soglia di errore, ma un pod precedentemente pronto e in servizio non è più pronto o è in fase di terminazione (ad esempio, durante un aggiornamento in sequenza). Il modo in cui i pacchetti vengono elaborati in questa situazione dipende dalla versione di GKE, dal fatto che il cluster utilizzi GKE Dataplane V2 e dal valore di externalTrafficPolicy: Senza GKE Dataplane V2, in GKE 1.26 e versioni successive e con GKE Dataplane V2 nelle versioni GKE 1.26.4-gke.500 e successive, è abilitato Proxy Terminating Endpoints. I pacchetti vengono indirizzati a un pod di terminazione come ultima risorsa, se vengono soddisfatte tutte le seguenti condizioni: Se tutti i pod di pubblicazione vengono terminati e externalTrafficPolicy è Cluster. Se tutti i pod di pubblicazione sul nodo vengono terminati e il externalTrafficPolicy è Local. Per tutte le altre versioni di GKE, il pacchetto riceve risposta dal kernel del nodo con un ripristino TCP.

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 di servizi di backend per progetto, la quota di controlli di integrità per progetto e la quota di 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 dei servizi di backend per progetto, la quota dei controlli di integrità per progetto e la quota delle regole di forwarding del bilanciatore del carico di rete passthrough esterno per progetto.
• 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.