Concetti del servizio LoadBalancer

Questa pagina fornisce una panoramica generale del modo in cui Google Kubernetes Engine (GKE) crea e gestisce i bilanciatori del carico Google Cloud quando applichi un manifest dei servizi Kubernetes LoadBalancer. Descrive i diversi tipi di bilanciatori del carico e il modo in cui impostazioni, come externalTrafficPolicy e l'impostazione dei sottoinsiemi di GKE per i bilanciatori del carico interni L4, determinano la modalità di configurazione dei bilanciatori del carico.

Prima di leggere questa pagina, dovresti acquisire familiarità con i concetti di networking di GKE.

Panoramica

Quando crei un servizio LoadBalancer, GKE configura un bilanciatore del carico passthrough di Google Cloud le cui caratteristiche dipendono dai parametri del manifest del servizio.

Scegli un servizio LoadBalancer

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

  • Il tipo di indirizzo IP del LoadBalancer. Il bilanciatore del carico può avere un indirizzo IP interno o esterno.
  • Il numero e il tipo di nodi supportati da LoadBalancer.

Dopo aver determinato i requisiti di architettura di rete, utilizza il seguente albero decisionale per determinare quale servizio LoadBalancer scegliere per la configurazione di rete.

Un servizio LoadBalancer in GKE può avere un indirizzo interno o esterno.
Figura: albero decisionale del servizio LoadBalancer

Bilanciamento del carico esterno e interno

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

  • Se i client si trovano nella stessa rete VPC o in una rete connessa alla rete VPC del cluster, utilizza un servizio LoadBalancer interno. I servizi LoadBalancer interni sono implementati utilizzando 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 al servizio utilizzando l'indirizzo IP del bilanciatore del carico.

    Per creare un servizio LoadBalancer interno, includi una delle seguenti annotazioni nel file metadata.annotations[] del file manifest del servizio:

    • networking.gke.io/load-balancer-type: "Internal" (GKE 1.17 e versioni successive)
    • cloud.google.com/load-balancer-type: "Internal" (versioni precedenti alla 1.17)

  • Se i client si trovano all'esterno della rete VPC, utilizza un servizio LoadBalancer esterno. Puoi utilizzare uno dei seguenti tipi di bilanciatori del carico di rete passthrough esterni accessibili su internet (incluse le VM Google Cloud con accesso a internet):

Effetto di externalTrafficPolicy

Puoi impostare externalTrafficPolicy su Local o Cluster per definire il modo in cui i pacchetti vengono instradati ai nodi con pod pronti e di gestione. Considera i seguenti scenari durante la definizione di externalTrafficPolicy:

  • Utilizza externalTrafficPolicy: Local per conservare gli indirizzi IP dei client originali o se vuoi ridurre al minimo le interruzioni quando cambia il numero di nodi senza gestire i pod nel cluster.

  • Utilizza externalTrafficPolicy: Cluster se il numero complessivo di nodi senza gestione dei pod nel tuo cluster rimane coerente, ma il numero di nodi con pod di gestione cambia. Questa opzione non conserva gli indirizzi IP dei client originali.

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

Creazione di sottoinsiemi GKE

L'opzione di configurazione a livello di cluster per l'impostazione di sottoinsiemi GKE per i bilanciatori del carico interni L4 migliora la scalabilità dei bilanciatori del carico di rete passthrough interni raggruppando in modo più efficiente gli endpoint dei nodi per i backend del bilanciatore del carico.

Il seguente diagramma mostra due servizi in un cluster di zona con tre nodi e l'impostazione di sottoinsiemi di GKE abilitata. Ogni servizio ha due pod. GKE crea un gruppo di endpoint di rete (NEG) GCE_VM_IP per ciascun servizio. Gli endpoint in ogni NEG sono i nodi con i pod di gestione per il servizio corrispondente.

Puoi abilitare l'impostazione di sottoinsiemi di GKE quando crei un cluster o modifichi un cluster esistente. Una volta abilitata, non puoi disabilitare l'impostazione secondaria di GKE. Per ulteriori informazioni, consulta la pagina relativa all'impostazione secondaria di GKE.

La creazione di sottoinsiemi di GKE richiede:

  • GKE versione 1.18.19-gke.1400 o 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 i servizi di backend.

Considerazione del conteggio dei nodi durante l'abilitazione dell'impostazione di sottoinsiemi di GKE

Come best practice, se hai bisogno di creare servizi LoadBalancer interni, devi abilitare l'impostazione di sottoinsiemi di GKE. L'impostazione di sottoinsiemi di GKE consente di supportare più nodi nel cluster:

  • Se nel cluster è disabilitata l'impostazione secondaria di GKE, non devi creare più di 250 nodi totali (tra tutti i pool di nodi). Se crei più di 250 nodi totali nel cluster, i servizi LoadBalancer interni potrebbero riscontrare una distribuzione non uniforme del traffico o una perdita completa di connettività.

  • Se nel cluster è abilitata l'impostazione di sottoinsiemi di GKE, puoi utilizzare externalTrafficPolicy: Local o externalTrafficPolicy: Cluster, a condizione che il numero di nodi univoci con almeno un pod di gestione non sia superiore a 250 nodi. I nodi senza pod di gestione non sono pertinenti. Se hai bisogno di più 250 nodi con almeno un pod di gestione, devi utilizzare externalTrafficPolicy: Cluster.

I bilanciatori del carico di rete passthrough interni creati da GKE possono distribuire pacchetti solo a un massimo di 250 VM dei nodi di backend. Questa limitazione esiste perché GKE non utilizza l'impostazione secondaria di backend del bilanciatore del carico e un bilanciatore del carico di rete passthrough interno può distribuire pacchetti a massimo 250 backend quando l'impostazione secondaria del backend del bilanciatore del carico è disabilitata.

Raggruppamento di nodi

Le annotazioni del manifest del servizio e, per il servizio LoadBalancer interno, lo stato dell'impostazione dei sottoinsiemi di GKE determinano il risultante bilanciatore del carico di Google Cloud e il tipo di backend. I backend per i bilanciatori del carico passthrough di Google Cloud identificano l'interfaccia di rete (NIC) del nodo GKE, non un particolare indirizzo IP del nodo o del pod. Il tipo di bilanciatore del carico e backend determina il modo in cui i nodi sono raggruppati in GCE_VM_IP NEG, gruppi di istanze o pool di destinazione.

Servizio LoadBalancer GKE Bilanciatore del carico Google 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 GCE_VM_IP backend di gruppi di endpoint di rete (NEG)

Le VM nodo sono raggruppate a livello di zona in GCE_VM_IP NEG in base al servizio, in base alla metrica externalTrafficPolicy del servizio e al numero di nodi nel cluster.

externalTrafficPolicy del servizio controlla anche quali nodi superano il controllo di integrità del bilanciatore del carico e l'elaborazione dei pacchetti.

Servizio LoadBalancer interno creato in un cluster con impostazione secondaria GKE disabilitata 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 sono 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.

L'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 dei gruppi di istanze con bilanciamento del carico.
Servizio LoadBalancer esterno con l'annotazione cloud.google.com/l4-rbs: "enabled"2 Un bilanciatore del carico di rete passthrough esterno basato sul servizio di backend il cui servizio di backend utilizza backend di gruppi di istanze non gestite a livello di zona

Tutte le VM dei nodi sono 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.

L'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 dei gruppi 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 sui gruppi di istanze. Tutti i nodi hanno l'appartenenza diretta al pool di destinazione.

L'externalTrafficPolicy del servizio controlla quali nodi superano il controllo di integrità del bilanciatore del carico e l'elaborazione dei pacchetti.

1 Solo i bilanciatori del carico di rete passthrough interni creati dopo l'abilitazione dell'impostazione secondaria di GKE utilizzano NEG GCE_VM_IP. Tutti i servizi LoadBalancer interni creati prima di abilitare l'impostazione secondaria di GKE continuano a utilizzare backend di gruppi di istanze non gestite. Per esempi e indicazioni sulla configurazione, consulta la pagina relativa alla creazione di servizi LoadBalancer interni.

2 GKE non esegue automaticamente la migrazione dei servizi di bilanciamento del carico esterni esistenti da bilanciatori del carico di rete passthrough esterni basati su pool di destinazione a bilanciatori del carico di rete passthrough esterni basati su servizio di backend. Per creare un servizio LoadBalancer esterno basato su un bilanciatore del carico di rete passthrough esterno basato su servizio di backend, devi includere l'annotazione cloud.google.com/l4-rbs: "enabled" nel manifest del servizio al momento della creazione.

3 Se rimuovi l'annotazione cloud.google.com/l4-rbs: "enabled" da un servizio LoadBalancer esterno esistente basato su un bilanciatore del carico di rete passthrough esterno basato su servizio di backend, GKE non crea un bilanciatore del carico di rete passthrough esterno basato sul pool di destinazione. Per creare un servizio LoadBalancer esterno basato su un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione, devi omettere l'annotazione cloud.google.com/l4-rbs: "enabled" dal manifest del servizio al momento della creazione.

Appartenenza ai nodi in GCE_VM_IP backend NEG

Quando l'impostazione di sottoinsiemi di GKE è abilitata per un cluster, GKE crea un NEG GCE_VM_IP univoco in ogni zona per ogni servizio LoadBalancer interno. A differenza dei gruppi di istanze, i nodi possono essere membri di più di un NEG GCE_VM_IP con bilanciamento del carico. externalTrafficPolicy del servizio e il numero di nodi nel cluster determinano quali nodi vengono aggiunti come endpoint ai NEG del servizio GCE_VM_IP.

Il piano di controllo del cluster aggiunge nodi come endpoint ai NEG GCE_VM_IP in base al valore del valore externalTrafficPolicy del servizio e al numero di nodi nel cluster, come riepilogato nella tabella seguente.

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

1 Limitato a 250 nodi con pod di gestione per i servizi LoadBalancer interni. Nel cluster possono essere presenti più di 250 nodi, ma i bilanciatori del carico di rete passthrough interni distribuiscono solo su 250 VM di backend quando l'impostazione secondaria di backend del bilanciatore del carico di rete passthrough interno è disabilitata. Anche se è abilitata l'impostazione di sottoinsiemi di rete GKE, GKE non configura mai bilanciatori del carico di rete passthrough interni con sottoinsiemi di backend del bilanciatore del carico di rete passthrough interno. Per maggiori dettagli su questo limite, consulta Numero massimo di istanze VM per servizio di backend interno.

Limitazione del singolo gruppo di istanze con bilanciamento del carico

L'API Compute Engine impedisce alle VM di far parte di più gruppi 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 vengono utilizzati per:

  • Bilanciatori del carico di rete passthrough interni creati per i servizi LoadBalancer interni quando la creazione di sottoinsiemi di GKE è disabilitata.
  • Bilanciatori del carico di rete passthrough esterni basati su servizi di backend creati per servizi di bilanciamento del carico esterni con l'annotazione cloud.google.com/l4-rbs: "enabled".
  • Bilanciatori del carico delle applicazioni esterni creati per le risorse GKE Ingress esterne, utilizzando il controller GKE Ingress, ma senza 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 esterni basati su servizi di backend e bilanciatori del carico delle applicazioni esterni creati per le risorse GKE Ingress se una delle seguenti condizioni è true:

  • Al di fuori di GKE, hai creato almeno un bilanciatore del carico basato sul servizio di backend e hai utilizzato i gruppi di istanze gestite del cluster come backend per il servizio di backend del bilanciatore del carico.
  • All'esterno di GKE, crei un gruppo di istanze non gestite personalizzato contenente alcuni o tutti i nodi del cluster, quindi lo colleghi a un servizio di backend per un bilanciatore del carico.

Per aggirare questa limitazione, puoi chiedere a GKE di utilizzare backend NEG se possibile:

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

Controlli di integrità del bilanciatore del carico

Tutti i servizi LoadBalancer di GKE richiedono un controllo di integrità del bilanciatore del carico. Il controllo di integrità del bilanciatore del carico viene implementato all'esterno del cluster ed è diverso da un probe di idoneità o di attività.

L'elemento externalTrafficPolicy del servizio definisce il funzionamento del controllo di integrità del bilanciatore del carico. In tutti i casi, i probe del controllo di integrità del bilanciatore del carico inviano pacchetti al software kube-proxy in esecuzione su ciascun nodo. Il controllo di integrità del bilanciatore del carico è un proxy per le informazioni raccolte da kube-proxy, ad esempio se un pod esiste, è in esecuzione e ha superato il probe di idoneità. I controlli di integrità per i servizi LoadBalancer non possono essere instradati ai pod di gestione. Il controllo di integrità del bilanciatore del carico è progettato per indirizzare le nuove connessioni TCP ai nodi.

La tabella seguente descrive il comportamento del controllo di integrità:

externalTrafficPolicy Quali nodi superano il controllo di integrità Quale porta viene utilizzata
Cluster Tutti i nodi del cluster superano il controllo di integrità anche se non hanno pod di gestione. Se su un nodo sono presenti uno o più pod di gestione, questo supera il controllo di integrità del bilanciatore del carico anche se i pod di gestione sono in fase di terminazione o non superano i probe di idoneità. La porta per il controllo di integrità del bilanciatore del carico deve essere la porta TCP 10256. Non può essere personalizzata.
Local

Solo i nodi con almeno un pod di gestione pronto e senza terminazione superano il controllo di integrità del bilanciatore del carico. I nodi senza un pod di gestione, i nodi i cui pod di gestione non superano i probe di idoneità, e quelli 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 bilanciatore del carico. Lo stato di transizione si verifica quando tutti i pod di gestione su un nodo iniziano a non superare i probe di idoneità o all'arresto di tutti i pod di gestione su un nodo. L'elaborazione del pacchetto in questa situazione dipende dalla versione di GKE. Per ulteriori dettagli, consulta la sezione successiva, Elaborazione dei pacchetti.

 La porta per il controllo di integrità è la porta TCP 10256, a meno che non specifichi una porta per il controllo di integrità personalizzata.

Elaborazione pacchetti

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

Bilanciamento del carico passthrough

Il bilanciatore del carico passthrough di Google Cloud instrada i pacchetti all'interfaccia nic0 dei nodi del cluster GKE. Ogni pacchetto con bilanciamento del carico ricevuto da 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:
    • un protocollo e una porta specificati in spec.ports[] del manifest del servizio
    • un protocollo e una porta configurati sulla regola di forwarding del bilanciatore del carico

Traduzione degli indirizzi di rete di destinazione sui nodi

Dopo che il nodo riceve il pacchetto, esegue un'ulteriore elaborazione dei pacchetti. Nei cluster GKE in cui non è abilitato 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 DNAT (Destination Network Address Translation) sul pacchetto, impostando l'indirizzo IP di destinazione su un indirizzo IP del pod di gestione.
  • Il nodo modifica la porta di destinazione del pacchetto impostandola su targetPort del spec.ports[] del servizio corrispondente.

Traduzione degli indirizzi di rete di origine sui nodi

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

externalTrafficPolicy Comportamento SNAT del nodo Comportamento di routing
Cluster Il nodo modifica l'indirizzo IP di origine dei pacchetti con bilanciamento del carico in modo che corrisponda all'indirizzo IP del nodo che li ha ricevuti dal bilanciatore del carico.

Il nodo instrada i pacchetti a qualsiasi pod di gestione. 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 per la gestione, instrada i pacchetti a un nodo diverso, che invece contiene un pod pronto per la gestione. I pacchetti di risposta dal pod vengono instradati dal relativo 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 instrada il pacchetto a un pod di gestione in esecuzione sul nodo che ha ricevuto il pacchetto dal bilanciatore del carico. Il nodo invia pacchetti di risposta al client originale utilizzando Direct Server Return. Questo è l'intento principale di questo tipo di criterio relativo al traffico.

In alcune situazioni, un nodo riceve pacchetti dal bilanciatore del carico, anche se non dispone di un pod di gestione pronto e senza terminazione 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 per la gestione non è più pronto o è in fase di arresto (ad esempio, durante un aggiornamento in sequenza). Il modo in cui i pacchetti vengono elaborati in questa situazione dipende dalla versione di GKE, dall'utilizzo o meno di GKE Dataplane V2 da parte del cluster 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, è abilitata l'opzione Endpoint di terminazione proxy. I pacchetti vengono instradati a un pod di arresto come ultima risorsa, se vengono soddisfatte tutte le seguenti condizioni:
    • Se tutti i pod di gestione sono in fase di arresto e externalTrafficPolicy è Cluster.
    • Se tutti i pod di gestione sul nodo sono in fase di arresto e externalTrafficPolicy è Local.
  • Per tutte le altre versioni di GKE, il pacchetto riceve una risposta dal kernel del nodo con un reset TCP.

Prezzi e quote

I prezzi di rete si applicano ai pacchetti elaborati da un bilanciatore del carico. Per ulteriori informazioni, consulta Prezzi di Cloud Load Balancing e delle regole di forwarding. Puoi anche stimare i costi di fatturazione con il Calcolatore prezzi di Google Cloud.

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

Passaggi successivi