Questa pagina fornisce una panoramica generale delle modalità con cui Google Kubernetes Engine (GKE) crea
e gestisce i bilanciatori del carico Google Cloud quando applichi un bilanciatore del carico Kubernetes
File manifest dei servizi. Descrive i diversi tipi di bilanciatori del carico e come
come externalTrafficPolicy e la creazione di sottoinsiemi di GKE per
I bilanciatori del carico interni L4 determinano il modo in cui sono configurati i bilanciatori del carico.
Prima di leggere questa pagina, è consigliabile acquisire familiarità con GKE concetti di networking.
Panoramica
Quando crei un bilanciatore del carico LoadBalancer assistenza, GKE configura un carico passthrough di Google Cloud di fatturazione il cui dipendono dai parametri del manifest del servizio.
Scegli un servizio LoadBalancer
Quando scegli la configurazione del servizio LoadBalancer da utilizzare, considera la classe i seguenti aspetti:
- Il tipo di indirizzo IP del LoadBalancer. Il bilanciatore del carico può avere interno o esterno.
- Il numero e il tipo di nodi supportati da LoadBalancer.
Dopo aver determinato i requisiti dell'architettura di rete, utilizza quanto segue albero decisionale per determinare quale servizio LoadBalancer scegliere per il tuo configurazione di rete.
Bilanciamento del carico esterno e interno
Quando crei un servizio LoadBalancer in GKE, devi specificare Indica 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 connesso al cluster (rete VPC), quindi servizio LoadBalancer interno. I servizi LoadBalancer interni vengono implementati utilizzando bilanciatori del carico di rete passthrough interni. I clienti che si trovano in nella stessa rete VPC o in una rete connessa Rete VPC può accedere al servizio utilizzando l'indirizzo IP del bilanciatore del carico.
Per creare un servizio LoadBalancer interno, includi uno dei seguenti elementi 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 a 1,17)
Se i tuoi client si trovano all'esterno della tua rete VPC, utilizza da un servizio LoadBalancer esterno. Puoi utilizzare uno dei seguenti tipi di bilanciatori del carico di rete passthrough esterni accessibili su internet (inclusi VM Google Cloud con accesso a internet):
- (Consigliato) Crea un servizio di backend
bilanciatore del carico di rete passthrough esterno
includendo quanto segue in
metadata.annotations[]del manifest:cloud.google.com/l4-rbs: "enabled" - Crea una campagna basata su pool di destinazione
bilanciatore del carico di rete passthrough esterno
omettendo l'annotazione
cloud.google.com/l4-rbs: "enabled".
- (Consigliato) Crea un servizio di backend
bilanciatore del carico di rete passthrough esterno
includendo quanto segue in
Effetto di externalTrafficPolicy
Puoi impostare externalTrafficPolicy su Local o Cluster per definire la modalità di visualizzazione dei pacchetti
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 senza di gestione dei pod nel tuo cluster rimane coerente, ma il numero di nodi gestire le modifiche ai pod. Questa opzione non conserva l'IP client originale indirizzi IP esterni.
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'impostazione secondaria di GKE per i bilanciatori del carico interni L4 a livello di cluster di configurazione, o sottoinsieme GKE, migliora la scalabilità di bilanciatori del carico di rete passthrough interni mediante il raggruppamento più efficiente degli endpoint dei nodi per il carico dei bilanciatori del carico.
Il seguente diagramma mostra due servizi in un cluster di zona con tre nodi
Creazione secondaria di GKE abilitata. Ogni servizio ha due pod.
GKE crea un gruppo di endpoint di rete (NEG) GCE_VM_IP per ciascun
assistenza. Gli endpoint in ogni NEG sono i nodi con i pod di gestione
rispettivo Servizio.
Puoi abilitare l'impostazione secondaria di GKE quando crei un cluster oppure modificare un cluster esistente. Una volta abilitato, non puoi disabilitare GKE la creazione di sottoinsiemi. Per ulteriori informazioni, consulta GKE creazione secondaria.
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 è sono abilitate per impostazione predefinita. Il cluster può gestire i bilanciatori del carico che utilizzano di backend.
Considerazione del numero di nodi durante l'abilitazione della definizione secondaria di GKE
Come best practice, se devi creare servizi LoadBalancer interni, abilitare l'impostazione secondaria di GKE. Creazione secondaria di GKE supporta più nodi nel tuo cluster:
Se nel cluster è disabilitata l'impostazione secondaria di GKE, non devi creano più di 250 nodi totali (tra tutti i pool di nodi). Se crei altri per un totale di 250 nodi nel cluster, i servizi LoadBalancer interni possono la distribuzione non uniforme del traffico o la completa perdita di connettività.
Se nel cluster è abilitata l'impostazione secondaria di GKE, puoi utilizzare
externalTrafficPolicy: LocaloexternalTrafficPolicy: Cluster, a condizione che il numero di nodi unici con almeno un pod di gestione non è superiore a e 250 nodi. I nodi senza pod di pubblicazione non sono pertinenti. Se hai bisogno di altro di oltre 250 nodi con almeno un pod di pubblicazione, devi usareexternalTrafficPolicy: Cluster.
I bilanciatori del carico di rete passthrough interni creati da GKE possono distribuire solo pacchetti Massimo 250 VM del nodo di backend. Questa limitazione esiste perché GKE non utilizza un bilanciatore del carico sottoinsiemi di backend e un il bilanciatore del carico di rete passthrough interno è limitato alla distribuzione di pacchetti a un massimo di 250 backend quando è disabilitata l'impostazione secondaria del backend del bilanciatore del carico.
Raggruppamento dei nodi
Le annotazioni del manifest del servizio e, per il servizio LoadBalancer interno, lo stato dell'impostazione secondaria di GKE
determinare il bilanciatore del carico di Google Cloud risultante e il tipo
di backend. I backend per i bilanciatori del carico passthrough di Google Cloud identificano
all'interfaccia di rete (NIC) del nodo GKE, non a un particolare nodo o 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 Creazione secondaria di 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 Il |
| Servizio LoadBalancer interno creato in un cluster con Creazione secondaria di GKE disabilitata | Un bilanciatore del carico di rete passthrough interno il cui servizio di backend utilizza il servizio di backend backend di gruppi di istanze non gestite | Tutte le VM del nodo sono inserite in gruppi di istanze non gestite a livello di zona, GKE utilizza come backend per il backend del bilanciatore del carico di rete passthrough interno completamente gestito di Google Cloud.
Gli stessi gruppi di istanze non gestite vengono utilizzati per altri carichi di backend del bilanciatore del carico creati nel cluster a causa singolo gruppo di istanze con bilanciamento del carico limitazione. |
il servizio LoadBalancer esterno con
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 a livello di zona backend di gruppi di istanze non gestite | Tutte le VM del nodo sono inserite in gruppi di istanze non gestite a livello di zona, GKE utilizza come backend per il backend del bilanciatore del carico di rete passthrough esterno completamente gestito di Google Cloud.
Gli stessi gruppi di istanze non gestite vengono utilizzati per altri carichi di backend del bilanciatore del carico creati nel cluster a causa singolo gruppo di istanze con bilanciamento del carico limitazione. |
Servizio LoadBalancer esterno senza il componente
Annotazione cloud.google.com/l4-rbs: "enabled"3
|
Un target bilanciatore del carico di rete passthrough esterno basato su pool il cui pool di destinazione contiene tutti i nodi il cluster | Il pool di destinazione è un'API legacy che non si basa sull'istanza gruppi. Tutti i nodi hanno appartenenza diretta al pool di destinazione.
|
1 Solo i bilanciatori del carico di rete passthrough interni creati dopo l'abilitazione
La creazione secondaria di GKE utilizza GCE_VM_IP NEG. Qualsiasi
servizi LoadBalancer interni creati prima di abilitare GKE
l'impostazione secondaria continua a utilizzare
i backend dei gruppi di istanze non gestite. Per esempi
e configurazione, consulta
Creazione in corso
e i servizi interni di bilanciamento del carico.
2GKE non esegue automaticamente la migrazione delle
servizi LoadBalancer esterni dai bilanciatori del carico di rete passthrough esterni basati su pool di destinazione
bilanciatori del carico di rete passthrough esterni basati su servizio di backend. Per creare un LoadBalancer esterno
Servizio basato su un bilanciatore del carico di rete passthrough esterno basato sul servizio di backend, devi
includi l'annotazione cloud.google.com/l4-rbs: "enabled" nella
manifest del servizio al momento della creazione.
3Rimozione del cloud.google.com/l4-rbs: "enabled"
da un servizio LoadBalancer esterno esistente basato su un backend
il bilanciatore del carico di rete passthrough esterno basato su servizio non fa sì che GKE crei un
il bilanciatore del carico di rete passthrough esterno basato su pool di destinazione. Per creare un LoadBalancer esterno
È necessario un servizio basato su un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione,
ometti 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 ciascuna zona per ciascun LoadBalancer interno
assistenza. A differenza dei gruppi di istanze, i nodi possono essere membri di più
GCE_VM_IP NEG con bilanciamento del carico. I externalTrafficPolicy del Servizio e
il numero di nodi nel cluster determina 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 del 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 del cluster come endpoint per NEG del servizio, anche se un nodo non contiene un pod di gestione per il Servizio. |
Cluster |
più di 25 nodi | GKE usa 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 |
qualsiasi numero di nodi1 | GKE utilizza solo nodi che hanno almeno uno dei I pod del servizio che utilizzano i pod come endpoint per i NEG del servizio. |
1Limitata a 250 nodi con pod di gestione per uso interno Servizi LoadBalancer. Il cluster può contenere più di 250 nodi, ma i bilanciatori del carico di rete passthrough interni si distribuiscono solo a 250 VM di backend bilanciatore del carico di rete passthrough interno backend l'impostazione secondaria sia disabilitata. Anche con l'impostazione secondaria di GKE abilitata, GKE non configura mai i bilanciatori del carico di rete passthrough interni con configurazione secondaria del backend del bilanciatore del carico di rete passthrough interno. Per maggiori dettagli come 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 di blocco.
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 L'impostazione secondaria di GKE è disabilitata.
- Bilanciatori del carico di rete passthrough esterni basati sul servizio di backend creati per LoadBalancer esterno
Servizi con l'annotazione
cloud.google.com/l4-rbs: "enabled". - Bilanciatori del carico delle applicazioni esterni creati per GKE Ingress esterno utilizzando il controller GKE Ingress, ma non utilizzando il bilanciamento del carico nativo del container.
Poiché le VM del nodo 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, backend bilanciatori del carico di rete passthrough esterni basati su servizi e bilanciatori del carico delle applicazioni esterni creati per Risorse GKE Ingress se una delle seguenti condizioni è true:
- Al di fuori di GKE, hai creato almeno un servizio di backend basato bilanciatore del carico 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 che contiene alcuni o tutti i nodi del cluster, quindi collega i nodi gruppo di istanze non gestite a un servizio di backend per un bilanciatore del carico.
Per aggirare questa limitazione, puoi indicare a GKE di utilizzare Backend NEG ove possibile:
- Abilita la creazione secondaria di GKE. Di conseguenza, le nuove
I servizi LoadBalancer utilizzano invece
GCE_VM_IPNEG. - Configura risorse GKE Ingress esterne per l'utilizzo del container il bilanciamento del carico nativo. Per ulteriori informazioni, consulta GKE caricamento nativo del container bilanciato.
Controlli di integrità del bilanciatore del carico
Tutti i servizi LoadBalancer GKE richiedono un integrità del bilanciatore del carico controllo. L'integrità del bilanciatore del carico controllo è implementato all'esterno del cluster ed è diverso da un livello di idoneità o il probe di attività.
Il externalTrafficPolicy del servizio definisce il modo in cui il bilanciatore del carico
controllo di integrità. In tutti i casi, i probe del controllo di integrità del bilanciatore del carico
di inviare pacchetti al software kube-proxy in esecuzione su ciascun nodo. Il carico
il controllo di integrità del bilanciatore è un proxy per le informazioni che kube-proxy
raccoglie dati, ad esempio se un pod esiste, è in esecuzione e ha superato l'idoneità
una sonda. I controlli di integrità per i servizi LoadBalancer non possono essere instradati alla pubblicazione
di pod. Il controllo di integrità del bilanciatore del carico è progettato per indirizzare nuovi modelli TCP
connessioni 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 sono e nessun pod in gestione. Se su un nodo sono presenti uno o più pod di gestione, supera il controllo di integrità del bilanciatore del carico anche se i pod di gestione sono in fase di terminazione o non soddisfano i probe di idoneità. | La porta per il controllo di integrità del bilanciatore del carico deve essere la porta TCP 10256. Non può possono essere personalizzati. |
Local |
Solo i nodi con almeno un pod di servizio pronto e non terminante il controllo di integrità del bilanciatore del carico. nodi senza un pod di gestione, nodi i cui pod di gestione non superano tutti i probe di idoneità e i nodi la cui i pod di gestione stanno terminando l'integrità del bilanciatore del carico verifica. Durante le transizioni di stato, un nodo passa comunque controllo di integrità fino a quando 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 o quando tutti i pod di gestione su un nodo sono in fase di arresto. Il modo in cui il pacchetto viene elaborato in questa situazione dipende dalla Versione GKE. Per ulteriori dettagli, consulta Elaborazione dei pacchetti. |
La porta per il controllo di integrità sia la porta TCP 10256, a meno che specificare una porta personalizzata per il controllo di integrità. |
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
Il bilanciatore del carico passthrough di Google Cloud instrada i pacchetti a nic0
dei nodi del cluster GKE. Ogni pacchetto con bilanciamento del carico
ricevute da un nodo ha le seguenti caratteristiche:
- L'indirizzo IP di destinazione del pacchetto corrisponde all'inoltro del bilanciatore del carico dell'indirizzo IP della regola.
- 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
- 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 pacchetto aggiuntivo
e l'elaborazione dei dati. Nei cluster GKE senza GKE Dataplane V2 abilitato,
i nodi utilizzano iptables per elaborare i pacchetti con bilanciamento del carico. In GKE
cluster con GKE Dataplane V2
abilitato, i nodi utilizzano
eBPF. Il pacchetto a livello di nodo
l'elaborazione include sempre le seguenti azioni:
- Il nodo esegue la DNAT (Destination Network Address Translation) di fatturazione, 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
targetPortdelspec.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 SNAT (Network Address Translation) di origine, nonché il percorso
di un 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 corrisponda all'indirizzo IP del nodo che lo ha ricevuto dal carico con il bilanciatore del carico di rete passthrough esterno regionale. | Il nodo instrada i pacchetti a qualsiasi pod di gestione. Il servizio Il pod potrebbe trovarsi o meno sullo stesso nodo. Se il nodo che riceve i pacchetti dal bilanciatore del carico manca pronto e in uso, il nodo instrada i pacchetti a un che contiene un pod pronto e in uso. Pacchetti di risposta vengono instradate dal pod al nodo che ha ricevuto i pacchetti di richiesta dal bilanciatore del carico. Il primo nodo quindi invia i pacchetti di risposta al client originale utilizzando Restituzione al server. |
Local |
Il nodo non cambia l'indirizzo IP di origine di e pacchetti con bilanciamento del carico. | Nella maggior parte delle situazioni, 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 i pacchetti di risposta al client originale utilizzando le Restituzione al server. Questo è l'intento principale di questo tipo di traffico . In alcune situazioni, un nodo riceve pacchetti dal bilanciatore del carico
anche se il nodo non dispone di un pod di servizio pronto e non terminante
il Servizio. Questa situazione si verifica quando il bilanciatore del carico
controllo di integrità non ha ancora raggiunto la soglia di errore, ma in precedenza era
il pod kubectl non è più pronto o è in fase di arresto (ad esempio,
durante un aggiornamento in sequenza). Come vengono elaborati i pacchetti
dipende dalla versione di GKE, se il cluster utilizza
GKE Dataplane V2 e il valore di
|
Prezzi e quote
I prezzi di rete si applicano ai pacchetti elaborati da un bilanciatore del carico. Per maggiori informazioni le informazioni, vedi Prezzi di Cloud Load Balancing e delle regole di forwarding. Puoi anche stimare gli addebiti di fatturazione utilizzando con il Calcolatore prezzi di Google Cloud.
Il numero di regole di forwarding che puoi creare è controllato dal bilanciatore del carico quote:
- I bilanciatori del carico di rete passthrough interni utilizzano quota dei servizi di backend per progetto, la quota dei controlli di integrità per progetto Regole di forwarding del bilanciatore del carico di rete passthrough interno per quota di rete del virtual private cloud.
- I bilanciatori del carico di rete passthrough esterni basati sul servizio di backend utilizzano quota dei servizi di backend per progetto, la quota dei controlli di integrità per progetto e la quota quota delle regole di forwarding del bilanciatore del carico di rete passthrough esterno.
- I bilanciatori del carico di rete passthrough esterni basati su pool di destinazione utilizzano quota di pool di destinazione per progetto, la quota dei controlli di integrità per progetto e la quota quota delle regole di forwarding del bilanciatore del carico di rete passthrough esterno.
Passaggi successivi
- Parametri del servizio GKE LoadBalancer.
- Servizi Kubernetes.
- Parametri del servizio GKE LoadBalancer.