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.
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):
- (Consigliato) Crea un bilanciatore del carico di rete passthrough esterno basato sul servizio di backend includendo quanto segue in
metadata.annotations[]
del manifest:cloud.google.com/l4-rbs: "enabled"
- (Consigliato) Crea un bilanciatore del carico di rete passthrough esterno basato sul servizio di backend includendo quanto segue in
- Crea un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione omettendo l'annotazione
cloud.google.com/l4-rbs: "enabled"
.
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
oexternalTrafficPolicy: 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 utilizzareexternalTrafficPolicy: 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
|
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' 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' 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' |
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
- 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 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
delspec.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
|
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:
- 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 su servizi di backend 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 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 di servizio di GKE LoadBalancer.
- Servizi Kubernetes.
- Parametri di servizio di GKE LoadBalancer.