Questa pagina fornisce una panoramica generale di come Google Kubernetes Engine (GKE) crea e gestisce i bilanciatori del carico di Google Cloud quando applichi un manifest Kubernetes LoadBalancer Services. Descrive i diversi tipi di bilanciatori del carico e come le impostazioni come externalTrafficPolicy e il sottoinsieme GKE per i bilanciatori del carico interni L4 determinano la loro configurazione.
Prima di leggere questa pagina, assicurati di conoscere i concetti di networking di GKE.
Panoramica
Quando crei un servizio LoadBalancer, GKE configura un bilanciatore del carico passthrough 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 la classe 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 dal bilanciatore del carico.
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 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 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 un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione 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 il modo in cui i pacchetti vengono indirizzati ai nodi con pod pronti e in servizio. Quando definisci externalTrafficPolicy, considera i seguenti scenari:
Utilizza
externalTrafficPolicy: Localper preservare gli indirizzi IP dei client originali o se vuoi ridurre al minimo le interruzioni quando cambia il numero di nodi senza pod in servizio nel cluster.Utilizza
externalTrafficPolicy: Clusterse il numero complessivo di nodi senza pod di servizio nel cluster rimane invariato, ma il numero di nodi con pod di servizio cambia. 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.
Sottoinsieme 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 GCE_VM_IP gruppo di endpoint di rete (NEG) per ogni servizio. Gli endpoint in ogni NEG sono i nodi con i pod di servizio per il rispettivo servizio.
Puoi abilitare l'impostazione secondaria di GKE quando crei un cluster oppure modificare un cluster esistente. Una volta attivato, non puoi disattivare il sottoinsieme GKE. Per ulteriori informazioni, consulta la sezione Subsetting GKE.
L'impostazione secondaria di GKE richiede:
- GKE versione 1.18.19-gke.1400 o successive e
- Il componente aggiuntivo
HttpLoadBalancingabilitato per il cluster. Questo componente aggiuntivo è attivo per impostazione predefinita. Consente al cluster di gestire i bilanciatori del carico che utilizzano i servizi di backend.
Considerazioni sul numero di nodi quando si attiva il sottoinsieme 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 è disabilitato il sottoinsieme 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 registrare una distribuzione non uniforme del traffico o una perdita completa della connettività.
Se nel tuo cluster è abilitato il sottoinsieme GKE, puoi utilizzare
externalTrafficPolicy: LocaloexternalTrafficPolicy: Cluster, a condizione che il numero di nodi univoci con almeno un pod in esecuzione non sia superiore a 250. I nodi senza pod di pubblicazione non sono pertinenti. Se hai bisogno di più di 250 nodi con almeno un pod di pubblicazione, devi utilizzareexternalTrafficPolicy: 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 il sottoinsieme di backend del bilanciatore del carico e un bilanciatore del carico di rete passthrough interno è limitato a distribuire i pacchetti a un massimo di 250 backend quando il sottoinsieme di backend del bilanciatore del carico è disabilitato.
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 pass-through 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 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 dei nodi sono raggruppate in base alla 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 backend di gruppi di istanze non gestiti 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. Il 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 con l'annotazionecloud.google.com/l4-rbs: "enabled"2
|
Un bilanciatore del carico di rete passthrough esterno basato su servizio di backend il cui servizio di backend utilizza i backend di gruppi di istanze non gestiti a livello di zona | Tutte le VM dei nodi vengono inserite in gruppi di istanze non gestite a livello di zona che GKE utilizza come backend per il servizio di backend del bilanciatore del carico di rete passthrough esterno. Il 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 precedente che non si basa su gruppi di istanze. Tutti i nodi fanno parte direttamente del pool di destinazione. Il |
1 Solo i bilanciatori del carico di rete passthrough interni creati dopo l'attivazione dell'impostazione secondaria GKE utilizzano i NEG GCE_VM_IP. 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
con i servizi LoadBalancer interni.
2 GKE 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 su servizi di backend. Per creare un servizio LoadBalancer esterno basato su un bilanciatore del carico di rete passthrough esterno basato su un servizio di backend, devi includere l'annotazione cloud.google.com/l4-rbs: "enabled" nel 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. Il externalTrafficPolicy del servizio e il numero di nodi nel cluster determinano quali nodi vengono aggiunti come endpoint ai GCE_VM_IP NEG 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 i NEG del servizio, anche se un nodo non contiene un pod di pubblicazione 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 |
Un numero qualsiasi 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. |
1Limite di 250 nodi con pod di servizio per i servizi LoadBalancer interni. Nel cluster possono essere presenti più di 250 nodi, ma i bilanciatori del carico di rete passthrough interni si distribuiscono solo a 250 VM di backend quando il sottoinsieme di backend del bilanciatore del carico di rete passthrough interno è disattivato. Anche con l'impostazione secondaria GKE abilitata, GKE non configura mai bilanciatori del carico di rete passthrough interni con impostazione secondaria del backend del bilanciatore del carico di rete passthrough interno. Per maggiori dettagli consulta la sezione 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ù gruppi di istanze bilanciate in base al carico. I nodi GKE sono soggetti a questo di blocco.
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 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 il LoadBalancer esterno
Servizi con l'annotazione
cloud.google.com/l4-rbs: "enabled". - Application Load Balancer esterni creati per le risorse GKE Ingress esterne, utilizzando il controller GKE Ingress, ma senza utilizzare il bilanciamento del carico nativo dei container.
Poiché le VM di nodi non possono essere membri di più di un gruppo di istanze con bilanciamento del carico, GKE non può creare e gestire bilanciatori del carico di rete passthrough interni, bilanciatori del carico di rete passthrough esterni basati su servizi di backend e bilanciatori del carico delle applicazioni esterni creati per le risorse Ingress di GKE se una delle seguenti condizioni è vera:
- Al di fuori di GKE, hai creato almeno un 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.
- Al di fuori di GKE, crea un gruppo di istanze non gestite personalizzato che contenga alcuni o tutti i nodi del cluster, quindi collegalo a un servizio di backend per un bilanciatore del carico.
Per ovviare a questa limitazione, puoi chiedere a GKE di utilizzare i backend NEG, se possibile:
- Abilita l'impostazione secondaria di GKE. Di conseguenza, i nuovi servizi LoadBalancer interni utilizzano invece i
GCE_VM_IPNEG. - Configura le risorse GKE Ingress esterne per utilizzare il bilanciamento del carico nativo dei contenitori. 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 funzionamento del controllo di integrità del bilanciatore del carico. 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
i 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 il nodo non ha pod in esecuzione. Se su un nodo esistono 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 del 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. I nodi senza un pod di servizio, i nodi i cui pod di servizio non superano tutti i probe di idoneità e i nodi i cui pod di servizio 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 finché non viene raggiunta la soglia di non integrità 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 bilanciato in base al carico ricevuto da un nodo presenta le seguenti caratteristiche:
- L'indirizzo IP di destinazione del pacchetto corrisponde all'indirizzo IP della regola di inoltro del bilanciatore del carico.
- Il protocollo e la porta di destinazione del pacchetto corrispondono a entrambi i seguenti:
- un protocollo e una porta specificati in
spec.ports[]del manifest del servizio - un protocollo e una porta configurati nella regola di inoltro 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 in cui GKE Dataplane V2 non è 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 Network Address Translation (DNAT) di destinazione sul pacchetto, impostando il relativo indirizzo IP di destinazione su un indirizzo IP del pod di pubblicazione.
- 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 Network Address Translation (SNAT) dell'origine, nonché 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 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 pubblicazione. Il servizio Il pod potrebbe trovarsi o meno sullo stesso nodo. Se il nodo che riceve i pacchetti dal bilanciatore del carico non ha un pod pronto e in esecuzione, inoltra i pacchetti a un altro nodo che contiene un pod pronto e in esecuzione. 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 modifica l'indirizzo IP di origine dei pacchetti con bilanciamento del carico. | Nella maggior parte dei casi, il nodo inoltra il pacchetto a un pod di pubblicazione in esecuzione sul nodo che ha ricevuto il pacchetto dal bilanciatore del carico. Questo nodo invia i pacchetti di risposta al client originale utilizzando il ritorno diretto del server. Questo è lo scopo principale di questo tipo di criterio sul 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). Il modo in cui i pacchetti vengono elaborati in questa situazione dipende dalla versione di GKE, dal fatto che il cluster utilizzi GKE Dataplane V2 e dal valore di
|
Prezzi e quote
I prezzi della 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 il calcolatore dei 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
- Scopri di più sui parametri del servizio GKE LoadBalancer.
- Scopri di più sui servizi Kubernetes.