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 Kubernetes LoadBalancer. Descrive i diversi tipi di bilanciatori del carico e il modo in cui impostazioni come externalTrafficPolicy e l'impostazione secondaria di GKE per i bilanciatori del carico interni L4 determinano la configurazione dei bilanciatori del carico.
Prima di leggere questa pagina, è importante 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 dell'architettura di rete, utilizza il seguente albero decisionale per determinare quale servizio LoadBalancer scegliere per la configurazione di rete.
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 tuoi client si trovano nella stessa rete VPC o in una rete connessa alla rete del cluster (rete VPC), utilizza un servizio LoadBalancer interno. I servizi di bilanciamento del carico interni vengono implementati tramite 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
metadata.annotations[]del 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 tuoi client si trovano all'esterno della tua 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):
- (Consigliato) Crea un bilanciatore del carico di rete passthrough esterno basato su servizi di backend includendo quanto segue in
metadata.annotations[]del manifest:cloud.google.com/l4-rbs: "enabled" - Crea un bilanciatore del carico di rete passthrough esterno basato sul pool di destinazione omettendo l'annotazione
cloud.google.com/l4-rbs: "enabled".
- (Consigliato) Crea un bilanciatore del carico di rete passthrough esterno basato su servizi di backend includendo quanto segue in
Effetto di externalTrafficPolicy
Puoi impostare externalTrafficPolicy su Local o Cluster per definire in che modo i pacchetti vengono
instradati ai nodi con pod pronti e in uso. Quando definisci externalTrafficPolicy, considera i seguenti scenari:
Utilizza
externalTrafficPolicy: Localper conservare gli indirizzi IP client originali o se vuoi ridurre al minimo le interruzioni quando cambia il numero di nodi senza gestione dei pod nel cluster.Utilizza
externalTrafficPolicy: Clusterse il numero complessivo di nodi nel cluster senza gestire pod rimane coerente, ma il numero di nodi con pod di gestione cambia. Questa opzione non conserva gli indirizzi IP del client originali.
Per ulteriori informazioni su come externalTrafficPolicy influisce sul routing dei pacchetti all'interno dei nodi, consulta l'articolo sull'elaborazione dei pacchetti.
Creazione secondaria di GKE
L'opzione di configurazione dell'impostazione secondaria di GKE per i bilanciatori del carico interni L4 a livello di cluster, o l'impostazione secondaria di GKE, 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 secondaria di GKE abilitata. Ogni servizio ha due pod.
GKE crea un gruppo di endpoint di rete (NEG) GCE_VM_IP per ogni servizio. Gli endpoint in ogni NEG sono i nodi con i pod di gestione per il
relativo servizio.
Puoi abilitare l'impostazione secondaria di GKE quando crei un cluster o modificando un cluster esistente. Una volta abilitata, non puoi disabilitare l'impostazione secondaria di GKE. Per ulteriori informazioni, vedi Sottoimpostazione di GKE.
L'impostazione secondaria di GKE richiede:
- GKE versione 1.18.19-gke.1400 o successive e
- Componente aggiuntivo
HttpLoadBalancingabilitato per il cluster. Questo componente aggiuntivo è abilitato per impostazione predefinita. Consente al cluster di gestire i bilanciatori del carico che utilizzano i servizi di backend.
Considerazione del numero di nodi durante l'abilitazione della definizione secondaria di GKE
Come best practice, se devi creare servizi LoadBalancer interni, devi abilitare l'impostazione secondaria di GKE. La creazione 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 in totale nel cluster, i servizi LoadBalancer interni potrebbero riscontrare una distribuzione non uniforme del traffico o la perdita completa di connettività.
Se nel cluster è abilitata l'impostazione secondaria di GKE, puoi utilizzare
externalTrafficPolicy: LocaloexternalTrafficPolicy: 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 pubblicazione non sono pertinenti. Se hai bisogno di più di 250 nodi con almeno un pod di gestione, devi utilizzareexternalTrafficPolicy: Cluster.
I bilanciatori del carico di rete passthrough interni creati da GKE possono distribuire pacchetti solo su 250 o meno VM dei nodi di backend. Questa limitazione esiste perché GKE non utilizza la creazione di un sottoinsieme di backend del bilanciatore del carico e un bilanciatore del carico di rete passthrough interno può distribuire pacchetti a un massimo di 250 backend quando l'impostazione secondaria dei backend del bilanciatore del carico è disabilitata.
Raggruppamento dei nodi
Le annotazioni del manifest del servizio e, per il servizio LoadBalancer interno, lo stato dell'impostazione secondaria di GKE
determinano il bilanciatore del carico Google Cloud risultante 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 determinato nodo o indirizzo IP
del pod. Il tipo di bilanciatore del carico e backend determina il modo in cui i nodi vengono 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 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 dei nodi sono raggruppate a livello di zona in L'elemento |
| 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 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. L'elemento Gli stessi gruppi di istanze non gestite vengono utilizzati per altri servizi di backend del bilanciatore del carico creati nel cluster a causa della limitazione del singolo gruppo di istanze con bilanciamento del carico. |
Servizio LoadBalancer esterno con
l'annotazione cloud.google.com/l4-rbs: "enabled"2
|
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 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. L'elemento Gli stessi gruppi di istanze non gestite vengono utilizzati per altri servizi di backend del bilanciatore del carico creati nel cluster a causa della limitazione del singolo gruppo di istanze con bilanciamento del carico. |
Servizio LoadBalancer esterno senza l'annotazione cloud.google.com/l4-rbs: "enabled"3
|
Un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione il cui pool di destinazione contiene tutti i nodi del cluster | Il pool di destinazione è un'API legacy che non si basa su gruppi di istanze. Tutti i nodi hanno appartenenza diretta al pool di destinazione. L'elemento |
1 Solo i bilanciatori del carico di rete passthrough interni creati dopo aver abilitato l'impostazione secondaria di GKE utilizzano GCE_VM_IP NEG. Tutti
i servizi LoadBalancer interni creati prima di abilitare l'impostazione secondaria di GKE continuano a utilizzare i backend di gruppi di istanze non gestite. Per esempi e indicazioni sulla configurazione, consulta Creazione di servizi LoadBalancer interni.
2GKE non esegue automaticamente la migrazione dei servizi LoadBalancer esterni esistenti dai bilanciatori del carico di rete passthrough esterni basati su pool di destinazione ai bilanciatori del carico di rete passthrough esterni basati sul servizio di backend. Per creare un servizio LoadBalancer
esterno basato su un bilanciatore del carico di rete passthrough esterno basato sul servizio di backend, devi
includere l'annotazione cloud.google.com/l4-rbs: "enabled" nel
manifest del servizio al momento della creazione.
3La rimozione dell'annotazione cloud.google.com/l4-rbs: "enabled"
da un servizio LoadBalancer esterno esistente basato su un bilanciatore del carico di rete passthrough esterno basato sul servizio di backend non fa sì che GKE crei 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 dei nodi in GCE_VM_IP backend NEG
Quando è abilitata l'impostazione secondaria di GKE 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. Il externalTrafficPolicy del servizio e il numero di nodi nel cluster determinano quali nodi vengono aggiunti come endpoint ai NEG GCE_VM_IP del servizio.
Il piano di controllo del cluster aggiunge nodi come endpoint ai NEG GCE_VM_IP in base al valore externalTrafficPolicy del servizio e al numero di nodi nel cluster, come riepilogato nella tabella seguente.
externalTrafficPolicy |
Numero di nodi nel cluster | Appartenenza a 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 un massimo di 25 nodi come endpoint per i NEG del servizio, anche se un nodo non contiene un pod di gestione per il servizio. |
Local |
qualsiasi numero di nodi1 | GKE utilizza solo nodi che hanno almeno uno dei pod di servizio del servizio come endpoint per i NEG del servizio. |
1Limitato 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 su 250 VM di backend solo quando l'impostazione secondaria del bilanciatore del carico di rete passthrough interno è disabilitata. Anche con l'impostazione secondaria di GKE abilitata, GKE non configura mai i bilanciatori del carico di rete passthrough interni con la configurazione del 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 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 backend di gruppi di istanze non gestite, GKE crea o aggiorna gruppi di istanze non gestite contenenti tutti i nodi di tutti i pool di nodi in ciascuna zona utilizzata dal cluster. Questi gruppi di istanze non gestite vengono utilizzati per:
- Bilanciatori del carico di rete passthrough interni creati per i servizi LoadBalancer interni quando l'impostazione secondaria di GKE è disabilitata.
- Bilanciatori del carico di rete passthrough esterni basati sul servizio di backend creati per i servizi LoadBalancer esterni con l'annotazione
cloud.google.com/l4-rbs: "enabled". - Bilanciatori del carico delle applicazioni esterni creati per 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 sul servizio 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 su 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, puoi creare un gruppo di istanze non gestite personalizzato contenente alcuni o tutti i nodi del cluster, quindi collegarlo a un servizio di backend per un bilanciatore del carico.
Per aggirare questa limitazione, puoi indicare a GKE di utilizzare i backend NEG ove possibile:
- Abilita l'impostazione secondaria di GKE. Di conseguenza, i nuovi servizi LoadBalancer interni utilizzano invece
GCE_VM_IPNEG. - Configura risorse GKE Ingress esterne per usare il bilanciamento del carico nativo del container. Per ulteriori informazioni, consulta Bilanciamento del carico nativo del container di GKE.
Controlli di integrità del bilanciatore del carico
Tutti i servizi LoadBalancer GKE richiedono un controllo di integrità del bilanciatore del carico. Il controllo di integrità del bilanciatore del carico è implementato al di fuori del cluster ed è diverso da un probe di idoneità o di attività.
L'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 nuove connessioni TCP
ai nodi.
Nella tabella seguente viene descritto il comportamento del controllo di integrità:
externalTrafficPolicy |
Quali nodi superano il controllo di integrità | Porta utilizzata |
|---|---|---|
Cluster |
Tutti i nodi del cluster superano il controllo di integrità anche se non hanno pod in gestione. Se su un nodo sono presenti uno o più pod in uso, questo supera il controllo di integrità del bilanciatore del carico anche se i pod in uso sono in fase di arresto 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 personalizzato. |
Local |
Solo i nodi con almeno un pod di servizio pronto e non terminante 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 tutti i probe di idoneità e i nodi i cui pod di gestione stanno per terminare 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 fino a quando non viene raggiunta la soglia di stato non integro. Lo stato di transizione si verifica quando tutti i pod di gestione su un nodo iniziano a non superare i probe di idoneità o quando tutti i pod in uso su un nodo vengono arrestati. 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. |
La porta per il controllo di integrità è la porta TCP 10256, a meno che non specifichi una porta personalizzata per il controllo di integrità. |
Elaborazione dei pacchetti
Le seguenti sezioni descrivono nel 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 entrambe le seguenti condizioni:
- 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
- un protocollo e una porta specificati in
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 GKE Dataplane V2 è abilitato, i nodi usano 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 azioni seguenti:
- Il nodo esegue la Translation Network Address Translation (DNAT) di destinazione sul pacchetto, impostando l'indirizzo IP di destinazione su un indirizzo IP del pod di gestione.
- Il nodo cambia la porta di destinazione del pacchetto nel valore
targetPortdell'elementospec.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 (SNAT) di origine, nonché il percorso seguito dal pacchetto dal nodo al pod:
externalTrafficPolicy |
Comportamento SNAT del nodo | Comportamento percorso |
|---|---|---|
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 lo ha ricevuto dal bilanciatore del carico. | Il nodo instrada i pacchetti a qualsiasi pod di gestione. Il pod di gestione potrebbe trovarsi o meno sullo stesso nodo. Se il nodo che riceve i pacchetti dal bilanciatore del carico non dispone di un pod pronto e distribuito, il nodo instrada i pacchetti a un nodo diverso che contiene un pod pronto e gestito. I pacchetti di risposta del pod vengono instradati dal nodo di nuovo 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 cambia 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. Questo nodo invia i pacchetti di risposta al client originale utilizzando Direct Server Return. Questo è l'intento principale di questo tipo di criterio di traffico. In alcune situazioni, un nodo riceve pacchetti dal bilanciatore del carico
anche se manca un pod di gestione pronto e non terminante per
il servizio. Questa situazione si verifica quando il controllo di integrità del bilanciatore del carico non ha ancora raggiunto la soglia di errore, ma un pod precedentemente pronto e in uso non è più pronto o è in fase di arresto (ad esempio, durante l'esecuzione di un aggiornamento in sequenza). Il modo in cui i pacchetti vengono elaborati in questa situazione dipende dalla versione di GKE, dall'uso o meno di GKE Dataplane V2 da parte del cluster e dal valore di
|
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 utilizzando il Calcolatore prezzi di Google Cloud.
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 dei servizi di backend per progetto, la quota dei controlli di integrità per progetto e le regole di forwarding del bilanciatore del carico di rete passthrough interno per quota di rete Virtual Private Cloud.
- I bilanciatori del carico di rete passthrough esterni basati sul servizio di backend utilizzano la quota dei servizi di backend per progetto, la quota dei controlli di integrità per progetto e la quota delle regole di forwarding del bilanciatore del carico di rete passthrough esterno per progetto.
- I bilanciatori del carico di rete passthrough esterni basati su pool di destinazione utilizzano la quota dei pool di destinazione per progetto, la quota dei controlli di integrità per progetto e la quota delle regole di forwarding del bilanciatore del carico di rete passthrough esterno per progetto.
Passaggi successivi
- Parametri del servizio GKE LoadBalancer.
- Servizi Kubernetes.
- Parametri del servizio GKE LoadBalancer.