Parametri del servizio LoadBalancer

In questa pagina vengono descritti i parametri per i manifest del servizio che controllano il LoadBalancer Comportamento e configurazione del servizio. Prima di leggere questa pagina, assicurati di avere avere familiarità con il servizio LoadBalancer di Google Kubernetes Engine (GKE) concetti fondamentali.

Parametri di servizio

GKE supporta i seguenti parametri per i servizi LoadBalancer.

Parametro Campo e descrizione del servizio Interno Esterno Supporto delle versioni
Bilanciatore del carico di rete passthrough interno networking.gke.io/load-balancer-type: "Internal"

Indica a GKE di creare un bilanciatore del carico di rete passthrough interno.

Per maggiori dettagli, consulta Concetti del servizio LoadBalancer.

 Tutte le versioni supportate.
Bilanciatore del carico di rete passthrough esterno basato sul servizio di backend cloud.google.com/l4-rbs: "enabled"

Indica a GKE di creare un ambiente basato su servizio di backend il bilanciatore del carico di rete passthrough esterno.

Per maggiori dettagli, consulta Concetti del servizio LoadBalancer.

 GKE 1.25.5 e versioni successive
Norme relative al traffico interno spec.internalTrafficPolicy

Se impostato su Local, GKE inoltra solo i pacchetti dai pod client su un nodo ai pod di servizio sullo stesso nodo. Se impostato su Cluster, GKE instrada pacchetti dai pod client su un nodo alla gestione dei pod su qualsiasi nodo. Per maggiori dettagli, consulta Norme sul traffico interno del servizio.

Questo parametro non è supportato nei cluster che eseguono GKE Dataplane 2.

 GKE 1.22 e versioni successive
Criterio traffico esterno spec.externalTrafficPolicy

Controlla quali VM dei nodi superano i controlli di integrità del bilanciatore del carico e come e pacchetti vengono instradati ai pod pronti e in uso nel cluster. Inoltre, controlla in che modo i nodi vengono raggruppati in GCE_VM_IP NEG quando è attivato il sottoinsieme GKE.

Per maggiori dettagli, vedi Concetti del servizio LoadBalancer.

 GKE 1.14 e versioni successive (1.23.4-gke.400 e versioni successive per il pool di nodi Windows).
Porta del controllo di integrità spec.healthCheckNodePort

Esegue il deployment di un controllo di integrità del bilanciatore del carico per i servizi LoadBalancer. Questo è valido solo se viene impostato spec.externalTrafficPolicy a Local.

 Tutte le versioni supportate.
Regole firewall e lista consentita per l'indirizzo IP di origine spec.loadBalancerSourceRanges

Configura le regole firewall facoltative in GKE e nel rete VPC solo per determinati intervalli di origine. kube-proxy configura anche iptables regole per corrispondano agli intervalli di origine specificati.

 Tutte le versioni supportate.
Indirizzi IP statici
  • spec.loadBalancerIP (solo IPv4)
  • networking.gke.io/load-balancer-ip-addresses

Specifica un indirizzo IPv4 statico, un intervallo di indirizzi IPv6 statico o entrambi assegnate alle regole di forwarding del bilanciatore del carico. Consulta la sezione Considerazioni per la condivisione di un indirizzo IP comune per informazioni importanti sui requisiti di configurazione e sull'implementazione.
  • spec.loadBalancerIP: tutte le versioni supportate.
  • networking.gke.io/load-balancer-ip-addresses: GKE 1.29 e versioni successive. Consulta Parametri degli indirizzi IP statici per ulteriori requisiti di annotazione o configurazione del cluster.
Network Service Tiers cloud.google.com/network-tier

Specifica quale Network Service Tiers GKE utilizza per la regola di forwarding esterno e l'IP . I valori validi dell'annotazione sono Standard e Premium (valore predefinito).

 GKE 1.19 e versioni successive.
Subnet personalizzata
  • networking.gke.io/internal-load-balancer-subnet
  • networking.gke.io/load-balancer-subnet
(si applica solo a IPv6)
  • networking.gke.io/internal-load-balancer-subnet: tutti versioni supportate
  • networking.gke.io/load-balancer-subnet: GKE 1.29 e versioni successive. Per ulteriori requisiti, consulta Annotazioni delle subnet personalizzate.
Accesso globale networking.gke.io/internal-load-balancer-allow-global-access: "true"

Consente all'indirizzo IP della regola di inoltro di essere accessibile ai client in qualsiasi regione della rete VPC o di una rete collegata.

 Anteprima in GKE 1.16 e versioni successive. Disponibile in generale in GKE 1.17.9-gke.600 e versioni successive.
Tutte le porte

Non è richiesta alcuna annotazione, ma il sottoinsieme GKE deve essere attivato.

GKE configura automaticamente la regola di inoltro in modo da utilizzare tutte le porte se in spec.ports[].port sono specificate almeno sei (fino a 100) porte univoche.

 GKE versione 1.18.19-gke.1400 o successive
ipFamilyPolicy

spec.ipFamilyPolicy

Definisce il modo in cui GKE alloca gli indirizzi IP a un servizio. Puoi definire spec.ipFamilyPolicy come SingleStack, PreferDualStack o RequireDualStack.

Per ulteriori informazioni, vedi Servizi a doppio stack IPv4/IPv6

 I cluster GKE versione 1.29 o successive supportano la rete a doppio stack per i servizi LoadBalancer.
ipFamilies (facoltativo)

spec.ipFamilies

Definisce la famiglia di indirizzi IP per allocare servizi single-stack o dual-stack. Utilizza uno dei seguenti valori:

  • IPv4 solo per il servizio IPv4 a stack singolo.
  • IPv6 solo per il servizio IPv6.
  • IPv4,IPv6 per il servizio a doppio stack in cui l'indirizzo IP principale del servizio è IPv4.
  • IPv6,IPv4 per il servizio a doppio stack in cui l'indirizzo IP principale del servizio è IPv6.
 I cluster GKE nella versione 1.29 o successive supportano la rete dual-stack per i servizi LoadBalancer.

Porta del controllo di integrità

Come descritto in Controlli di integrità dei bilanciatori del carico, GKE esegue sempre il deployment di un controllo di integrità del bilanciatore del carico quando crea un bilanciatore del carico di rete passthrough esterno o interno.

La possibilità di configurare il parametro healthCheckNodePort dipende dal seguente configurazione di externalTrafficPolicy:

externalTrafficPolicy Porta del controllo di integrità
Cluster

Non puoi utilizzare spec.healthCheckNodePort.

Local

Puoi selezionare una porta personalizzata utilizzando spec.healthCheckNodePort. Se non specificato, il control plane Kubernetes assegna una porta di controllo di integrità dall'intervallo di porte del nodo.

Regole firewall e lista consentita di indirizzi IP di origine

Quando crei un servizio LoadBalancer, GKE crea una regola firewall VPC corrispondente al servizio. Ogni regola firewall presenta le seguenti caratteristiche:

  • La direzione della regola firewall è in entrata e la sua azione è consentita. La firewall implicito per negare l'accesso di Google Cloud in Google Cloud che GKE utilizza un modello di lista consentita durante la creazione del firewall in entrata le regole del caso.
  • GKE imposta il protocollo e la porta di destinazione della regola firewall su a quelle specificate nell'elenco spec.ports[] del servizio.
  • GKE imposta la destinazione della regola firewall impostandone parametro target su l'indirizzo IP virtuale di LoadBalancer.
  • Se il servizio include spec.loadBalancerSourceRanges[], GKE imposta il parametro source della regola del firewall sugli indirizzi IP in quell'elenco. Inoltre, l'istanza kube-proxy in esecuzione su ciascun nodo configura regole iptables del nodo per limitare il traffico agli indirizzi IP specificati. Se il servizio non include loadBalancerSourceRanges[], GKE imposta il parametro di origine della regola firewall su tutti gli indirizzi IP (0.0.0.0/0).

La regola firewall creata per un servizio LoadBalancer consente i pacchetti, al protocollo e alle porte di destinazione del servizio, all'IP virtuale .

Servizi che utilizzano porte comuni

Quando un cluster contiene due o più servizi che condividono almeno un servizio e la porta di destinazione, l'insieme effettivo di intervalli di origine è l'unione di loadBalancerSourceRanges per tutti i Servizi che specificano tale protocollo di porte di destinazione. Questo perché il parametro target di un traffico in entrata regola firewall definisce gli indirizzi IP di destinazione come tutti gli indirizzi IP associati a una VM.

Considera un cluster con due servizi LoadBalancer:

  • Il spec.ports[0].port del primo servizio è la porta TCP 80 e il suo spec.loadBalancerSourceRanges=[100.10.0.0/16]. Il bilanciatore del carico risultante corrispondente a questo servizio ha l'indirizzo IP 192.0.2.2.
  • Il spec.ports[0].port del secondo servizio è la porta TCP 80, spec.ports[1].port è la porta TCP 90 e la relativa spec.loadBalancerSourceRanges=[172.16.0.0/24]. Il bilanciatore del carico risultante corrispondente a questo servizio ha l'indirizzo IP 198.51.100.3.

GKE crea due regole firewall di autorizzazione in entrata nel la rete VPC (Virtual Private Cloud). Entrambe le regole firewall specificano tutti i nodi del cluster come target:

  • La prima regola firewall consente i pacchetti verso la porta TCP di destinazione 80 da fonte 100.10.0.0/16.
  • La seconda regola firewall consente i pacchetti alle porte di destinazione TCP 80 e 90 dall'origine 172.16.0.0/24.

La prima regola di inoltro inoltra il traffico corrispondente alla destinazione 192.0.2.2:80. La seconda regola di forwarding instrada il traffico che corrisponde sia 198.51.100.3:80 e 198.51.100.3:90 destinazioni. Tutti e tre i requisiti seguenti sono destinazioni valide su ciascun nodo: 192.0.2.2:80, 198.51.100.3:80 e 198.51.100.3:90. Ciò significa che:

  • Entrambi i servizi accettano pacchetti sulla porta TCP 80 dall'unione dell'IP intervalli di origine di indirizzi, da 100.10.0.0/16 o 172.16.0.0/24.
  • Il secondo servizio accetta pacchetti sulla porta TCP 90 da 172.16.0.0/24.

L'insieme effettivo di intervalli di origine per tutti i Servizi che utilizzano lo stesso protocollo e La combinazione di porte di destinazione diventa tutti gli indirizzi IP se spec.loadBalancerSourceRanges è omesso in almeno uno dei servizi che lo utilizzano combinazione di protocollo e porta di destinazione. Ad esempio, se il secondo servizio avesse omesso spec.loadBalancerSourceRanges, l'origine del secondo firewall sarebbe 0.0.0.0/0 e:

  • Entrambi i servizi accetteranno i pacchetti per la porta TCP 80 dall'unione degli intervalli di origine degli indirizzi IP, da 100.10.0.0/16 o 0.0.0.0/0. Poiché l'intervallo 0.0.0.0/0 include l'intervallo 100.10.0.0/16, l'origine effettiva per i pacchetti inviati alla porta TCP 80 è qualsiasi indirizzo IP.
  • Il secondo servizio accetterà pacchetti sulla porta TCP 90 da 0.0.0.0/0 (qualsiasi l'indirizzo IP).

Indirizzi IP statici

Puoi creare un indirizzo IP statico e configurare GKE in modo da assegnare questo indirizzo statico alla regola di inoltro del bilanciatore del carico. L'utilizzo di un indirizzo IP statico garantisce che l'indirizzo IP del bilanciatore del carico rimanga invariato anche se apporti modifiche al servizio LoadBalancer. Senza un indirizzo IP statico, GKE potrebbe assegnare un indirizzo IP diverso alla regola di inoltro del bilanciatore del carico quando aggiorni un servizio LoadBalancer. L'indirizzo IP della regola di inoltro non corrisponde all'indirizzo spec.clusterIP del servizio. L'indirizzo ClusterIP di un servizio non cambia mai quando aggiorni un servizio LoadBalancer.

Parametri dell'indirizzo IP statico

Per indicare a un servizio LoadBalancer di utilizzare un indirizzo IP statico, utilizza il parametro spec.loadBalancerIP o il parametro Annotazione networking.gke.io/load-balancer-ip-addresses. In GKE 1.29 e successive, l'annotazione ha la precedenza sulle spec.loadBalancerIP se il manifest del servizio contiene sia il parametro che l'annotazione.

Parametro o annotazione e valore Requisiti e funzionalità
spec.loadBalancerIP:
IPv4_ADDRESS

Puoi specificare un indirizzo IPv4 interno statico per un server servizio LoadBalancer interno. Puoi specificare un IPv4 esterno statico per un servizio LoadBalancer esterno solo IPv4. Il parametro funziona con tutte le versioni GKE supportate.
networking.gke.io/load-balancer-ip-addresses:
IP_ADDRESS_RESOURCE_NAME
  • Per i servizi LoadBalancer a stack singolo, imposta il valore dell'annotazione sul nome della risorsa indirizzo IPv4 o IPv6, non sull'indirizzo IP stesso.
  • Per i servizi LoadBalancer a doppio stack, imposta il valore del parametro sul nome della risorsa dell'indirizzo IPv4 statico e sull'IPv6 statico nome della risorsa dell'intervallo di indirizzi separato da una virgola.

Puoi specificare un indirizzo IPv4 statico, un intervallo di indirizzi IPv6 statico, solo IPv4, solo IPv6 e a doppio stack interno ed esterno Servizi LoadBalancer. L'annotazione richiede GKE 1.29 o versioni successive e i seguenti requisiti aggiuntivi:

  • Per utilizzare questa annotazione con un servizio LoadBalancer interno, devi crea il servizio LoadBalancer interno in un cluster dopo aver abilitato Creazione secondaria di GKE.
  • Per utilizzare questa annotazione con un servizio LoadBalancer esterno, devi includi l'annotazione cloud.google.com/l4-rbs: "enabled" in il manifest del servizio quando crei il bilanciatore del carico esterno assistenza.

Considerazioni per la condivisione di un indirizzo IP comune

Due o più servizi LoadBalancer possono fare riferimento allo stesso indirizzo IP statico se la regola di inoltro per ogni bilanciatore del carico utilizza una combinazione univoca di indirizzo IP, protocollo, specifica della porta e specifica dei livelli di servizio di rete, come indicato nella tabella di questa sezione. Inoltre:

  • Gli indirizzi IPv6 statici sono in realtà intervalli di indirizzi IPv6 di /96, ma GKE configura i nodi in modo da accettare i pacchetti solo sul primo indirizzo IPv6 (/128) nell'intervallo /96.

  • Affinché due o più servizi Internal LoadBalancer utilizzino lo stesso indirizzo IPv4 interno o lo stesso intervallo di indirizzi IPv6 interni, l'indirizzo IP statico deve essere creato con lo scopo SHARED_LOADBALANCER_VIP.

Servizio LoadBalancer interno Servizio LoadBalancer esterno
Specifica della porta

Le regole di inoltro per i bilanciatori del carico di rete passthrough interni supportano fino a cinque numeri di porta distinti oppure possono essere configurate per utilizzare tutte le porte.

Quando un servizio LoadBalancer interno ha sei o più spec.ports[] specificati, GKE configura la regola di inoltro per il bilanciatore del carico di rete passthrough interno in modo che utilizzi tutte le porte.

Quando una regola di inoltro utilizza tutte le porte, nessun'altra regola di inoltro (di conseguenza, nessun altro servizio LoadBalancer interno) può utilizzare lo stesso indirizzo IP.

GKE crea un bilanciatore del carico di rete passthrough esterno basato su un pool di destinazione se nel manifest del servizio LoadBalancer manca l'annotazione cloud.google.com/l4-rbs: "enabled".

Le regole di forwarding per i bilanciatori del carico di rete passthrough esterni basati su pool di destinazione devono utilizzare di porte contigue. L'intervallo di porte contigue include tutte le porte di cui il Servizio ha bisogno, ma potrebbe includere anche porte aggiuntive non utilizzate dal Servizio. Ad esempio, un servizio LoadBalancer esterno basato su un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione che specifica le porte 80 e 443 nel relativo manifest del servizio utilizza una regola di inoltro del bilanciatore del carico con un intervallo di porte di 80-443. Questo intervallo di porte impedisce che altre per i servizi LoadBalancer dall'utilizzo di una delle porte 80, 443 e qualsiasi numeri compresi tra 80 e 443.

GKE crea un bilanciatore del carico di rete passthrough esterno basato su un servizio di backend se il manifest del servizio LoadBalancer include l'annotazione cloud.google.com/l4-rbs: "enabled". Inoltro regole per i bilanciatori del carico di rete passthrough esterni basati sul servizio di backend supportano fino a cinque numeri di porte discreti, un intervallo di porte contiguo oppure configurate per l'utilizzo di tutte le porte.
Network Service Tiers Non configurabile: gli indirizzi interni sono sempre di livello Premium.

Configurabile per indirizzi IPv4 statici esterni a livello di regione. Gli intervalli di indirizzi IPv6 esterni regionali statici possono essere creati solo nel livello Premium.

La specifica dei livelli di servizio di rete dell'indirizzo IP esterno statico deve corrispondere a:

  • Il livello specificato nel file manifest del servizio LoadBalancer Annotazione cloud.google.com/network-tier, se è presenti nel file manifest,
  • Il livello predefinito del progetto, se l'annotazione cloud.google.com/network-tier non è presente nel manifest del servizio LoadBalancer.

Il livello predefinito del progetto è Premium, a meno che tu non lo abbia configurato in modo diverso.

Subnet LoadBalancer

Puoi configurare un servizio LoadBalancer interno per utilizzare un servizio temporaneo o statico Indirizzo IPv4, intervallo di indirizzi IPv6 o entrambi in una subnet personalizzata la stessa regione e rete VPC del cluster. Usa una subnet personalizzata di un servizio LoadBalancer interno per:

  • Raggruppa i bilanciatori del carico di rete passthrough interni creati dai servizi di bilanciamento del carico interno da due o nella stessa rete VPC, regione.
  • Crea servizi LoadBalancer interni i cui bilanciatori del carico di rete passthrough interni hanno indirizzi IPv4 distinti dagli indirizzi IPv4 dei nodi del cluster.
  • In un cluster dual-stack, crea servizi LoadBalancer interni i cui bilanciatori del carico di rete passthrough interni hanno intervalli di indirizzi IPv6 separati dagli indirizzi IPv6 dei nodi e dei pod del cluster. Una subnet LoadBalancer personalizzata è obbligatoria per il supporto Servizi LoadBalancer interni se la subnet del cluster ha un IPv6 esterno di indirizzi IP esterni.

Puoi configurare un servizio LoadBalancer esterno per utilizzare un servizio temporaneo o statico Intervallo di indirizzi IPv6 in una subnet personalizzata che si trova nella stessa regione rete VPC come cluster. Utilizza una sottorete personalizzata per creare servizi LoadBalancer esterni i cui bilanciatori del carico di rete passthrough esterni hanno intervalli di indirizzi IPv6 distinti dagli indirizzi IPv6 del nodo e del pod del cluster. Una subnet LoadBalancer personalizzata è obbligatoria per supportare i servizi LoadBalancer esterni in un cluster privato dual-stack perché la subnet del cluster ha un intervallo di indirizzi IPv6 interni.

Annotazioni per subnet personalizzate

Utilizza una delle seguenti annotazioni per indicare a un servizio LoadBalancer di utilizzare un indirizzo IP temporaneo o statico in una subnet personalizzata. Se un servizio LoadBalancer il file manifest include entrambe le annotazioni, networking.gke.io/load-balancer-subnet l'annotazione ha la precedenza purché i relativi requisiti di annotazione siano soddisfatti.

Annotazione e valore Requisiti e funzionalità
networking.gke.io/internal-load-balancer-subnet:
SUBNET_RESOURCE_NAME

Puoi utilizzare l'annotazione solo per specificare una subnet personalizzata per un Servizio LoadBalancer interno solo IPv4. L'annotazione funziona con tutti versioni GKE supportate.
networking.gke.io/load-balancer-subnet:
SUBNET_RESOURCE_NAME

Puoi specificare una subnet personalizzata per un'istanza solo IPv4, solo IPv6 servizio LoadBalancer interno dual-stack. Puoi specificare una subnet personalizzata per un servizio LoadBalancer esterno solo IPv6 o a doppio stack. L'annotazione richiede GKE 1.29 o versioni successive e i seguenti requisiti aggiuntivi:

  • Per utilizzare questa annotazione allo scopo di specificare una subnet personalizzata per un devi creare il servizio LoadBalancer interno in un cluster dopo aver abilitato Creazione secondaria di GKE.
  • Per utilizzare questa annotazione per specificare una sottorete personalizzata per un servizio LoadBalancer esterno, devi includere l'annotazione cloud.google.com/l4-rbs: "enabled" nel manifest del servizio quando crei il servizio LoadBalancer esterno.

Subnet e indirizzo IPv4 per un servizio LoadBalancer interno

La tabella seguente descrive le combinazioni valide di specifica della subnet e indirizzo IPv4 per un servizio LoadBalancer interno solo IPv4 o a doppio stack.

Indirizzo IPv4 statico Indirizzo IPv4 temporaneo
Subnet personalizzata
 Subnet personalizzata e indirizzo IPv4 statico: l'indirizzo IPv4 interno statico deve essere stato creato nell'indirizzo IPv4 principale della subnet personalizzata intervallo. Subnet personalizzata e indirizzo IPv4 temporaneo: GKE utilizza un indirizzo IPv4 interno non allocato nell'intervallo di indirizzi IPv4 primario della subnet personalizzata.
Subnet cluster Subnet del cluster e indirizzo IPv4 statico: l'indirizzo IPv4 interno statico deve essere stato creato nell'intervallo di indirizzi IPv4 principale della subnet del cluster. Subnet del cluster e indirizzo IPv4 temporaneo: GKE utilizza un indirizzo IPv4 interno non allocato nella subnet principale del cluster Intervallo di indirizzi IPv4.

Subnet e intervallo di indirizzi IPv6 per un servizio LoadBalancer interno

La tabella seguente descrive una specifica della subnet valida e un intervallo di indirizzi IPv6 per un servizio LoadBalancer interno solo IPv6 o a doppio stack. Anche se la regola di inoltro IPv6 del bilanciatore del carico di rete passthrough interno utilizza un intervallo di indirizzi IPv6 /96 interno, GKE configura i nodi in modo da accettare solo i pacchetti le cui destinazioni corrispondono al primo indirizzo IPv6 (/128) dell'intervallo /96 della regola di inoltro.

Intervallo di indirizzi IPv6 statico Indirizzo IPv6 temporaneo intervallo
Subnet dual-stack personalizzata
  • Deve trovarsi nella stessa rete VPC e nella stessa regione del cluster.
  • Deve avere un intervallo di indirizzi IPv6 interno (tipo di accesso INTERNAL).
  • Deve essere specificato utilizzando l'annotazione networking.gke.io/load-balancer-subnet.
 Subnet personalizzata e intervallo di indirizzi IPv6 statico: la subnet statica l'intervallo di indirizzi IPv6 /96 interno deve essere stato creato in l'intervallo di indirizzi IPv6 /64 interno della subnet personalizzata. Subnet personalizzata e intervallo di indirizzi IPv6 temporanei: GKE utilizza un IPv6 /96 interno non allocato di indirizzi dell'IPv6 interno /64 della subnet personalizzata di indirizzi IP esterni.
Subnet a stack doppio del cluster
  • Deve avere un intervallo di indirizzi IPv6 interno (tipo di accesso INTERNAL).
 Subnet del cluster e intervallo di indirizzi IPv6 statico: l'intervallo l'intervallo di indirizzi IPv6 /96 interno deve essere stato creato in all'intervallo di indirizzi IPv6 /64 interno della subnet cluster. Subnet del cluster e intervallo di indirizzi IPv6 effimeri: GKE utilizza un intervallo di indirizzi IPv6 interno /96 non allocato dall'intervallo di indirizzi IPv6 interno /64 della subnet del cluster.

Subnet e indirizzo IPv4 per un servizio LoadBalancer esterno

Per i servizi LoadBalancer esterni solo IPv4 e a doppio stack, l'indirizzo IPv4 esterno, che si tratti di un indirizzo IPv4 esterno statico o di un indirizzo IPv4 esterno temporaneo, non proviene da una subnet.

Subnet e intervallo di indirizzi IPv6 per un servizio LoadBalancer esterno

La tabella seguente descrive una specifica della subnet valida e un intervallo di indirizzi IPv6 per un servizio LoadBalancer esterno solo IPv6 o a doppio stack. Anche se la regola di inoltro IPv6 del bilanciatore del carico di rete passthrough esterno utilizza un intervallo di indirizzi IPv6 /96 esterno, GKE configura i nodi in modo da accettare solo i pacchetti le cui destinazioni corrispondono al primo indirizzo IPv6 (/128) dell'intervallo /96 della regola di inoltro.

Intervallo di indirizzi IPv6 statico Intervallo di indirizzi IPv6 effimeri
Subnet dual-stack personalizzata
  • Deve trovarsi nella stessa rete VPC e nella stessa regione del cluster.
  • Deve avere un intervallo di indirizzi IPv6 esterni (tipo di accesso EXTERNAL).
  • Deve essere specificato utilizzando la proprietà networking.gke.io/load-balancer-subnet.
 Subnet personalizzata e intervallo di indirizzi IPv6 statici: l'intervallo di indirizzi IPv6 /96 esterno statico deve essere stato creato nell'intervallo di indirizzi IPv6 /64 esterno della subnet personalizzata. Gli intervalli di indirizzi IPv6 esterni statici possono essere creati solo nel livello Premium. Subnet personalizzata e intervallo di indirizzi IPv6 effimeri: GKE utilizza un intervallo di indirizzi IPv6 /96 esterno non allocato dall'intervallo di indirizzi IPv6 /64 esterno della subnet personalizzata.
Subnet a stack doppio del cluster
  • Deve avere un intervallo di indirizzi IPv6 esterni (tipo di accesso EXTERNAL).
 Subnet del cluster e intervallo di indirizzi IPv6 statico: l'intervallo è stato creato un intervallo di indirizzi IPv6 /96 esterno in l'intervallo di indirizzi IPv6 /64 esterno della subnet del cluster. Gli intervalli di indirizzi IPv6 esterni statici possono essere creati solo nel livello Premium. Subnet del cluster e intervallo di indirizzi IPv6 temporanei: GKE utilizza un IPv6 /96 esterno non allocato intervallo di indirizzi dall'IPv6 esterno /64 della subnet del cluster di indirizzi IP esterni.

Accesso globale

Quando networking.gke.io/internal-load-balancer-allow-global-access l'annotazione è false o non specificata per un servizio LoadBalancer interno, GKE crea un bilanciatore del carico di rete passthrough interno la cui regola di forwarding ha accesso globale disabilitato. Se l'accesso globale è disattivato, i client che devono al bilanciatore del carico deve trovarsi nella stessa regione rete VPC o una rete connessa rete VPC.

Quando l'annotazione networking.gke.io/internal-load-balancer-allow-global-access è true per un servizio LoadBalancer interno, GKE attiva l'opzione di accesso globale nella regola di inoltro del bilanciatore del carico di rete passthrough interno. I client in qualsiasi regione della rete VPC o in una rete collegata alla rete VPC del cluster possono accedere al bilanciatore del carico.

Per saperne di più su come l'accesso globale si applica ai client in una rete connessa, consulta:

Tutte le regole di forwarding delle porte

Le regole di forwarding per i bilanciatori del carico di rete passthrough interni supportano cinque numeri di porta univoci o tutti porte.

Nei cluster GKE in cui è disabilitata l'impostazione secondaria di GKE, viene il servizio LoadBalancer interno può supportare solo cinque porte univoche spec.ports[].port del servizio.

Nei cluster GKE in cui è abilitata l'impostazione secondaria di GKE, viene il servizio LoadBalancer interno può supportare solo fino a 100 porte nella spec.ports[].port. Per servizi LoadBalancer interni con un valore compreso tra 6 e 100 voci spec.ports[].port univoche, GKE configura regola di forwarding del bilanciatore del carico di rete passthrough interno per utilizzare tutte le porte dalla sua creazione. Il controller GKE attiva tutte le porte nella regola di inoltro perché il servizio ha più di cinque porte. Quando configuri una regola di inoltro per l'utilizzo di tutte le porte, GKE crea solo regole firewall di autorizzazione in entrata per le porte specifiche configurate in spec.ports[].port nel servizio.

Per ulteriori informazioni sulle regole di inoltro del bilanciatore del carico di rete passthrough interno e sulle specifiche delle porte valide, consulta Regole di inoltro e specifiche delle porte.

Servizio LoadBalancer con stack doppio IPv4/IPv6

Puoi creare un servizio LoadBalancer interno o esterno che stack singolo (solo IPv4 o solo IPv6) o doppio stack. LoadBalancer a stack singolo I servizi creano un'unica regola di forwarding con un indirizzo IPv4 o un indirizzo IPv6 . I servizi LoadBalancer a doppio stack creano due regole di inoltro: una con un indirizzo IPv4 e un'altra con un indirizzo IPv6. Per creare un servizio LoadBalancer a doppio stack IPv4/IPv6, esegui il deployment in un cluster a doppio stack IPv4/IPv6 e completa una delle seguenti operazioni, a seconda del tipo di bilanciatore del carico utilizzato:

Per ogni servizio, puoi definire le specifiche ipFamilyPolicy e ipFamilies. Per saperne di più, consulta IPv4/IPv6 a doppio stack.

Limitazioni dei servizi LoadBalancer dual-stack

  • I servizi LoadBalancer con indirizzi IPv6 sono supportati solo nei cluster con tipo di stack ipv4-ipv6. Per ulteriori informazioni, scopri come Utilizza un indirizzo IP a doppio stack per un cluster nativo di VPC.

  • Impossibile eseguire l'upgrade dei servizi LoadBalancer creati con un indirizzo a stack singolo ai servizi dual stack.

  • I servizi LoadBalancer creati con indirizzi a doppio stack possono essere modificati in modo da avere un solo stack in base alle seguenti condizioni:

    • Un servizio con ipFamilies ["IPv4","IPv6"] può essere modificato in un servizio con ipFamilies IPv4 ma non IPv6.
    • Un servizio con ipFamilies ["IPv6","IPv4"] può essere modificato in un servizio con ipFamilies IPv6 ma non IPv4.