Cluster VPC nativi

Questa pagina fornisce una panoramica generale dei cluster nativi VPC in Google Kubernetes Engine (GKE).

Questa pagina è rivolta a Cloud Architect e a esperti di networking che progettano e progettano la rete per la propria organizzazione. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Panoramica

In GKE, i cluster possono essere distinti in base al modo in cui indirizzano il traffico da un pod all'altro.

Un cluster che utilizza intervalli di indirizzi IP alias è chiamato cluster nativo VPC.

Un cluster che utilizza route statiche personalizzate in una rete VPC è chiamato cluster basato su route.

Vantaggi dei cluster nativi di VPC

I cluster nativi di VPC offrono diversi vantaggi:

• Gli indirizzi IP dei pod sono instradabili in modo nativo all'interno della rete VPC del cluster e di altre reti VPC collegate tramite il peering di rete VPC.

• Gli indirizzi IP dei pod vengono riservati nella rete VPC prima che i pod vengano creati nel cluster. In questo modo si evitano conflitti con altre risorse nella rete VPC e puoi pianificare meglio le allocazioni degli indirizzi IP.

• Gli intervalli di indirizzi IP del pod non dipendono dalle route statiche personalizzate. Non consumano la quota per le route statiche personalizzate e generate dal sistema. Al loro posto, il routing per i cluster VPC-native viene gestito dalle route delle subnet generate automaticamente.

• Puoi creare regole firewall che si applicano solo agli intervalli di indirizzi IP dei pod anziché a qualsiasi indirizzo IP sui nodi del cluster.

• Gli intervalli di indirizzi IP dei pod e gli intervalli di indirizzi IP secondari delle subnet in generale sono accessibili dalle reti on-premise connesse a Cloud VPN o Cloud Interconnect tramite router Cloud.

• Alcune funzionalità, come i gruppi di endpoint di rete (NEG), funzionano solo con i cluster VPC-native.

Modalità di rete del cluster predefinita

VPC-native è la modalità di rete predefinita per tutti i cluster in GKE 1.21.0-gke.1500 e versioni successive. Per le versioni precedenti, la modalità di rete del cluster predefinita dipende da come viene creato il cluster.

La tabella seguente elenca la modalità di rete del cluster predefinita per le versioni e i metodi di creazione dei cluster GKE.

Puoi anche creare un cluster basato su route specificando il flag --no-enable-ip-alias al momento della creazione.

Intervalli di indirizzi IP per i cluster VPC nativi

Quando crei un cluster nativo di VPC, specifichi una subnet in una rete VPC. Il cluster utilizza i seguenti intervalli di indirizzi IP della subnet:

Allocazione degli indirizzi IPv4

I cluster nativi di VPC allocano indirizzi IPv4 per nodi, pod e servizi utilizzando intervalli distinti all'interno della subnet specificata come segue.

• Indirizzi IP dei nodi: il cluster utilizza l'intervallo di indirizzi IPv4 primario della subnet per assegnare indirizzi IP a tutti i nodi.

• Indirizzi IP dei pod: il cluster utilizza l'intervallo di indirizzi IPv4 secondario all'interno della subnet per tutti gli indirizzi IPv4 dei pod all'interno del cluster. Per una maggiore flessibilità, puoi utilizzare intervalli di indirizzi IPv4 secondari di subnet aggiuntivi configurando un CIDR multi-pod disgiunto.

• Indirizzi IP dei servizi: il cluster utilizza un intervallo di indirizzi IP secondario distinto per tutti gli indirizzi dei servizi (IP cluster). Per informazioni su come attivare la condivisione dello stesso intervallo IPv4 dei servizi per più cluster, consulta Condividere intervalli di indirizzi IP tra i cluster GKE.

Allocazione degli indirizzi IPv6 (networking dual-stack)

• Indirizzi IPv6 di nodi e pod: nei cluster abilitati per la rete a doppio stack, l'indirizzo IPv6 del nodo e tutti gli indirizzi IPv6 dei pod provengono dall'intervallo di indirizzi IPv6 /96 designato del nodo. L'indirizzo IP del nodo è il primo /128 (singolo indirizzo IPv6) all'interno di questo intervallo. Per ulteriori informazioni, consulta la sezione relativa alla networking dual-stack.

La tabella seguente fornisce un riepilogo degli intervalli di indirizzi IP per nodi, pod e servizi:

Indirizzi IP interni

Gli indirizzi IP che utilizzi per le subnet del cluster nativo di VPC devono provenire da un intervallo di subnet valido. Gli intervalli validi includono indirizzi IP privati (RFC 1918 e altri) e indirizzi IP pubblici utilizzati privatamente. Per ulteriori informazioni sugli intervalli di sottoreti validi, consulta Intervalli validi e Intervalli con limitazioni nella documentazione VPC.

Consulta Utilizzare intervalli di indirizzi IP privati non RFC 1918 per istruzioni su come attivare l'utilizzo di questi intervalli.

Per istruzioni sull'utilizzo di questi intervalli, consulta Abilitare intervalli di indirizzi IP pubblici utilizzati privatamente.

Metodi di assegnazione degli intervalli secondari

Puoi assegnare intervalli di indirizzi IP dei pod e intervalli di indirizzi dei servizi (ClusterIP) a un cluster nativo di VPC. Questi intervalli di indirizzi IP possono essere gestiti da GKE o dall'utente.

Per comprendere i metodi di assegnazione dell'intervallo secondario, devi conoscere i seguenti termini chiave.

Assegnazione: l'assegnazione di intervalli di indirizzi IP si riferisce al processo di allocazione di un intervallo di subnet specifico a un cluster nativo di VPC. Viene stabilito un pool di indirizzi IP che i componenti possono utilizzare all'interno del cluster, ad esempio pod e servizi.

Gestione: la gestione dell'intervallo di indirizzi IP si riferisce alle operazioni CRUD (creazione, aggiornamento, eliminazione, lettura) in corso a livello di cluster, pool di nodi o pod, relative agli intervalli di subnet assegnati e all'allocazione delle risorse all'interno del cluster nativo di VPC.

Intervalli secondari gestiti da GKE (valore predefinito)

Per i cluster GKE Autopilot che eseguono la versione 1.27 e successive e per i cluster GKE Standard che eseguono le versioni 1.29 e successive, per impostazione predefinita GKE assegna gli indirizzi IP per i servizi da un intervallo gestito da GKE: 34.118.224.0/20. In questo modo non è più necessario specificare il tuo proprio intervallo di indirizzi IP per i servizi. Si applicano le seguenti considerazioni:

• Se vuoi, puoi specificare intervalli personalizzati per i servizi utilizzando il flag --services-ipv4-cidr.
• Se specifichi solo una dimensione dell'intervallo utilizzando il flag --services-ipv4-cidr (ad esempio /22), GKE utilizza comunque l'intervallo gestito da GKE per ottenere l'intervallo parziale di indirizzi.
• GKE non crea un intervallo di indirizzi IP secondario separato per i servizi quando viene utilizzato l'intervallo gestito da GKE.

Gestita dall'utente

Per il controllo completo dell'allocazione degli indirizzi IP, puoi gestire manualmente le subnet del tuo cluster nativo di VPC.

Puoi creare gli intervalli di indirizzi IP secondari della subnet, quindi creare un cluster che li utilizzi. Durante la creazione del cluster, specifica il nome dell'intervallo della sottorete per i pod e i servizi. Se crei manualmente gli intervalli secondari, devi gestirli autonomamente.

L'intervallo di indirizzi IP più piccolo che puoi creare senza utilizzare il CIDR multi-pod disgiunto è /28, ma questo intervallo ti consente di creare solo un nodo con un massimo di 8 pod. Devi utilizzare un intervallo sufficientemente ampio per il numero massimo di nodi di cui hai bisogno.

L'intervallo minimo utilizzabile dipende anche dal numero massimo di pod per nodo.

Consulta la tabella in Ottimizzazione dell'allocazione degli indirizzi IP per l'intervallo CIDR minimo utilizzabile per diversi valori di pod massimi per nodo.

Se esaurisci l'intervallo di indirizzi IP per i pod, devi eseguire una delle seguenti operazioni:

• Crea un nuovo cluster con un intervallo di indirizzi dei pod più ampio.
• Ricrea i node pool dopo aver ridotto il valore --max-pods-per-node per i node pool.
• Espandi l'intervallo di indirizzi IP del pod secondario utilizzando il CIDR multi-pod disgiunto.

Differenze con i cluster basati su route

Lo schema di allocazione degli indirizzi di pod e servizio (ClusterIP) è diverso da quello utilizzato da un cluster basato su route. Anziché specificare un singolo CIDR per i pod e i servizi, devi scegliere o creare due intervalli di indirizzi IP secondari nella subnet del cluster: uno per i pod e un altro per i servizi.

Considerazioni sul VPC condiviso

Quando crei un cluster nativo di VPC in un ambiente VPC condiviso, un proprietario del progetto, un editor o un'entità IAM (Identity and Access Management) con il ruolo Amministratore di rete nel progetto host VPC condiviso deve creare manualmente la subnet e gli intervalli di indirizzi IP secondari del cluster. Un amministratore del progetto di servizio che crea un cluster deve disporre almeno delle autorizzazioni a livello di subnet per la subnet nel progetto host della rete VPC condiviso.

In un ambiente VPC condiviso, gli intervalli di indirizzi IP secondari non possono essere gestiti da GKE. Prima di poter creare il cluster, un amministratore di rete nel progetto host VPC condiviso deve creare la subnet e gli intervalli di indirizzi IP secondari. Per un example che mostra come configurare un cluster nativo di VPC in una rete VPC condivisa, consulta Configurazione di cluster con VPC condiviso.

Pianificazione degli intervalli di indirizzi IP

Utilizza le informazioni riportate nelle sezioni seguenti per calcolare le dimensioni degli intervalli di indirizzi IP principali e secondari della subnet utilizzata dal cluster.

Intervallo di indirizzi IP principale della subnet

Prendi in considerazione le seguenti condizioni quando pianifichi l'intervallo di indirizzi IP del nodo principale:

• Ogni subnet deve avere un intervallo di indirizzi IP principale. Si tratta dell'intervallo di indirizzi IP utilizzato da GKE per allocare indirizzi IP per i bilanciatori del carico e i nodi interni.
• Non puoi ridurre o modificare l'intervallo di indirizzi IP principale di una subnet dopo la sua creazione.
• I primi due e gli ultimi due indirizzi IP di un intervallo IP principale sono riservati da Google Cloud.
• I cluster con Private Service Connect utilizzano l'intervallo della subnet principale per eseguire il provisioning dell'indirizzo IP interno assegnato all'endpoint del piano di controllo. Tuttavia, puoi ignorare questo provisioning dell'indirizzo IP con il flag private-endpoint-subnetwork. Per saperne di più, vedi Creare un cluster e selezionare l'intervallo di indirizzi IP del piano di controllo.

La tabella seguente mostra il numero massimo di nodi che puoi creare in base alle dimensioni dell'intervallo di indirizzi IP principale della subnet e alla configurazione del cluster:

• Scenario 1: numero massimo di nodi in un cluster che utilizza la subnet predefinita.
• Scenario 2: numero massimo di nodi in un cluster Private Service Connect che non utilizza il flag private-endpoint-subnetwork.

Espandi l'intervallo di indirizzi IP principale

Se non hai più indirizzi IP nell'intervallo IP principale, puoi espandere l'intervallo IP principale in qualsiasi momento, anche quando le risorse Google Cloud, come i bilanciatori del carico e i gruppi di endpoint di rete, utilizzano la subnet.

Prima di espandere l'intervallo di indirizzi IP principale, tieni presente quanto segue:

• Non devono essere presenti intervalli di indirizzi IP sovrapposti nella subnet.
• GKE utilizza l'intervallo di indirizzi IP principale per allocare indirizzi IP per i bilanciatori del carico e i nodi interni.

Formule utili

Puoi utilizzare le seguenti formule per:

• Calcola il numero massimo di nodi, N, che una determinata subnet può supportare nei cluster che utilizzano la subnet predefinita. Utilizza S per la dimensione della subnet mask, il cui intervallo valido è compreso tra 8 e 29, inclusi.

  N = 2^{(32 -S)} - 4

• Calcola la dimensione della subnet mask, S, necessaria per supportare un massimo di N nodi:

  S = 32 - ⌈log₂(N + 4)⌉

  ⌈⌉ è la funzione ceil (intero minimo), che significa arrotondamento per eccesso al numero intero successivo. L'intervallo valido per la dimensione della maschera di rete, S, è compreso tra 8 e 29, inclusi.

Nei cluster Private Service Connect che non utilizzano il flag private-endpoint-subnetwork, puoi utilizzare le formule precedenti, ma ridurre il valore di N di 1.

Intervallo di indirizzi IP secondario della subnet per i pod

Pianifica con attenzione l'intervallo di indirizzi IP secondario per i pod.

La tabella seguente mostra il numero massimo di nodi e pod che puoi creare in tutti i cluster che utilizzano la subnet, in base alle dimensioni dell'intervallo di indirizzi IP secondario della subnet utilizzato dai pod.

Questa tabella presuppone che il numero massimo di pod per nodo sia 110, ovvero la densità del pod predefinita.

Se hai modificato il numero massimo di pod per nodo, puoi utilizzare le seguenti formule per calcolare il numero massimo di nodi e pod supportati dall'intervallo di indirizzi IP secondario per i pod di una subnet:

1. Calcola la dimensione della netmask dell'intervallo di pod di ogni nodo, M.
   M = 31 - ⌈log2(Q)⌉ dove:

   • Q è il numero di pod per nodo
   • ⌈⌉ è la funzione di soffitto (intero minimo), ovvero arrotondamento per eccesso al numero intero successivo
   • Ad esempio, se Q è 110, then M = 24

2. Calcola il numero massimo di nodi, N, supportato dall'intervallo di indirizzi IP secondario della subnet per i pod:
   N = 2(M - S) dove:

   • M è la dimensione della netmask dell'intervallo di indirizzi IP alias di ciascun nodo per i pod, calcolata nel primo passaggio
   • S è la dimensione della subnet mask dell'intervallo di indirizzi IP secondario della subnet
   • Ad esempio, se M è 24 e S è 20, allora N = 16

3. Calcola il numero massimo di pod, P, supportato dall'intervallo di indirizzi IP secondario per i pod della subnet:
   P = N × Q dove:

   • N è il numero massimo di nodi, calcolato nel passaggio precedente
   • Q è il numero di pod per nodo
   • Ad esempio, se N è 16 e Q è 110, allora P = 1760

Puoi aggiungere altri indirizzi IP per i pod utilizzando il CIDR multi-pod non contiguo.

Intervallo di indirizzi IP secondari della subnet per i servizi

Pianifica attentamente l'intervallo di indirizzi IP secondario per i servizi. Poiché si tratta anche di un intervallo di indirizzi IP secondari della sottorete, non può essere modificato dopo la creazione del cluster.

Se utilizzi servizi multi-cluster, l'oggetto ServiceImport utilizza gli indirizzi IP dell'intervallo IP secondario per i servizi.

Nei cluster GKE Autopilot che eseguono la versione 1.27 e successive e nei cluster GKE Standard che eseguono le versioni 1.29 e successive, per impostazione predefinita GKE assegna gli indirizzi IP per i servizi da un intervallo gestito da GKE: 34.118.224.0/20. In questo modo non è più necessario specificare il tuo proprio intervallo di indirizzi IP per i servizi. Si applicano le seguenti considerazioni:

• Se vuoi, puoi specificare intervalli personalizzati per i servizi utilizzando il --services-ipv4-cidr o il --services-secondary-range-name.
• Se specifichi solo una dimensione dell'intervallo utilizzando il flag --services-ipv4-cidr (ad esempio /22), GKE utilizza comunque l'intervallo gestito da GKE per ottenere l'intervallo di sottoindirizzi.
• GKE non crea un intervallo di indirizzi IP secondario separato per i servizi quando viene utilizzato l'intervallo gestito da Google. L'intervallo gestito da GKE non utilizza la quota dell'intervallo di indirizzi IP secondario per la tua subnet.

La tabella seguente mostra il numero massimo di servizi che puoi creare in un singolo cluster utilizzando la subnet, in base alle dimensioni dell'intervallo di indirizzi IP secondario della subnet per i servizi.

Condivisione di intervalli di indirizzi IP tra i cluster GKE

Puoi condividere l'intervallo principale, l'intervallo di indirizzi IP secondario per i pod e l'intervallo di indirizzi IP secondario per i servizi tra i cluster della stessa subnet.

Questo comportamento è disponibile sia per i cluster Standard che per quelli Autopilot.

Potresti voler condividere gli intervalli di indirizzi IP se hai un team centralizzato che gestisce l'infrastruttura per i cluster. Puoi ridurre il sovraccarico creando tre intervalli per pod, servizi e nodi e riutilizzandoli o condividendoli, soprattutto in un modello VPC condiviso. Inoltre, può semplificare la gestione degli indirizzi IP da parte degli amministratori di rete, in quanto non è necessario creare sottoreti specifiche per ogni cluster.

Condivisione dell'intervallo di subnet personalizzato per il piano di controllo

Per impostazione predefinita, GKE utilizza l'intervallo della subnet principale per eseguire il provisioning dell'endpoint interno del piano di controllo. Tuttavia, nei cluster con Private Service Connect, puoi configurare GKE in modo da eseguire il provisioning dell'endpoint interno da una subnet diversa che hai creato. Puoi condividere questa subnet con altri cluster o tra progetti se utilizzi la VPC condiviso.

Condivisione dell'intervallo di indirizzi IP principale per i nodi

Se crei più di un cluster nella subnet, l'intervallo di indirizzi IP principali per i nodi è condiviso per impostazione predefinita.

La condivisione dell'indirizzo IP principale per i nodi presenta le seguenti limitazioni:

• Se condividi l'intervallo di indirizzi IP principale per i nodi con due o più cluster nativi VPC, un cluster può utilizzare una porzione ampia dell' intervallo di indirizzi IP condiviso, lasciando gli altri cluster senza indirizzi IP sufficienti per espandersi.

Condivisione dell'intervallo di indirizzi IP secondario per i pod

Quando condividi l'intervallo secondario per i pod, ogni pod riceve comunque un indirizzo IP univoco.

La condivisione dell'intervallo di indirizzi IP secondario per i pod presenta le seguenti limitazioni:

• Se condividi l'intervallo di indirizzi IP secondario per i pod con due o più cluster nativi VPC, un cluster può utilizzare una porzione ampia dell'intervallo di indirizzi IP condiviso, lasciando gli altri cluster senza indirizzi IP sufficienti per espandersi.

• Tra i diversi tipi di intervalli secondari, sia quelli gestiti da GKE sia gli intervalli di pod aggiuntivi non sono condivisibili tra i cluster.

• Per condividere un intervallo di indirizzi IP secondario, passalo alla riga di comando con --cluster-secondary-range. Non puoi utilizzare un intervallo secondario condiviso durante la creazione di cluster nell'interfaccia utente.

Condivisione dell'intervallo di indirizzi IP secondario per i servizi

Due o più cluster possono utilizzare contemporaneamente lo stesso intervallo di indirizzi IPv4 secondari della subnet per i servizi quando utilizzi intervalli secondari gestiti dall'utente.

Per configurare due o più cluster in modo che condividano un intervallo di indirizzi IPv4 secondari della subnet comune per i servizi, utilizza lo stesso intervallo di indirizzi IPv4 secondari della subnet quando crei ogni cluster. Non è richiesto alcun flag di configurazione separato per condividere un intervallo di indirizzi IPv4 comune per i servizi.

Quando condividi un intervallo di indirizzi IPv4 comune per i servizi, ogni cluster utilizza internamente l'intero intervallo di indirizzi IPv4 secondario della subnet per i servizi. Gli indirizzi IP per i servizi sono programmati all'interno del nodo di ciascun cluster, ma non sono assegnati all'interfaccia di rete di nessun nodo. Gli indirizzi IP dei servizi non sono instradabili all'interno della rete VPC del cluster. Gli indirizzi IP dei servizi sono utilizzabili solo dai pod client nello stesso cluster del servizio.

Quando un pod invia un pacchetto a un indirizzo IP di un servizio, la configurazione iptables o eBPF sul nodo esegue la Network Address Translation (NAT) di destinazione, modificando l'indirizzo IP di destinazione del pacchetto dall'indirizzo IP del servizio a un indirizzo IP del pod di servizio. Il pacchetto viene indirizzato in base all'indirizzo IP del pod di destinazione.

La condivisione dell'intervallo di indirizzi IP secondario per i servizi offre i seguenti vantaggi:

• Riduci il numero di intervalli di indirizzi IP secondari univoci per i servizi creati su una subnet
• Utilizza meno indirizzi IP

La condivisione dell'intervallo di indirizzi IP secondario per i servizi presenta i seguenti limiti:

• La condivisione dell'intervallo di indirizzi IP secondari per i servizi non è supportata con Cloud DNS per GKE nell'ambito VPC.

• Non puoi condividere intervalli corrispondenti alla seguente regex:

  ^gke-.*-services-[abcdef0-9]{8}
  

• Per condividere un intervallo di indirizzi IP secondario per i servizi, passalo alla riga di comando con --cluster-secondary-range non puoi utilizzare un intervallo secondario condiviso per i servizi quando crei i cluster nell'interfaccia utente.

Intervalli di limitazione dei nodi

Il numero massimo di pod e servizi per un determinato cluster GKE è limitato dalle dimensioni degli intervalli secondari del cluster. Il numero massimo di nodi nel cluster è limitato dalle dimensioni dell'intervallo di indirizzi IP principale della subnet del cluster e dall'intervallo di indirizzi pod del cluster.

Il seguente messaggio di errore indica che l'intervallo IP primario della subnet o l'intervallo IP del pod del cluster (l'intervallo IP secondario della subnet per i pod) è esaurito:

Instance [node name] creation failed: IP space of [cluster subnet] is
exhausted

Puoi aggiungere altri indirizzi IP per i nodi espandendo la subnet principale o aggiungere nuovi indirizzi IP per i pod utilizzando CIDR multi-pod non contigui. Per saperne di più, consulta Spazio indirizzi IP non sufficiente per i pod.

Rete a doppio stack IPv4/IPv6

Con la rete a doppio stack IPv4/IPv6, puoi definire in che modo GKE alloca gli indirizzi IP (ipFamilies) ai seguenti oggetti:

• Per i pod e i nodi, GKE alloca sia indirizzi IPv4 sia indirizzi IPv6.
• Per i servizi, GKE alloca indirizzi a stack singolo (solo IPv4 o solo IPv6) o a doppio stack.

In GKE versione 1.24 o successive, puoi attivare la rete dual-stack per i nuovi cluster GKE su reti VPC autonome e condivise. Puoi anche applicare i criteri di rete con la rete dual-stack attivata. Se visualizzi errori di convalida durante l'attivazione della rete dual-stack sui cluster GKE di cui è stato eseguito l'upgrade dalle versioni 1.24 alle versioni 1.25 o 1.26, contatta il team di assistenza di Google Cloud.

Vantaggi

La rete dual-stack offre i seguenti vantaggi:

• Consente la comunicazione IPv6 end-to-end.
• Consente prestazioni migliori rispetto alla Network Address Translation (NAT) o al tunneling IP. Questo risultato viene ottenuto perché non esiste una traduzione da IPv6 a IPv4.

Disponibilità

La rete dual-stack con GKE presenta le seguenti limitazioni:

• Il networking dual-stack è disponibile solo per i cluster VPC nativi con GKE Dataplane V2 abilitato.
• La rete a doppio stack è supportata solo nelle subnet delle VPC in modalità personalizzata. Per ulteriori informazioni, consulta Tipi di reti VPC di Google Cloud.
• Gli indirizzi IPv6 a stack singolo per pod o nodi non sono supportati.
• I cluster a doppio stack consumano memoria aggiuntiva per nodo per supportare sia IPv4 che IPv6 rispetto ai cluster solo IPv4. Tieni conto di questa caratteristica quando configuri i cluster su larga scala.
• I cluster dual-stack non supportano l'accesso privato Google tramite IPv6.
• Le versioni GKE 1.26.0-gke.2200 e successive supportano IPv6 (record AAAA) con Cloud DNS per le operazioni interne al cluster e le query DNS esterne.
• I servizi dual-stack sono supportati per i servizi ClusterIP, NodePort e LoadBalancer.

• IPv6 non è supportato per i nodi Windows.

Tieni conto delle limitazioni precedenti prima di creare un cluster con la rete dual-stack. Per saperne di più, scopri come creare un cluster nativo di VPC con la rete dual-stack.

Assegnazione di indirizzi IPv6 pubblici e privati

La tabella seguente fornisce un riepilogo degli indirizzi IPv6 pubblici e privati con configurazioni e comportamenti di rete a doppio stack:

Per scoprire di più, consulta come utilizzare una rete dual-stack per un cluster nativo della VPC.

Architettura

Un cluster con rete a doppio stack IPv4/IPv6 ha gli intervalli seguenti allocati:

• Un intervallo /64 a ogni subnet come intervallo principale.
• Un intervallo per nodo di 96 bit dall'intervallo principale da utilizzare come intervallo di indirizzi IP del nodo principale.

• Un intervallo per nodo /112 dall'intervallo di indirizzi IP del nodo principale da utilizzare come intervallo di indirizzi IP del pod per quel nodo. Con la rete a doppio stack, i pod ricevono i propri indirizzi IPv6 dall'intervallo di indirizzi IP dei pod complessivo (in modo simile ai nodi) e non dall'intervallo secondario per i pod riservato agli indirizzi IPv4.

  L'intervallo di indirizzi IP del pod complessivo è costituito da intervalli non sovrapposti dell'intervallo di indirizzi IP del nodo principale. Pertanto, questo intervallo IP del pod non è contiguo.

• Un intervallo /112 da utilizzare per i servizi. Questo intervallo proviene da un intervallo /64 dell'intervallo di indirizzi privati di Google che è stato riservato per l'intervallo di indirizzi IP secondario dei servizi di GKE.

Il seguente diagramma mostra in che modo Google Cloud e GKE allocano gli indirizzi IPv6:

Nel diagramma, l'intervallo principale della subnet VPC è2600:1900:0:1::/64 e l'intervallo riservato per i servizi GKE è2600:2D00:0:4::0:0/64. Ogni nodo del cluster ha un intervallo /96 per l'intervallo di indirizzi IP del nodo principale e un intervallo /112 per l'intervallo di indirizzi IP del pod. Il cluster ha anche un intervallo di indirizzi IP secondario dei servizi /112.

Servizi

Puoi creare un servizio IPv4/IPv6 a doppio stack di tipo ClusterIP o NodePort. I nuovi cluster GKE che eseguono la versione 1.29 o successive supportano i servizi dual-stack di tipo LoadBalancer.

Puoi esporre un deployment con un servizio di tipo ClusterIP, NodePort o LoadBalancer. Per ciascuno di questi tipi di servizio, puoi definire i campi ipFamilies e ipFamilyPolicy come IPv4, IPv6 o come servizio dual-stack. Per ulteriori informazioni, consulta un esempio di come configurare un deployment.

Passaggi successivi

• Scopri di più sul peering di rete VPC.
• Scopri come creare un cluster nativo della VPC.

• Scopri di più sugli approfondimenti sull'utilizzo degli indirizzi IP di GKE.