Informazioni sui servizi LoadBalancer

Autopilot Standard

Questa pagina fornisce una panoramica generale di come Google Kubernetes Engine (GKE) crea e gestisce i bilanciatori del carico Google Cloud quando applichi un manifest dei servizi LoadBalancer di Kubernetes. Descrive i tipi di LoadBalancer, i parametri di configurazione e fornisce suggerimenti 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 Google Cloud bilanciatore del carico passthrough le cui caratteristiche dipendono dai parametri del manifest del servizio.

Personalizza il servizio LoadBalancer

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

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

Figura: albero decisionale del servizio LoadBalancer

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 regionali. I client che si trovano all'esterno della tua rete VPC e le VM Google Cloud con accesso a internet possono accedere a un servizio LoadBalancer esterno.

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

  • Nei cluster che eseguono GKE 1.37 o versioni successive, GKE crea automaticamente un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend con backend NEG GCE_VM_IP. Non è necessario aggiungere annotazioni o campi al manifest del servizio. Per creare esplicitamente un bilanciatore del carico legacy basato su pool di destinazione, aggiungi la coppia chiave-valore spec.loadBalancerClass: "networking.gke.io/l4-regional-external-legacy".

  • Nei cluster che eseguono GKE dalla versione 1.33.1-gke.1779000 alla versione 1.36, aggiungi spec.loadBalancerClass: "networking.gke.io/l4-regional-external" al manifest del Service prima di inviarlo al cluster. Ti consigliamo di utilizzare questo campo perché crea sempre un bilanciatore del carico di rete passthrough esterno regionale 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 regionale basato su un servizio 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 dei gruppi 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 gke-subsetting sia abilitato. Il subsetting GKE viene abilitato automaticamente se il cluster esegue GKE 1.36 o versioni successive. Per le versioni GKE precedenti, devi abilitare esplicitamente la suddivisione in sottoinsiemi 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 con il subsetting GKE abilitato, aggiungi spec.loadBalancerClass: "networking.gke.io/l4-regional-internal" al manifest del Service 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 Service prima di inviarlo al cluster. In questo modo 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 subsetting GKE. In caso contrario, il bilanciatore del carico utilizza i backend dei gruppi di istanze.

Per i cluster che eseguono versioni di GKE precedenti alla 1.37, 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 regionale basato su un pool di destinazione. Sconsigliamo di utilizzare bilanciatori del carico di rete passthrough esterni regionali basati su pool di destinazione.

Prerequisito HttpLoadBalancing

Per creare servizi LoadBalancer basati su bilanciatori del carico di rete passthrough esterni regionali o bilanciatori del carico di rete passthrough 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 versione 1.36 e 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 consegnati 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 distribuzione, pronto e non in fase di terminazione, conservando l'indirizzo IP di origine del client originale. Questa opzione è ideale per i workload con un numero relativamente costante di nodi con pod di distribuzione, anche se il numero complessivo di nodi nel cluster varia. Questa opzione è obbligatoria per supportare il bilanciamento del carico ponderato.

Nota: l'utilizzo della policy Local per conservare gli indirizzi IP di origine non funzionerà se ip-masq-agent è in esecuzione sul tuo cluster e l'intervallo di indirizzi IP dei pod non è escluso dall'IP masquerading. Consulta custom nonMasqueradeCIDRs list in the ip-masq-agent configMap per istruzioni su come escludere gli intervalli di indirizzi IP dal mascheramento.

• Utilizza externalTrafficPolicy: Cluster in situazioni in cui il numero complessivo di nodi nel cluster è relativamente costante, ma il numero di nodi con pod di distribuzione varia. Questa opzione non conserva gli indirizzi IP di origine del client originale e può aggiungere latenza perché i pacchetti potrebbero essere indirizzati a un pod di distribuzione 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.

Importante: per i servizi LoadBalancer interni, externalTrafficPolicy determina indirettamente anche il numero di nodi con pod di distribuzione supportati. Per saperne di più, consulta Considerazioni sul numero di nodi.

Bilanciamento del carico ponderato

I servizi LoadBalancer esterni supportano il bilanciamento del carico ponderato, che consente ai nodi con più pod in stato di pubblicazione, pronto e non in fase di terminazione 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.

Figura: distribuzione del traffico con bilanciamento del carico ponderato

Come illustrato nel diagramma, i servizi con bilanciamento del carico ponderato abilitato distribuiscono le nuove connessioni in modo proporzionale al numero di pod pronti su ciascun 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 successiva.

• Devi creare un servizio LoadBalancer esterno che generi un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend.

  • Nei cluster che eseguono GKE 1.37 o versioni successive, GKE crea questo tipo di bilanciatore del carico per impostazione predefinita. Non sono richiesti campi o annotazioni aggiuntivi.

  • Nei cluster che eseguono GKE dalla versione 1.33.1-gke.1779000 alla versione 1.36, 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 Service prima di inviare il manifest al cluster.

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

• Il manifest del servizio LoadBalancer deve utilizzare externalTrafficPolicy: Local. GKE non impedisce l'utilizzo di externalTrafficPolicy: Cluster, ma externalTrafficPolicy: Cluster disabilita di fatto 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, consulta Attiva il bilanciamento del carico ponderato.

Affinità a livello di zona

I servizi LoadBalancer interni supportano l'affinità di zona, che può instradare le nuove connessioni ai nodi con pod di distribuzione nella stessa zona di un client. Se nella zona non sono presenti pod integri, GKE instrada il traffico a un'altra zona. 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 abilitare l'affinità di zona in un cluster GKE, devi abilitare la suddivisione in sottoinsiemi GKE.

Quando configuri l'affinità di zona per un servizio LoadBalancer interno, GKE configura il bilanciatore del carico di rete passthrough interno corrispondente con l'opzione ZONAL_AFFINITY_SPILL_CROSS_ZONE e un rapporto di spillover pari a zero (0.0). Questa configurazione contribuisce a garantire che il traffico venga interrotto all'interno della zona anziché riversarsi in altre zone. 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à di zona.

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

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

Per ulteriori dettagli su come la configurazione dell'affinità di zona influisce sul comportamento del bilanciatore del carico, consulta la documentazione sull'affinità di zona. Per ulteriori informazioni su come l'affinità di zona e externalTrafficPolicy influenzano il routing dei pacchetti sulle VM dei nodi, consulta Network Address Translation di origine e routing sui nodi.

Considerazioni sulla scalabilità con l'affinità a livello di zona

Poiché l'affinità di zona non si integra in modo nativo con HorizontalPodAutoscaler (HPA), possono verificarsi problemi di scalabilità quando il traffico all'interno di una zona supera la capacità dei pod in quella zona. L'HPA scala i pod in base alle metriche aggregate del cluster anziché al carico per zona. Di conseguenza, una zona con un traffico elevato (sovraccarico della zona) potrebbe non ricevere pod aggiuntivi, il che comporta un peggioramento delle prestazioni o l'interruzione delle connessioni per i client in quella zona, anche se il cluster nel suo complesso è sottoutilizzato.

Famiglie di indirizzi IP

Un servizio LoadBalancer può essere a stack singolo (solo IPv4 o solo IPv6) o a doppio stack. Puoi controllarlo con i campi spec.ipFamilyPolicy e spec.ipFamilies. Un servizio a stack singolo ha una regola di forwarding, mentre un servizio a doppio stack ne ha due: una per IPv4 e una per IPv6.

I servizi LoadBalancer IPv6 hanno le seguenti caratteristiche aggiuntive:

• Utilizzano sempre backend NEG GCE_VM_IP.
• I loro indirizzi IPv6 provengono da un intervallo di subnet nella tua rete VPC (il cui tipo di accesso IPv6 deve corrispondere al tipo di bilanciatore del carico) o da indirizzi IPv6 BYO (BYOIPv6):
  • I servizi LoadBalancer IPv6 interni possono utilizzare subnet interne di cui è stato eseguito il provisioning da un prefisso delegato pubblico BYOIPv6.
  • In GKE versione 1.37.1-gke.2097000 e successive, i servizi LoadBalancer IPv6 esterni single-stack supportano l'allocazione diretta di intervalli di indirizzi BYOIPv6 esterni da un sottoprefisso IPv6 regionale di un prefisso delegato pubblico. Puoi configurare questa allocazione utilizzando l'annotazione networking.gke.io/ip-collection-v6 o specificando un intervallo di indirizzi BYOIPv6 esterni statici.
• I servizi LoadBalancer IPv6 esterni richiedono un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend.

Per saperne di più, consulta Servizi LoadBalancer IPv6 e Bring Your Own IPv6 (BYOIPv6).

Considerazioni speciali per i servizi LoadBalancer interni

Questa sezione descrive la funzionalità di suddivisione in sottoinsiemi di GKE, che è esclusiva dei servizi LoadBalancer interni, e il modo in cui la suddivisione in sottoinsiemi di GKE interagisce con externalTrafficPolicy per influenzare il numero massimo di nodi con bilanciamento del carico.

Impostazione secondaria GKE

La suddivisione in sottoinsiemi 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, la suddivisione in sottoinsiemi GKE rimane attiva anche se il flag --enable-l4-ilb-subsetting a livello di cluster è impostato su false nella configurazione del cluster o negli strumenti di 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 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 di zona con tre nodi. Il cluster ha il subsetting GKE abilitato. 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 distribuzione per il rispettivo servizio.

Per i cluster che eseguono versioni precedenti alla 1.36, puoi attivare manualmente il GKE Subsetting quando crei un cluster o aggiorni un cluster esistente. Una volta abilitato, il subsetting GKE non può essere disabilitato.

L'impostazione secondaria GKE richiede:

• GKE versione 1.18.19-gke.1400 o successive e
• Se il cluster è su una versione precedente alla 1.36, il componente aggiuntivo HttpLoadBalancing deve essere abilitato. Questo componente aggiuntivo è attivo 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 il subsetting GKE.

Nota: il subsetting GKE è diverso dal Google Cloud subsetting dei backend del bilanciatore del carico di rete passthrough interno. I bilanciatori del carico di rete passthrough interni creati da GKE non vengono mai configurati per utilizzare la suddivisione in subset dei backend dei bilanciatori del carico di rete passthrough interni.

Conteggio nodi

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

• GKE non utilizza la suddivisione in subset del backend del bilanciatore del carico.
• Un bilanciatore del carico di rete passthrough interno può distribuire pacchetti a un massimo di 250 backend quando la suddivisione in sottoinsiemi dei backend del bilanciatore del carico è disabilitata.

Un cluster con suddivisione in sottoinsiemi GKE supporta i servizi LoadBalancer interni nei cluster con più di 250 nodi totali.

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

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

• externalTrafficPolicy: Cluster: non impone un limite al numero di nodi con pod di distribuzione. 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 Appartenenza 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 instradare rapidamente i pacchetti successivi della connessione al backend del nodo idoneo selezionato in precedenza. Per saperne di più 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 regionali

Effetto del bilanciamento del carico ponderato

Quando configuri il bilanciamento del carico ponderato per un servizio di bilanciatore del carico esterno, GKE attiva il bilanciamento del carico ponderato sul bilanciatore del carico di rete passthrough esterno regionale 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 stato di pubblicazione, pronto e non in fase di terminazione su ciascun nodo.

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

• Il set 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 del nodo idoneo con più pod in stato di pubblicazione, pronto e non in fase di terminazione rispetto a un backend del nodo idoneo con meno pod.

Raggruppamento dei nodi

La versione di GKE, le annotazioni del manifest del servizio e, per i servizi LoadBalancer interni, l'opzione di suddivisione in sottoinsiemi di GKE determinano il bilanciatore del carico Google Cloud risultante e il tipo di backend.

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

Dettagli del servizio e del cluster	Bilanciatore del carico Google Cloud risultante	Metodo di raggruppamento dei nodi
Servizi LoadBalancer interni
GKE versione 1.33.1-gke.1779000 o successive in un cluster con subsetting GKE abilitato^1. 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 backend di gruppi di endpoint di rete (NEG) GCE_VM_IP	Le VM dei nodi sono raggruppate in NEG di zona GCE_VM_IP in base al servizio, in base al externalTrafficPolicy del servizio e al numero di nodi nel cluster. Il valore 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 la suddivisione in sottoinsiemi GKE abilitata^1. 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 GKE Subsetting disabilitato^1. 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 a livello di zona	Tutte le VM dei nodi vengono inserite in gruppi di istanze non gestite di zona che GKE utilizza come backend per il servizio di backend del bilanciatore del carico di rete passthrough interno. Il valore 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.
Servizi LoadBalancer esterni
GKE versione 1.37 o successive. Manifest del servizio inviato al cluster, ma la coppia campo-valore spec.loadBalancerClass: "networking.gke.io/l4-regional-external-legacy" non è inclusa.	Un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend con backend di gruppi di endpoint di rete (NEG) GCE_VM_IP	Le VM dei nodi sono raggruppate in NEG di zona GCE_VM_IP in base al servizio, in base al externalTrafficPolicy del servizio e al numero di nodi nel cluster. Il valore externalTrafficPolicy del servizio controlla anche quali nodi superano il controllo di integrità del bilanciatore del carico e l'elaborazione dei pacchetti.
GKE versione da 1.33.1-gke.1779000 a 1.36. Manifest del servizio inviato al cluster con la coppia campo-valore spec.loadBalancerClass: "networking.gke.io/l4-regional-external".
GKE versione da 1.32.2-gke.1652000 a 1.36. Manifest del servizio inviato al cluster con l'annotazione cloud.google.com/l4-rbs: "enabled"^2.
GKE versione precedente alla 1.32.2-gke.1652000^3. Manifest del servizio inviato al cluster con l'annotazione cloud.google.com/l4-rbs: "enabled"^2.	Un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend con backend di gruppi di istanze non gestite a livello di zona	Tutte le VM dei nodi vengono inserite in gruppi di istanze non gestite di zona che GKE utilizza come backend per il servizio di backend del bilanciatore del carico di rete passthrough esterno regionale. Il valore 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.
Versioni di GKE precedenti alla 1.37. 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 OPPURE GKE versione 1.37 o successive. Manifest del servizio inviato al cluster con la coppia chiave-valore spec.loadBalancerClass: "networking.gke.io/l4-regional-external-legacy".	Un bilanciatore del carico di rete passthrough esterno regionale basato su pool di destinazione il cui pool di destinazione contiene tutti i nodi del cluster	Il pool di destinazione è un'API precedente che non si basa su NEG o gruppi di istanze. Tutti i nodi hanno l'appartenenza diretta al pool di destinazione. Il valore externalTrafficPolicy del servizio controlla quali nodi superano il controllo di integrità del bilanciatore del carico e l'elaborazione dei pacchetti.

¹ Il subsetting GKE viene abilitato automaticamente in GKE 1.36 e versioni successive. Il subsetting GKE non può essere disattivato dopo l'attivazione.

² L'annotazione cloud.google.com/l4-rbs: "enabled" viene rispettata solo quando il manifest del servizio viene inviato al cluster. L'aggiunta di questa annotazione a un manifest del Service esistente non converte un bilanciatore del carico di rete passthrough esterno regionale basato su pool di destinazione in un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend.

³ GKE non aggiorna automaticamente i bilanciatori del carico di rete passthrough esterni regionali basati su servizi di backend con backend di gruppi di istanze ai bilanciatori del carico di rete passthrough esterni regionali basati su servizi di backend con backend NEG GCE_VM_IP. Per istruzioni sulla migrazione manuale, consulta Esegui la migrazione ai backend NEG GCE_VM_IP.

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 regionale basato su un servizio di backend con backend NEG GCE_VM_IP, crea e gestisce i NEG in questo 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.

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

• Per un servizio LoadBalancer IPv6, GKE compila il NEG GCE_VM_IP con gli indirizzi IPv6 delle interfacce di rete dei nodi.

Nota: i NEG GCE_VM_IP sono diversi dai NEG GCE_VM_IP_PORT. GCE_VM_IP_PORT I NEG contengono endpoint di IP dei pod e porte dei container e vengono utilizzati da Gateway e Ingress (nativi dei container). GCE_VM_IP I NEG identificano le interfacce di rete delle VM nodo utilizzando l'indirizzo IP del nodo, anche se i pacchetti con bilanciamento del carico hanno destinazioni che corrispondono all'indirizzo IP della regola di forwarding del bilanciatore del carico e a una delle porte configurate per la regola di forwarding.

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 riassunto nelle tabelle seguenti.

Nodi nel bilanciatore del carico di rete passthrough interno

externalTrafficPolicy	Numero di nodi nel cluster	Appartenenza 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 distribuzione 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 distribuzione per il servizio.
Local	qualsiasi numero di nodi^1	GKE utilizza solo i nodi che hanno almeno uno dei pod di distribuzione del servizio come endpoint per i NEG del servizio.

¹Limitato a 250 nodi con pod in uso. Nel cluster possono essere presenti più di 250 nodi, ma i bilanciatori del carico di rete passthrough interni possono distribuire il traffico solo a 250 VM di backend quando la suddivisione in sottoinsiemi dei backend del bilanciatore del carico di rete passthrough interno è disabilitata. Anche se il subsetting GKE è abilitato, GKE non configura mai i bilanciatori del carico di rete passthrough interni con il subsetting dei backend dei bilanciatori del carico di rete passthrough interni. Per informazioni dettagliate su questo limite, consulta Numero massimo di istanze VM per servizio di backend interno.

Nodi nel bilanciatore del carico di rete passthrough esterno regionale

externalTrafficPolicy	Numero di nodi nel cluster	Appartenenza 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 distribuzione 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 distribuzione per il servizio.
Local	qualsiasi numero di nodi^1	GKE utilizza solo i nodi che hanno almeno uno dei pod di distribuzione del servizio come endpoint per i NEG del servizio.

¹Limite di 3000 nodi con pod di distribuzione. Nel cluster possono essere presenti più di 3000 nodi, ma GKE supporta la creazione di un massimo di 3000 endpoint quando crea bilanciatori del carico di rete passthrough esterni regionali basati su servizi di backend che utilizzano backend NEG GCE_VM_IP.

Limitazione per un singolo gruppo di istanze con bilanciamento del carico

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

Quando utilizzi backend di 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 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 ha l'annotazione networking.gke.io/load-balancer-type: "Internal", inviato a un cluster che esegue una versione GKE precedente alla 1.36, con il subsetting GKE disabilitato.
• Un bilanciatore del carico di rete passthrough esterno regionale basato su un servizio di backend creato per un servizio LoadBalancer esterno il cui manifest ha l'annotazione cloud.google.com/l4-rbs: "enabled", inviato a un cluster che esegue una versione GKE precedente alla 1.32.2-gke.1652000.
• Un bilanciatore del carico delle applicazioni esterno creato per un Ingress GKE esterno, utilizzando il controller Ingress GKE, ma non il bilanciamento del carico nativo del 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 regionali basati su servizi di backend e bilanciatori del carico delle applicazioni esterni creati per le risorse GKE Ingress 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 lo colleghi 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ù, consulta Raggruppamento dei nodi.
• Configura le risorse Ingress GKE esterne per utilizzare il bilanciamento del carico nativo del container. Per saperne di più, consulta Bilanciamento del carico nativo del container GKE.

Controlli di integrità dei bilanciatori 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 all'esterno del cluster ed è diverso da un probe di idoneità, attività o avvio di un pod.

I pacchetti di controllo di integrità del bilanciatore del carico ricevono una risposta dal software kube-proxy (nei cluster che non utilizzano GKE Dataplane V2) o dal software cilium-agent (nei cluster con GKE Dataplane V2) in esecuzione su ciascun nodo. I controlli di integrità del bilanciatore del carico per i servizi LoadBalancer non possono ricevere risposta dai pod.

Il valore 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 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 distribuzione, 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 distribuzione pronto e non in fase di terminazione, indipendentemente dallo stato di altri pod. I nodi senza un pod di gestione, i nodi i cui pod di gestione non superano tutti i probe di idoneità e i nodi i cui pod di gestione 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 vengono terminati. 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 di Kubernetes assegna la porta del controllo di integrità dall'intervallo di porte dei nodi, 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 le informazioni sull'integrità e sul peso per identificare l'insieme di backend dei nodi idonei. Per saperne di più, 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 Affinità di zona.

Controllo di integrità dei NEG rispetto ai MIG

Il tipo di backend utilizzato dal servizio LoadBalancer determina il modo in cui Google Cloud configura ed esegue i controlli di integrità del bilanciatore del carico:

• Suddivisione in sottoinsiemi GKE (backend NEG): quando il servizio utilizza i gruppi di endpoint di rete (NEG) GCE_VM_IP, ad esempio quando è abilitata la suddivisione in sottoinsiemi GKE, GKE configura i controlli di integrità di zona. Per i NEG a livello di zona, i probe di controllo di integrità hanno come target direttamente la porta del servizio.
• Configurazioni dei gruppi di istanze (backend MIG): quando il servizio utilizza gruppi di istanze gestite (MIG) come backend, GKE configura i controlli di integrità globali. Per i gruppi di istanze, i probe del controllo di integrità hanno come target l'nodePort allocata del servizio.

Risoluzione dei problemi relativi ai controllo di integrità non riusciti

Se i backend del bilanciatore del carico vengono segnalati come non integri (ad esempio, se viene visualizzato 0/X healthy nella console Google Cloud ), esamina le seguenti cause comuni:

• Regole firewall mancanti:i bilanciatori del carico Google Cloud richiedono regole firewall in entrata per consentire ai probe di controllo di integrità provenienti dagli intervalli di indirizzi IP di controllo di integrità di Google (come 130.211.0.0/22 e 35.191.0.0/16) di raggiungere i nodi del cluster. Se queste regole firewall vengono eliminate o modificate, i controlli di integrità non vanno a buon fine.
• Mancata corrispondenza della porta di destinazione del probe: tutte le regole di sicurezza di rete personalizzate o le configurazioni del firewall a livello di nodo devono tenere conto della porta di destinazione corretta del controllo di integrità. I probe hanno come target direttamente la porta del servizio per i backend NEG, ma hanno come target nodePort per i backend dei gruppi di istanze (MIG). Una mancata corrispondenza nella configurazione della porta prevista causa l'errore dei probe.
• Comportamento di externalTrafficPolicy: Local: se il servizio è configurato con l'impostazione externalTrafficPolicy: Local, i nodi che non ospitano un pod pronto e attivo per quel servizio non superano intenzionalmente il controllo di integrità del bilanciatore del carico. Se tutti i pod per il servizio non sono pronti o sono in fase di terminazione nel cluster, tutti i nodi di backend vengono segnalati come non integri (0/X healthy).

Intervalli di probe di controllo di integrità per i servizi LoadBalancer IPv6

I probe di controllo di integrità per i servizi LoadBalancer IPv6 provengono da intervalli di origine diversi rispetto ai probe IPv4. GKE crea regole firewall di autorizzazione in entrata per i seguenti intervalli di origine IPv6:

• 2600:2d00:1:b029::/64 per i bilanciatori del carico di rete passthrough interni.
• 2600:1901:8001::/48 per i bilanciatori del carico di rete passthrough esterni regionali.

Se gestisci le tue regole firewall, devi consentire il traffico in entrata da questi intervalli ai nodi del cluster, altrimenti i controlli di integrità per i servizi LoadBalancer IPv6 non andranno a buon fine.

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 passthrough

I bilanciatori del carico di rete passthrough instradano i pacchetti all'interfaccia nic0 dei nodi del cluster GKE. Ogni pacchetto con bilanciamento 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 i seguenti elementi:
  • 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

Destination Network Address Translation sui nodi

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

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

Source Network Address Translation e routing sui nodi

La tabella seguente mostra la relazione tra externalTrafficPolicy e se il nodo che ha ricevuto i pacchetti con bilanciamento del carico esegue la Network Address Translation (SNAT) di origine prima di inviare i pacchetti con bilanciamento del carico a un pod:

externalTrafficPolicy	Comportamento SNAT
Cluster	Nei cluster GKE che non utilizzano GKE Dataplane V2, ogni nodo che ha ricevuto pacchetti con bilanciamento 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 con bilanciamento 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 instrada i pacchetti a un pod su un nodo diverso. Se il nodo che ha ricevuto i pacchetti con bilanciamento 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 con bilanciamento del carico li instrada esclusivamente a un pod locale e non modifica l'indirizzo IP di origine di questi pacchetti.

La tabella seguente mostra in che modo externalTrafficPolicy controlla il modo in cui i nodi instradano i pacchetti con bilanciamento del carico e i pacchetti di risposta:

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 attivo, pronto e non in fase di terminazione, il nodo indirizza i pacchetti a un altro nodo che ha un pod attivo, pronto e non in fase di terminazione. Se il nodo che ha ricevuto i pacchetti con bilanciamento del carico ha un pod in stato di pubblicazione, pronto e non in fase di terminazione, il nodo potrebbe instradare i pacchetti a: Un pod locale. Un nodo diverso che ha un pod in stato di pubblicazione, pronto e non in fase di terminazione. Nei cluster a livello di regione, se il nodo che ha ricevuto i pacchetti con bilanciamento del carico 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à di zona è abilitata, il nodo che ha ricevuto i pacchetti con bilanciamento del carico tenta di instradarli a un nodo diverso nella stessa zona. Se non è possibile, il nodo diverso potrebbe trovarsi in qualsiasi zona. Come ultima risorsa, se non sono presenti pod in stato di pubblicazione, pronti e non in fase di terminazione per il servizio su tutti i nodi del cluster, si verifica quanto segue: Se l'opzione Proxy Terminating Endpoints è abilitata^1, il nodo che ha ricevuto i pacchetti con bilanciamento del carico li instrada a un pod in fase di terminazione, ma in servizio, se possibile. Se l'opzione Proxy Terminating Endpoints è disattivata o se non sono presenti pod nell'intero cluster, il nodo che ha ricevuto i pacchetti con bilanciamento del carico chiude la connessione con un reset TCP.	I pacchetti di risposta vengono sempre inviati da un nodo utilizzando Direct Server Return: Se il nodo con il pod di distribuzione non è il nodo che ha ricevuto i pacchetti con bilanciamento del carico corrispondenti, il nodo di distribuzione invia i pacchetti di risposta al nodo di ricezione. Il nodo di ricezione invia quindi i pacchetti di risposta utilizzando Direct Server Return. Se il nodo con il pod di distribuzione è quello che ha ricevuto i pacchetti con bilanciamento del carico, invia i pacchetti di risposta utilizzando Direct Server Return.
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 generalmente ha un pod in esecuzione, pronto e non in fase di terminazione (perché la presenza di un pod di questo tipo è necessaria 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 a livello di regione, l'affinità di zona non modifica il comportamento di base per il routing dei pacchetti con bilanciamento del carico. Come ultima risorsa, se non sono presenti pod in stato di pubblicazione, pronti e non in fase di terminazione per il servizio sul nodo che ha ricevuto i pacchetti con bilanciamento del carico, si verifica quanto segue: Se l'opzione Proxy Terminating Endpoints è abilitata^1, il nodo che ha ricevuto i pacchetti con bilanciamento del carico li indirizza a un pod di gestione locale, ma in fase di terminazione, se possibile. Se l'opzione Proxy Terminating Endpoints è disabilitata o il nodo che ha ricevuto i pacchetti con bilanciamento del carico non ha pod di distribuzione, il nodo chiude la connessione con un ripristino TCP.	Il nodo con il pod di distribuzione è sempre il nodo che ha ricevuto i pacchetti con bilanciamento del carico e quel nodo invia i pacchetti di risposta utilizzando Direct Server Return.

¹ Proxy Terminating Endpoints è abilitato in queste configurazioni:

• Cluster GKE che non utilizzano GKE Dataplane V2: GKE versione 1.26 e successive
• Cluster GKE che utilizzano GKE Dataplane V2: GKE versione 1.26.4-gke.500 e successive

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 regionali basati sui servizi di backend utilizzano la quota dei servizi di backend per progetto, la quota dei controlli di salute per progetto e la quota delle regole di forwarding dei bilanciatori del carico di rete passthrough esterni regionali per progetto.
• I bilanciatori del carico di rete passthrough esterni regionali 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 dei bilanciatori del carico di rete passthrough esterni regionali 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 i NEG autonomi.
• Scopri di più sull'API Gateway.