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 tipi di LoadBalancer, i parametri di configurazione e fornisce consigli sulle best practice.
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 pass-through Google Cloud le cui caratteristiche dipendono dai parametri del manifest del servizio.
Personalizzare il servizio LoadBalancer per una rete
Quando scegli la configurazione del servizio LoadBalancer da utilizzare, prendi in considerazione i seguenti aspetti:
- Tipo di bilanciatore del carico: interno o esterno
- Norme sul traffico esterno
- Bilanciamento del carico ponderato
Tipo di bilanciatore del carico: interno o esterno
Quando crei un servizio LoadBalancer in GKE, specifica se il bilanciatore del carico ha un indirizzo interno o esterno:
I servizi LoadBalancer esterni vengono implementati utilizzando bilanciatori del carico di rete passthrough esterni. I client esterni alla rete VPC e le VM Google Cloud con accesso a internet possono accedere a un servizio LoadBalancer esterno.
Quando crei un servizio LoadBalancer e non specifichi impostazioni personalizzate, viene applicata per impostazione predefinita questa configurazione.
Come best practice, quando crei un servizio LoadBalancer esterno, includi l'annotazione
cloud.google.com/l4-rbs: "enabled"nel manifest del servizio. L'inclusione di questa annotazione nel manifest del servizio crea un bilanciatore del carico di rete passthrough esterno basato su un servizio di backend.I manifest del servizio LoadBalancer che omettono l'annotazione
cloud.google.com/l4-rbs: "enabled"creano un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione. L'utilizzo di bilanciatori del carico di rete passthrough esterni basati su pool di destinazione non è più consigliato.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 a un servizio LoadBalancer interno.
Per creare un servizio LoadBalancer interno:
Come best practice, assicurati che il sottoinsieme GKE sia abilitato in modo che GKE possa raggruppare in modo efficiente i nodi utilizzando i
GCE_VM_IPgruppi di endpoint di rete (NEG). La sottosezione GKE non è obbligatoria, ma è vivamente consigliata.Includi l'annotazione
networking.gke.io/load-balancer-type: "Internal"nel manifest del servizio.
Effetto di externalTrafficPolicy
Il parametro externalTrafficPolicy controlla quanto segue:
- Quali nodi ricevono i pacchetti dal bilanciatore del carico
- Indica se i pacchetti possono essere instradati tra i nodi del cluster dopo che il bilanciatore del carico li ha inviati a un nodo
- Indica se l'indirizzo IP del client originale viene conservato o perso
externalTrafficPolicy può essere Local o Cluster:
Utilizza
externalTrafficPolicy: Localper assicurarti che i pacchetti vengano soltanto recapitati a un nodo con almeno un pod di servizio pronto e non finale, preservando l'indirizzo IP di origine del client originale. Questa opzione è ideale per i carichi di lavoro con un numero relativamente costante di nodi con pod di servizio, anche se il numero complessivo di nodi nel cluster varia. Questa opzione è obbligatoria per supportare il bilanciamento del carico ponderato.Utilizza
externalTrafficPolicy: Clusterin situazioni in cui il numero complessivo di nodi nel cluster è relativamente costante, ma il numero di nodi con pod in servizio varia. Questa opzione non conserva gli indirizzi IP di origine del client originale e può aggiungere latenza perché i pacchetti potrebbero essere instradati a un pod di servizio su un altro nodo dopo essere stati inviati a un nodo dal bilanciatore del carico. Questa opzione non è compatibile con il bilanciamento del carico ponderato.
Per ulteriori informazioni su come externalTrafficPolicy influisce sul routing dei pacchetti
all'interno dei nodi, consulta Elaborazione dei pacchetti.
Bilanciamento del carico ponderato
I servizi LoadBalancer esterni supportano il bilanciamento del carico ponderato, che consente ai nodi con più pod di servizio di ricevere una proporzione maggiore di nuove connessioni rispetto ai nodi con meno pod di servizio.
Per utilizzare il bilanciamento del carico ponderato, devi soddisfare tutti i seguenti requisiti:
Il cluster GKE deve utilizzare la versione 1.31.0-gke.1506000 o successive.
Il componente aggiuntivo
HttpLoadBalancingdeve essere abilitato 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.Devi includere l'annotazione
cloud.google.com/l4-rbs: "enabled"nel manifest del servizio LoadBalancer in modo che GKE crei un bilanciatore del carico di rete passthrough esterno basato su servizio di backend. I bilanciatori del carico di rete passthrough esterni basati su pool di destinazione non supportano il bilanciamento del carico ponderato.Per attivare la funzionalità di bilanciamento del carico ponderato, devi includere l'annotazione
networking.gke.io/weighted-load-balancing: pods-per-nodenel manifest del servizio LoadBalancer.Il manifest del servizio LoadBalancer deve utilizzare
externalTrafficPolicy: Local. GKE non ti impedisce di utilizzareexternalTrafficPolicy: Cluster, maexternalTrafficPolicy: Clusterdisattiva efficacemente il bilanciamento del carico ponderato perché il pacchetto potrebbe essere indirizzato, dopo il bilanciatore del carico, a un nodo diverso.
Per ulteriori informazioni sul bilanciamento del carico ponderato dal punto di vista del bilanciatore del carico, consulta Bilanciamento del carico ponderato nel bilanciatore del carico di rete passthrough esterno basato sul servizio di backend.
Considerazioni speciali per i servizi LoadBalancer interni
Questa sezione descrive l'opzione di sottoinsieme GKE, che è unica per i servizi LoadBalancer interni, e come il sottoinsieme GKE interagisce con externalTrafficPolicy per influenzare il numero massimo di nodi bilanciati in base al carico.
Sottoinsieme GKE
Attiva l'impostazione secondaria GKE per migliorare la scalabilità dei servizi LoadBalancer interni.
L'impostazione secondaria GKE, chiamata anche impostazione secondaria GKE per i bilanciatori del carico di rete interni di livello 4, è un'opzione di configurazione a livello di cluster che migliora la scalabilità dei bilanciatori del carico di rete passthrough interni raggruppando in modo più efficiente gli endpoint dei nodi in GCE_VM_IP gruppi di endpoint di rete (NEG). I NEG vengono utilizzati come
i backend del bilanciatore del carico.
Il seguente diagramma mostra due servizi in un cluster zonale con tre nodi.
Il cluster ha l'impostazione secondaria GKE abilitata. Ogni servizio ha due
Pod. GKE crea un GCE_VM_IP NEG per ogni servizio. Gli endpoint
in ogni NEG sono i nodi con i pod di servizio per il rispettivo servizio.
Puoi attivare l'impostazione secondaria di GKE quando crei un cluster o aggiornatene uno esistente. Una volta attivato, non puoi disattivare il sottoinsieme GKE. L'impostazione secondaria 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.
Conteggio nodi
Un cluster con l'impostazione secondaria GKE disattivata può riscontrare problemi con i servizi LoadBalancer interni se il cluster ha più di 250 nodi totali (tra tutti i pool di nodi). Questo accade perché i bilanciatori del carico di rete passthrough interni creati da GKE possono distribuire i pacchetti solo a un massimo di 250 VM dei nodi di backend. Questa limitazione esiste per i seguenti due motivi:
- GKE non utilizza il sottoinsieme del backend del bilanciatore del carico.
- Un bilanciatore del carico di rete passthrough interno è limitato alla distribuzione dei pacchetti a un massimo di 250 backend quando l'impostazione secondaria del backend del bilanciatore del carico è disattivata.
Un cluster con sottoinsieme GKE supporta i servizi LoadBalancer interni nei cluster con più di 250 nodi totali.
Un servizio LoadBalancer interno che utilizza
externalTrafficPolicy: Localin un cluster in cui è abilitata l'impostazione secondaria GKE supporta fino a 250 nodi con pod di servizio che supportano questo servizio.Un servizio LoadBalancer interno che utilizza
externalTrafficPolicy: Clusterin un cluster in cui è abilitato il sottoinsieme GKE non impone alcuna limitazione al numero di nodi con pod di servizio, perché GKE configura non più di 25 endpoint di nodo neiGCE_VM_IPNEG. Per ulteriori informazioni, vedi Adesione dei nodi ai backendGCE_VM_IPNEG.
Raggruppamento dei nodi
Le annotazioni del manifest del servizio e, per il servizio LoadBalancer interno, lo stato del sottoinsieme GKE determinano il bilanciatore del carico 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 i backend determinano la modalità di raggruppamento dei nodi in GCE_VM_IPNEG, 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 backend di gruppi di endpoint di rete (NEG) GCE_VM_IP
|
Le VM dei nodi sono raggruppate in base alla zona in Il |
| Servizio LoadBalancer interno creato in un cluster con l'impostazione secondaria GKE disattivata | 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 servizi di backend del bilanciatore del carico creati nel cluster a causa della limitazione del singolo gruppo di istanze bilanciate del carico. |
Servizio LoadBalancer esterno con l'annotazionecloud.google.com/l4-rbs: "enabled"2
|
Un bilanciatore del carico di rete passthrough esterno basato su un 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 servizi di backend del bilanciatore del carico creati nel cluster a causa della limitazione del singolo gruppo di istanze bilanciate del carico. |
Servizio LoadBalancer esterno senza l'annotazionecloud.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 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. Eventuali
servizi LoadBalancer interni creati prima dell'attivazione del sottoinsieme GKE
continuano a utilizzare i backend dei gruppi di istanze non gestiti. Per esempi e indicazioni sulla configurazione, consulta Creare 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 servizio 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.
3 La 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 su servizio di backend non comporta la creazione da parte di GKE di un bilanciatore del carico di rete passthrough esterno basato su 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.
Adesione dei nodi ai backend NEG di GCE_VM_IP
Quando l'impostazione secondaria 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ù gruppi NEG GCE_VM_IP bilanciati in base al 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 i nodi come endpoint ai NEG GCE_VM_IP in base al valore di externalTrafficPolicy del servizio e al numero di nodi nel cluster, come descritto nella tabella seguente.
externalTrafficPolicy |
Numero di nodi nel cluster | Abbonamento 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 servizio 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 servizio attivo per il servizio. |
Local |
Un numero qualsiasi di nodi1 | GKE utilizza solo i nodi che hanno almeno uno dei pod di servizio in esecuzione 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 informazioni dettagliate 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ù gruppi di istanze bilanciate in base al 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 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 GKE è disattivata.
- Bilanciatori del carico di rete passthrough esterni basati su servizi di backend creati per servizi LoadBalancer
esterni 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 è 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.
- 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:
- Attiva il sottoinsieme 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 il bilanciamento del carico nativo dei contenitori GKE.
Controlli di integrità del bilanciatore del carico
Tutti i servizi LoadBalancer di GKE implementano un controllo dello stato del bilanciatore del carico. Il sistema di controllo dell'integrità del bilanciatore del carico opera al di fuori del cluster ed è diverso da un probe di idoneità, attività o avvio del pod.
I pacchetti di controllo di integrità del bilanciatore del carico ricevono una risposta dal software kube-proxy
(piano dati precedente) o cilium-agent (GKE Dataplane V2) in esecuzione su ogni
nodo. I controlli di integrità del bilanciatore del carico per i servizi LoadBalancer non possono essere gestiti
dai pod.
Il externalTrafficPolicy del servizio determina quali nodi superano il controllo di integrità del bilanciatore del carico:
externalTrafficPolicy |
Quali nodi superano il controllo di integrità | La porta utilizzata |
|---|---|---|
Cluster |
Tutti i nodi del cluster superano il controllo di integrità dell'integrità, inclusi i nodi senza pod in esecuzione. Se su un nodo esiste almeno un pod in esecuzione, quel nodo supera il controllo di integrità del bilanciatore del carico indipendentemente dallo stato del pod. | La porta del controllo di integrità del bilanciatore del carico deve essere la porta TCP 10256. Non può essere personalizzato. |
Local |
Il controllo di integrità del bilanciatore del carico considera un nodo integro se sul nodo è presente almeno un pod di servizio pronto e non in fase di terminazione, indipendentemente dallo stato di eventuali altri pod. 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 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 malfunzionamento del controllo di integrità del bilanciatore del carico. Lo stato di transizione si verifica quando tutti i pod in esecuzione su un nodo iniziano a non superare i probe di idoneità o quando tutti i pod in esecuzione su un nodo vengono terminati. 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 del controllo di integrità è la porta TCP 10256, a meno che non specifichi una porta di controllo di integrità personalizzata. |
Quando il bilanciamento del carico ponderato è abilitato, il software kube-proxy o cilium-agent include un'intestazione di risposta nella risposta al controllo di integrità del bilanciatore del carico. Questa intestazione di risposta definisce un peso proporzionale al numero di pod in pubblicazione, pronti e non in fase di terminazione sul nodo. Il bilanciatore del carico indirizza le nuove connessioni ai pod di servizio in base a questo peso.
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
I bilanciatori del carico di rete passthrough instradano i pacchetti all'interfaccia nic0 dei nodi del cluster GKE. Ogni pacchetto bilanciato in base al carico ricevuto su un nodo
ha 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 forwarding del bilanciatore del carico
- un protocollo e una porta specificati in
Network Address Translation (NAT) di destinazione sui nodi
Dopo aver ricevuto il pacchetto, il nodo esegue un'ulteriore elaborazione del pacchetto. Nei cluster GKE che utilizzano il dataplane precedente,
i nodi utilizzano iptables per elaborare i pacchetti con bilanciamento del carico. Nei cluster GKE con GKE Dataplane V2 attivato, i nodi utilizzano invece eBPF. L'elaborazione dei pacchetti a livello di nodo 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 modifica la porta di destinazione del pacchetto in
targetPortdelspec.ports[]del servizio corrispondente.
Network Address Translation 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 bilanciati 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 pubblicazione. Il pod di pubblicazione potrebbe o meno trovarsi sullo stesso nodo. Se il nodo che riceve i pacchetti dal bilanciatore del carico non dispone di un pod pronto e in esecuzione, inoltra i pacchetti a un altro nodo che contiene un pod pronto e in esecuzione. I pacchetti di risposta del pod vengono instradati dal suo nodo al nodo che ha ricevuto i pacchetti di richiesta dal bilanciatore del carico. Questo primo nodo invia quindi i pacchetti di risposta al client originale utilizzando il ritorno diretto del 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 eseguito sul nodo che ha ricevuto il pacchetto dal bilanciatore del carico. Il 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 alcuni casi, un nodo riceve pacchetti dal bilanciatore del carico anche se non dispone di un pod di servizio pronto e non in fase di terminazione. 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 idoneo e in esecuzione non è più idoneo o sta terminando (ad esempio, quando viene eseguito un aggiornamento progressivo). 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 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 inoltro. Puoi anche stimare gli addebiti di fatturazione utilizzando il calcolatore dei prezzi di Google Cloud.
Il numero di regole di inoltro 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 inoltro 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 per i servizi di backend per progetto, la quota per i controlli di integrità per progetto e la quota per le regole di inoltro dei bilanciatori del carico di rete passthrough esterni 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 per progetto delle regole di inoltro del bilanciatore del carico di rete passthrough esterno.
Passaggi successivi
- Scopri di più sui parametri del servizio LoadBalancer di GKE.
- Scopri di più sui servizi Kubernetes.