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. Cloud de Confiance by S3NS Descrive i tipi di LoadBalancer, i parametri di configurazione e fornisce consigli sulle best practice.

Prima di leggere questa pagina, assicurati di conoscere i concetti di networking di GKE.

Panoramica

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

Personalizza 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 rete VPC e le VM con accesso a internet possono accedere a un servizio LoadBalancer esterno. Cloud de Confiance

  Per creare un servizio LoadBalancer esterno, utilizza una delle seguenti tecniche:

  • Nei cluster che eseguono GKE 1.33.1-gke.1779000 o versioni successive, aggiungi spec.loadBalancerClass: "networking.gke.io/l4-regional-external" al manifest del servizio prima di inviarlo al cluster. Ti consigliamo di utilizzare questo campo perché crea sempre un bilanciatore del carico di rete passthrough esterno basato su un servizio di backend con backend NEG GCE_VM_IP. Il campo spec.loadBalancerClass è immutabile e non può essere modificato dopo la creazione del servizio.

  • Nei cluster che eseguono qualsiasi versione GKE supportata, puoi aggiungere l'annotazione cloud.google.com/l4-rbs: "enabled" al manifest del servizio prima di inviarlo al cluster. Questa annotazione crea anche un bilanciatore del carico di rete passthrough esterno basato sui servizi di backend. Il bilanciatore del carico utilizza i backend NEG GCE_VM_IP se il manifest viene inviato a un cluster che esegue GKE 1.32.2-gke.1652000 o versioni successive. In caso contrario, il bilanciatore del carico utilizza i backend del gruppo di istanze. GKE valuta questa annotazione solo quando il manifest del servizio viene applicato per la prima volta al cluster.

• 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 LoadBalancer interno.

  Come best practice, prima di creare un servizio LoadBalancer interno, assicurati che il sottoinsieme GKE sia abilitato. L'impostazione secondaria di GKE viene abilitata automaticamente se il cluster esegue GKE 1.36 o versioni successive. Per le versioni precedenti di GKE, devi abilitare esplicitamente l'impostazione secondaria di GKE.

  Per creare un servizio LoadBalancer interno, utilizza una delle seguenti tecniche:

  • Nei cluster che eseguono GKE 1.33.1-gke.1779000 o versioni successive in cui è abilitata l'impostazione secondaria di GKE, aggiungi spec.loadBalancerClass: "networking.gke.io/l4-regional-internal" al manifest del servizio prima di inviarlo al cluster. Ti consigliamo di utilizzare questo campo perché crea sempre un bilanciatore del carico di rete passthrough interno con backend NEG GCE_VM_IP. Il campo spec.loadBalancerClass è immutabile e non può essere modificato dopo la creazione del servizio.

  • Nei cluster che eseguono qualsiasi versione GKE supportata, puoi aggiungere l'annotazione networking.gke.io/load-balancer-type: "Internal" al manifest del servizio prima di inviarlo al cluster. Viene creato anche un bilanciatore del carico di rete passthrough interno. Il bilanciatore del carico utilizza i backend NEG GCE_VM_IP se il manifest viene inviato a un cluster in cui è abilitato il sottoinsieme GKE. In caso contrario, il bilanciatore del carico utilizza i backend dei gruppi di istanze.

I manifest del servizio LoadBalancer che non hanno un spec.loadBalancerClass e che non hanno le annotazioni cloud.google.com/l4-rbs: "enabled" o networking.gke.io/load-balancer-type: "Internal" creano un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione. Sconsigliamo l'utilizzo di bilanciatori del carico di rete passthrough esterni basati su pool di destinazione.

Prerequisito HttpLoadBalancing

Per creare servizi LoadBalancer basati su bilanciatori del carico di rete passthrough esterni o interni basati su servizio di backend, assicurati che il componente aggiuntivo HttpLoadBalancing sia abilitato se il tuo cluster esegue una versione di GKE precedente alla 1.36. Il componente aggiuntivo HttpLoadBalancing è abilitato per impostazione predefinita.

I servizi LoadBalancer in GKE 1.36 e versioni successive non dipendono dal componente aggiuntivo HttpLoadBalancing.

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 saperne di più 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 proporzionalmente al numero di pod pronti su ogni nodo.

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.

• Devi creare un servizio LoadBalancer esterno che generi un bilanciatore del carico di rete passthrough esterno basato sul servizio di backend. Puoi utilizzare una delle seguenti tecniche:

  • Nei cluster che eseguono GKE 1.33.1-gke.1779000 o versioni successive, aggiungi spec.loadBalancerClass: "networking.gke.io/l4-regional-external" al manifest del servizio prima di inviarlo al cluster. Questo è il metodo preferito.

  • Nei cluster che eseguono qualsiasi versione GKE supportata, aggiungi l'annotazione cloud.google.com/l4-rbs: "enabled" al manifest del servizio prima di inviarlo al cluster.

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

• 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à a livello di zona (Anteprima), che può instradare le nuove connessioni ai nodi con pod di servizio nella stessa zona di un client. Se non ci sono pod integri nella zona, GKE indirizza il traffico a un'altra zona. Mantenere il traffico all'interno di una zona può ridurre al minimo il traffico tra zone diverse, il che riduce i costi e la latenza. Per abilitare l'affinità di zona in un cluster GKE, devi aver abilitato l'impostazione secondaria di GKE.

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 saperne di più su come l'affinità di zona e externalTrafficPolicy influiscono sul routing dei pacchetti sulle VM dei nodi, consulta Source Network Address Translation e routing sui nodi.

Considerazioni speciali per i servizi LoadBalancer interni

Questa sezione descrive la funzionalità 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

L'impostazione secondaria di GKE per i servizi LoadBalancer interni è abilitata per impostazione predefinita per i cluster GKE che eseguono la versione 1.36 e successive. Per queste versioni, il sottoinsieme GKE rimane attivo anche se il flag --enable-l4-ilb-subsetting a livello di cluster è impostato su false nella configurazione del cluster o negli strumenti Infrastructure as Code (IaC) come Terraform.

Questa opzione di configurazione a livello di cluster migliora la scalabilità dei bilanciatori del carico di rete passthrough interni raggruppando in modo più efficiente gli endpoint dei nodi in GCE_VM_IP gruppi di endpoint di rete (NEG). 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 rispettivo.

Per i cluster che eseguono versioni precedenti alla 1.36, puoi abilitare manualmente l'impostazione secondaria di GKE quando crei un cluster o aggiorni un cluster esistente. Una volta abilitato il sottoinsieme GKE, non puoi disattivarlo.

L'impostazione secondaria GKE richiede:

• GKE 1.18.19-gke.1400 o versioni successive e
• Se il cluster utilizza una versione precedente alla 1.36, è necessario attivare il componente aggiuntivo HttpLoadBalancing. Questo componente aggiuntivo è attivato per impostazione predefinita. Consente al cluster di gestire i bilanciatori del carico che utilizzano i servizi di backend. Se il tuo cluster utilizza la versione 1.36 e successive, il componente aggiuntivo HttpLoadBalancing non è un prerequisito per l'impostazione secondaria di GKE.

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 node pool). 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 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.

Il numero di nodi supportati con il sottoinsieme GKE dipende dal valore del campo externalTrafficPolicy per il servizio LoadBalancer interno:

• externalTrafficPolicy: Local: supporta fino a 250 nodi con pod di servizio per un determinato servizio.

• externalTrafficPolicy: Cluster: non impone un limite al numero di nodi con pod di pubblicazione. Questo comportamento si verifica perché GKE configura un massimo di 25 endpoint nodo nei NEG GCE_VM_IP per ogni servizio. Per saperne di più, consulta Iscrizione dei nodi ai backend NEG GCE_VM_IP.

Distribuzione del traffico

Per impostazione predefinita, i servizi LoadBalancer interni ed esterni creano bilanciatori del carico di rete passthrough con l'affinità sessione 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 indirizzare rapidamente i pacchetti successivi per la connessione al backend del nodo idoneo selezionato in precedenza. Per ulteriori informazioni su come i bilanciatori del carico di rete passthrough 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 attiva 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 che includa un'intestazione della risposta nella risposta al controllo di integrità del bilanciatore del carico. Questa intestazione della risposta definisce un peso proporzionale al numero di pod in 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 un bilanciamento del carico ponderato efficace), è più probabile che venga selezionato un backend di nodi idoneo che dispone di più pod di pubblicazione, pronti e non terminati 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 maggiori dettagli su come la configurazione dell'affinità zonale influisce sul comportamento del bilanciatore del carico, consulta la documentazione relativa all'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. Cloud de Confiance

La tabella seguente descrive i metodi di raggruppamento dei nodi per le diverse configurazioni del servizio LoadBalancer:

Dettagli del servizio e del cluster	Bilanciatore del carico Cloud de Confiance risultante	Metodo di raggruppamento dei nodi
Servizi LoadBalancer interni
GKE versione 1.33.1-gke.1779000 o successive in un cluster con l'impostazione secondaria di GKE abilitata1. Manifest del servizio inviato al cluster con spec.loadBalancerClass: "networking.gke.io/l4-regional-internal".	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 in GCE_VM_IP NEG zonali in base al servizio in base al 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.
Tutte le versioni GKE supportate in un cluster con l'impostazione secondaria di GKE abilitata1. Manifest del servizio inviato al cluster con l'annotazione networking.gke.io/load-balancer-type: "Internal".
Versioni di GKE precedenti alla 1.36 in un cluster con l'impostazione secondaria di GKE disabilitata1. Manifest del servizio inviato al cluster con l'annotazione networking.gke.io/load-balancer-type: "Internal".	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 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.
Servizi LoadBalancer esterni
GKE 1.33.1-gke.1779000 o versioni successive. Manifest del servizio inviato al cluster con spec.loadBalancerClass: "networking.gke.io/l4-regional-external".	Un bilanciatore del carico di rete passthrough esterno basato sui servizio di backend con backend di gruppi di endpoint di rete (NEG) GCE_VM_IP	Le VM dei nodi sono raggruppate in GCE_VM_IP NEG zonali in base al servizio in base al 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.
GKE 1.32.2-gke.1652000 o versioni successive. Manifest del servizio inviato al cluster con l'annotazione cloud.google.com/l4-rbs: "enabled"2.
Versione GKE precedente alla 1.32.2-gke.16520003. Manifest del servizio inviato al cluster con l'annotazione cloud.google.com/l4-rbs: "enabled"2.	Un bilanciatore del carico di rete passthrough esterno basato sui servizio di backend con backend di gruppi di istanze non gestiti 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. Il 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.
Tutte le versioni di GKE supportate. Manifest del servizio inviato al cluster senza tutti i seguenti elementi: spec.loadBalancerClass networking.gke.io/load-balancer-type annotazione cloud.google.com/l4-rbs annotazione	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 NEG o gruppi di istanze. Tutti i nodi sono membri diretti del pool di destinazione. Il 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 GKE crea un bilanciatore del carico di rete passthrough interno o un bilanciatore del carico di rete passthrough esterno basato su servizio di backend con backend NEG GCE_VM_IP, crea e gestisce i NEG nel seguente modo:

• 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ù NEG GCE_VM_IP con bilanciamento del carico.

• L'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 gestisce gli endpoint dei nodi nei NEG GCE_VM_IP in base al valore di externalTrafficPolicy del servizio e al numero di nodi nel cluster, come riepilogato 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 pubblicazione del 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 pubblicazione del 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 sono backend per i seguenti bilanciatori del carico creati da GKE:

• Un bilanciatore del carico di rete passthrough interno creato per un servizio LoadBalancer interno il cui manifest contiene l'annotazione networking.gke.io/load-balancer-type: "Internal", inviato a un cluster che esegue una versione di GKE precedente alla 1.36, con l'impostazione secondaria di GKE disattivata.
• Un bilanciatore del carico di rete passthrough esterno basato su un servizio di backend creato per un servizio LoadBalancer esterno il cui manifest contiene l'annotazione cloud.google.com/l4-rbs: "enabled", inviato a un cluster che esegue una versione di GKE precedente alla 1.32.2-gke.1652000.
• Un bilanciatore del carico delle applicazioni esterno creato per un GKE Ingress esterno, utilizzando il controller GKE Ingress, ma non 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 questo limite, puoi indicare a GKE di utilizzare i backend NEG:

• Crea servizi LoadBalancer che utilizzano NEG GCE_VM_IP. Per saperne di più, vedi Raggruppamento dei nodi.
• Configura le risorse GKE Ingress esterne per utilizzare il bilanciamento del carico nativo dei container. Per saperne di più, consulta Bilanciamento del carico nativo dei container 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. Per saperne di più su come il bilanciatore del carico utilizza le informazionicontrollo 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 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 tu non specifichi una porta del controllo di integrità personalizzata.

Quando il bilanciamento del carico ponderato è abilitato, 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ù, consulta 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 piano dati 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 e routing 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 inviare i pacchetti bilanciati del carico a un pod:

externalTrafficPolicy	Comportamento SNAT
Cluster	Nei cluster GKE che utilizzano il dataplane 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 instradi 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 del 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 instrada 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 bilanciati del carico non ha un pod di servizio pronto e non in fase di terminazione, instrada i pacchetti a un nodo diverso che ha un pod di 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: 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 è abilitata, il nodo diverso potrebbe trovarsi in qualsiasi zona. Se l'affinità a livello di zona è abilitata, il nodo che ha ricevuto 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 servizio, 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 di ricezione invia quindi i pacchetti di risposta utilizzando Direct Server Return. 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 l'instradamento 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 terminante (perché avere un pod di questo tipo è necessario 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 bilanciati 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 pubblicazione, 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 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 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 LoadBalancer.
• Scopri come configurare un bilanciatore del carico interno.
• Leggi una panoramica di Ingress per i bilanciatori del carico delle applicazioni.
• Scopri come utilizzare le estensioni di Google autonome.
• Scopri di più sull'API Gateway.