Parametri del servizio LoadBalancer

Questo documento descrive i parametri per i manifest del servizio che controllano il LoadBalancer Comportamento e configurazione del servizio. Prima di leggere questo documento, assicurati di avere avere familiarità con il servizio LoadBalancer di Google Kubernetes Engine (GKE) Concetti.

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, vedi 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, vedi Concetti del servizio LoadBalancer.

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

Se impostato su Local, GKE instrada solo i pacchetti dai pod client su un nodo ai pod gestiti sullo stesso nodo. Se impostato su Cluster, GKE instrada pacchetti dai pod client su un nodo alla gestione dei pod su qualsiasi nodo. Per ulteriori dettagli, vedi Norme relative al traffico interno del servizio.

Questo parametro non è supportato nei cluster in esecuzione GKE Dataplane V2.

 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 come i nodi vengono raggruppati in GCE_VM_IP NEG quando è abilitata l'impostazione secondaria di 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 indirizzo IP di origine lista consentita spec.loadBalancerSourceRanges

Configura le regole firewall facoltative in GKE e nel rete VPC solo per determinati intervalli di origine.

 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 Considerazioni per la condivisione di un IP comune per importanti requisiti di configurazione e implementazione i dettagli.
  • 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 di configurazione o di annotazione del cluster aggiuntivi.
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. Consulta Annotazioni per subnet personalizzate per ulteriori requisiti.
Accesso globale networking.gke.io/internal-load-balancer-allow-global-access: "true"

Abilita l'indirizzo IP della regola di forwarding per essere accessibile da client in qualsiasi regione della rete VPC o in ogni rete.

 Visualizza l'anteprima in GKE 1.16 e versioni successive. Generalmente disponibile in GKE 1.17.9-gke.600 e versioni successive.
Tutte le porte

Non è richiesta alcuna annotazione, ma l'impostazione secondaria di GKE deve essere in un bucket con il controllo delle versioni attivo.

GKE configura automaticamente la regola di forwarding Utilizza tutte le porte se vengono specificate almeno sei (fino a 100) porte univoche a spec.ports[].port.

 GKE versione 1.18.19-gke.1400 o successiva
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 stack singolo i servizi dual stack. Utilizza uno qualsiasi 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 versione 1.29 o successive supportano la rete a doppio stack per i servizi LoadBalancer.

Porta del controllo di integrità

Come descritto in Controlli di integrità del bilanciatore del carico e externalTrafficPolicy, 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 un bilanciatore del carico di rete passthrough 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, l'oggetto Kubernetes il piano di controllo assegna una porta per il 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 un'istanza Regola firewall VPC corrispondente al servizio. Ogni regola firewall ha 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 di origine della regola firewall sugli indirizzi IP presenti nell'elenco. 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).
di Gemini Advanced.

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 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 verso le porte di destinazione TCP 80 e 90 dall'origine 172.16.0.0/24.

La prima regola di forwarding instrada il traffico corrispondente a 192.0.2.2:80 destinazione. 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 ha omesso spec.loadBalancerSourceRanges, l'origine del secondo firewall 0.0.0.0/0 e:

  • Entrambi i servizi accettano pacchetti sulla porta TCP 80 dall’unione intervalli di origine di indirizzi, 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, la fonte effettiva per di pacchetti alla porta TCP 80 è un 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 di destinazione e configurare di assegnare l'indirizzo statico a GKE di una regola di forwarding. L'uso di un indirizzo IP statico garantisce che l'indirizzo IP del bilanciatore del carico rimane invariato anche se apporti modifiche al servizio LoadBalancer. Senza un indirizzo IP statico, GKE potrebbe assegnare un indirizzo IP diverso alla regola di forwarding del bilanciatore del carico quando aggiorni un LoadBalancer assistenza. L'indirizzo IP della regola di forwarding non è uguale a quello del servizio spec.clusterIP. L'indirizzo ClusterIP di un servizio non cambia mai di aggiornare un servizio LoadBalancer.

Parametri degli indirizzi IP statici

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 del parametro l'annotazione sul nome della risorsa dell'indirizzo IPv4 o IPv6, non l'IP il proprio indirizzo.
  • 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 in un secondo momento e ai 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 sulla condivisione di un indirizzo IP comune

Due o più servizi LoadBalancer possono fare riferimento allo stesso indirizzo IP statico se la regola di forwarding per ciascun bilanciatore del carico utilizza una combinazione univoca di indirizzi IP indirizzo, protocollo, specifiche della porta e specifiche di Network Service Tiers, come indicato nella tabella di questa sezione. Inoltre:

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

  • Per due o più servizi LoadBalancer interni che utilizzano lo stesso IPv4 interno o un intervallo di indirizzi IPv6 interno, è necessario creare l'indirizzo IP statico con lo scopo SHARED_LOADBALANCER_VIP.

Servizio LoadBalancer interno Servizio LoadBalancer esterno
Specifica della porta

Le regole di forwarding per i bilanciatori del carico di rete passthrough interni supportano fino a cinque numeri di porta o possono essere configurati per l'utilizzo di tutte le porte.

Quando un servizio LoadBalancer interno ha sei o più spec.ports[] specificato, GKE configura regola di forwarding affinché il bilanciatore del carico di rete passthrough interno utilizzi tutte le porte.

Quando una regola di forwarding utilizza tutte le porte, nessun'altra regola di forwarding (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 pool di destinazione se al manifest del servizio LoadBalancer manca 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 porte necessarie al servizio, ma l'intervallo potrebbe includere anche porte aggiuntive non è utilizzato 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 Il codice 443 nel manifest del servizio utilizza una regola di forwarding 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 sul servizio di backend se il manifest del servizio LoadBalancer include il componente 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. Statica gli intervalli di indirizzi IPv6 esterni a livello di regione possono essere creati solo nella versione Premium livello.

La specifica di Network Service Tiers dell'indirizzo IP esterno statico deve corrispondere a uno dei seguenti elementi:

  • 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 in 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 dispongono di IPv4 separati dagli indirizzi IPv4 dei nodi del cluster.
  • In un cluster a doppio stack, crea servizi LoadBalancer interni la cui i bilanciatori del carico di rete passthrough interni hanno intervalli di indirizzi IPv6 separati dal nodo del cluster gli indirizzi IPv6 dei pod. 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. Usa una subnet personalizzata per creare I servizi LoadBalancer esterni i cui bilanciatori del carico di rete passthrough esterni hanno intervalli di indirizzi IPv6 e separate dagli indirizzi IPv6 dei nodi e dei pod del cluster. Un LoadBalancer personalizzato la subnet è obbligatoria per supportare i servizi LoadBalancer esterni in uno stack doppio cluster privato perché la subnet ha un indirizzo IPv6 interno intervallo.

Annotazioni per subnet personalizzate

Utilizza una delle seguenti annotazioni per indicare a un servizio LoadBalancer di utilizzare un indirizzo IP statico o temporaneo 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 quanto segue 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 allo scopo di specificare una subnet personalizzata per un servizio LoadBalancer, devi includere Annotazione cloud.google.com/l4-rbs: "enabled" nel servizio quando crei il servizio LoadBalancer esterno.

Subnet e indirizzo IPv4 per un servizio LoadBalancer interno

La tabella seguente descrive una specifica della subnet e un indirizzo IPv4 validi 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 nella subnet principale personalizzata Intervallo di indirizzi IPv4.
Subnet cluster Subnet del cluster e indirizzo IPv4 statico: l'indirizzo IP statico L'indirizzo IPv4 deve essere stato creato nell'indirizzo IPv4 principale della subnet del cluster di indirizzi IP esterni. 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. Uniforme tramite la regola di forwarding IPv6 del bilanciatore del carico di rete passthrough interno utilizza un IPv6 /96 interno di indirizzi IP esterni, GKE configura i nodi solo per accettare pacchetti le destinazioni corrispondono al primo indirizzo IPv6 (/128) della regola di forwarding Intervallo di /96.

Intervallo di indirizzi IPv6 statico Indirizzo IPv6 temporaneo intervallo
Subnet a doppio stack personalizzata
  • Deve trovarsi nella stessa rete VPC e nella stessa regione in un cluster Kubernetes.
  • Deve avere un intervallo di indirizzi IPv6 interno (tipo di accesso INTERNAL).
  • Deve essere specificato utilizzando la proprietà 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 doppio stack 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 temporanei: GKE utilizza un IPv6 /96 interno non allocato di indirizzi dall'IPv6 interno /64 della subnet del cluster di indirizzi IP esterni.

Subnet e indirizzo IPv4 per un servizio LoadBalancer esterno

Per i servizi LoadBalancer esterni solo IPv4 e a doppio stack, il protocollo un indirizzo email, indirizzo IPv4 esterno statico o 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. Uniforme tramite la regola di forwarding IPv6 del bilanciatore del carico di rete passthrough esterno utilizza un IPv6 /96 esterno di indirizzi IP esterni, GKE configura i nodi solo per accettare pacchetti le destinazioni corrispondono al primo indirizzo IPv6 (/128) della regola di forwarding Intervallo di /96.

Intervallo di indirizzi IPv6 statico Indirizzo IPv6 temporaneo intervallo
Subnet a doppio stack personalizzata
  • Deve trovarsi nella stessa rete VPC e nella stessa regione in un cluster Kubernetes.
  • Deve avere un intervallo di indirizzi IPv6 esterno (tipo di accesso EXTERNAL).
  • Deve essere specificato utilizzando la proprietà networking.gke.io/load-balancer-subnet.
 Subnet personalizzata e intervallo di indirizzi IPv6 statico: la subnet statica è stato creato un intervallo di indirizzi IPv6 /96 esterno in l'intervallo di indirizzi IPv6 /64 esterno della subnet personalizzata. Statica gli intervalli di indirizzi IPv6 esterni possono essere creati solo nel livello Premium. Subnet personalizzata e intervallo di indirizzi IPv6 temporanei: GKE utilizza un IPv6 /96 esterno non allocato intervallo di indirizzi dall'IPv6 esterno /64 della subnet personalizzata di indirizzi IP esterni.
Subnet a doppio stack del cluster
  • Deve avere un intervallo di indirizzi IPv6 esterno (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. Statica gli intervalli di indirizzi IPv6 esterni 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 networking.gke.io/internal-load-balancer-allow-global-access l'annotazione è true per un servizio LoadBalancer interno, GKE Abilita l'opzione di accesso globale sulla regola di forwarding del bilanciatore del carico di rete passthrough interno. Client situati in qualsiasi regione della rete VPC o di una rete connesse alla rete VPC del cluster possono accedere al carico con il bilanciatore del carico di rete passthrough esterno regionale.

Per ulteriori informazioni su come l'accesso globale si applica ai client in una connessione rete, 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. La Il controller GKE abilita tutte le porte sulla regola di forwarding il servizio ha più di cinque porte. Quando configuri una regola di forwarding da utilizzare tutte le porte, GKE crea solo regole firewall di autorizzazione in entrata porte specifiche configurate in spec.ports[].port nel servizio.

Per ulteriori informazioni sulle regole di forwarding del bilanciatore del carico di rete passthrough interno e su una porta valida specifiche, consulta Regole e porta di forwarding specifiche.

Servizio LoadBalancer a doppio stack 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 forwarding: una un indirizzo IPv4 e un altro 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 operazioni seguenti a seconda del tipo di bilanciatore del carico che utilizzi:

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

Limitazioni dei servizi LoadBalancer a doppio stack

  • I servizi LoadBalancer con indirizzi IPv6 sono supportati solo sui cluster con di tipo 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 stack singolo 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.