Cluster VPC nativi

Autopilot Standard

---

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

Panoramica

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

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

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

Per i cluster GKE Autopilot, il routing del traffico VPC nativo è abilitato per impostazione predefinita.

Vantaggi dei cluster nativi di VPC

I cluster nativi di VPC hanno diversi vantaggi:

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

• Gli indirizzi IP dei pod vengono prenotati nella rete VPC prima della creazione dei pod nel cluster. In questo modo si evita il conflitto con altre risorse nella rete VPC e si può pianificare meglio le allocazioni degli indirizzi IP.

• Gli intervalli di indirizzi IP dei pod non dipendono da route statiche personalizzate. Non consumano la quota di route statiche personalizzate e generate dal sistema. Invece, le route di subnet generate automaticamente gestiscono il routing per i cluster nativi di VPC.

• 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 con Cloud VPN o Cloud Interconnect tramite i router Cloud.

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

Modalità di rete cluster predefinita

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

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

Versioni di GKE	Metodo di creazione del cluster	Modalità di rete cluster
Tutte le versioni	Nella console Google Cloud	Rete VPC nativa
1.21.0-gke.1500 e versioni successive	API Kubernetes Engine o Google Cloud CLI	Rete VPC nativa
Anteriori alla versione 1.21.0-gke.1500	API Kubernetes Engine o Google Cloud CLI	Basato su route

Puoi anche creare un cluster basato su route specificando il flag --no-enable-ip-alias quando crei il cluster.

Intervalli di indirizzi IP per cluster nativi di VPC

Quando crei un cluster nativo di VPC, specifichi una subnet in una rete VPC. Il cluster utilizza i seguenti intervalli di indirizzi IP delle 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 principali della subnet per assegnare indirizzi IP a tutti i nodi.

• Indirizzi IP dei pod: il cluster utilizza l'intervallo di indirizzi IPv4 secondari 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 aggiuntivi della subnet configurando un CIDR multi-pod distinto.

• Indirizzi IP di servizio: il cluster utilizza un intervallo di indirizzi IP secondari separato per tutti gli indirizzi di servizio (IP cluster). Per informazioni su come consentire a più cluster di condividere lo stesso intervallo IPv4 dei servizi, consulta Condivisione di intervalli di indirizzi IP tra cluster GKE.

Assegnazione degli indirizzi IPv6 (networking a doppio stack)

• Indirizzi IPv6 di nodi e pod: nei cluster abilitati per il networking a doppio stack, l'indirizzo IPv6 del nodo e tutti gli indirizzi IPv6 dei pod provengono dall'intervallo di indirizzi IPv6 /96 designato dal nodo. L'indirizzo IP del nodo stesso è il primo /128 (indirizzo IPv6 singolo) in questo intervallo. Per ulteriori informazioni, consulta la pagina relativa al networking a due stack.

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

Intervallo	Spiegazione	Esempio
Nodi	Gli indirizzi IP dei nodi vengono assegnati dall'intervallo di indirizzi IP principali della subnet associata al cluster. Sia gli indirizzi IP dei nodi sia la dimensione dell'intervallo di indirizzi IP secondari della subnet per i pod limitano il numero di nodi che un cluster può supportare. Per saperne di più, consulta la sezione Intervalli di limite dei nodi.	Se prevedi di creare un cluster di 900 nodi, l'intervallo di indirizzi IP principali della subnet del cluster deve essere almeno /22 (2^(32-22) = 2^10 = 1024 indirizzi). Di questi 1024 indirizzi, 1020 sono utilizzabili perché quattro indirizzi IP sono riservati in ogni intervallo di indirizzi IP principali. Per saperne di più, consulta Intervallo di indirizzi IP principali della subnet e Intervallo di indirizzi IP secondari della subnet per i pod.
i pod	Gli indirizzi IP dei pod vengono recuperati dall'intervallo di indirizzi IP secondari della subnet del cluster per i pod. A meno che tu non imposti un numero massimo di pod per nodo diverso, GKE alloca un /24 intervallo IP alias (256 indirizzi) a ciascun nodo per i pod in esecuzione. Su ciascun nodo, questi 256 indirizzi IP alias vengono utilizzati per supportare fino a 110 pod.	Per un cluster di 900 nodi che supporta fino a 110 pod per nodo, sono necessari 900 × 256 = 230.400 indirizzi IP per i pod. A ogni nodo è allocato un intervallo IP alias la cui dimensione della netmask è /24. Questo cluster richiede una subnet il cui intervallo IP secondario per i pod ha una subnet mask non superiore a /14. Questo intervallo IP secondario fornisce 2^(32-14) = 2^18 = 262.144 indirizzi IP per i pod. Per ulteriori informazioni, consulta Intervallo di indirizzi IP secondari della subnet per i pod.
Servizi	Gli indirizzi di servizio (IP cluster) vengono recuperati dall'intervallo di indirizzi IP secondari della subnet del cluster per i servizi. Devi assicurarti che questo intervallo sia abbastanza grande da fornire indirizzi per tutti i servizi Kubernetes ospitati nel tuo cluster. Nei nuovi cluster Autopilot che eseguono GKE versione 1.27 e successive, GKE assegna indirizzi IP per i servizi GKE da un intervallo gestito da Google: 34.118.224.0/20 per impostazione predefinita. In questo modo non sarà necessario specificare il tuo intervallo di indirizzi IP per i servizi. Per maggiori dettagli, consulta Intervallo di indirizzi IP secondari delle subnet per i servizi.	Per un cluster che esegue fino a 3000 servizi, sono necessari 3000 indirizzi IP del cluster. È necessario un intervallo secondario di dimensione /20 o superiore. Un intervallo /20 di indirizzi IP genera 2^(32-20) = 2^12 = 4096 indirizzi IP. Per ulteriori informazioni, consulta Intervallo di indirizzi IP secondari della subnet per i servizi.

Indirizzi IP interni

Gli indirizzi IP utilizzati 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. Consulta Intervalli validi e Intervalli limitati nella documentazione di VPC per ulteriori informazioni sugli intervalli di subnet validi.

Consulta Utilizzo di intervalli di indirizzi IP privati non RFC 1918 per le istruzioni su come abilitare l'utilizzo di questi intervalli.

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

Metodi di assegnazione dell'intervallo secondario

Puoi assegnare intervalli di indirizzi IP dei pod e intervalli di indirizzi di servizio (ClusterIP) a un cluster nativo di VPC. Questi intervalli di indirizzi IP possono essere gestiti da GKE o dagli utenti.

Per comprendere i metodi di assegnazione dell'intervallo secondario, devi comprendere 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. In questo modo 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 in corso (creazione, aggiornamento, eliminazione, lettura) 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 della VPC.

Intervalli secondari gestiti da GKE (predefinito)

Per impostazione predefinita, GKE assegna e gestisce gli indirizzi IP per i cluster nativi di VPC. Quando crei un cluster, non devi creare una subnet. Puoi definire un intervallo CIDR o la dimensione di una netmask sia per i pod sia per i servizi. GKE gestisce la creazione e la gestione degli intervalli di subnet. Ad esempio, puoi specificare 10.1.0.0/16 per i pod e 10.2.0.0/20 per i servizi oppure /16 per i pod e /20 per i servizi.

Per i cluster Autopilot che eseguono GKE 1.27 e versioni successive, GKE assegna gli indirizzi IP dei servizi da un intervallo gestito da Google per impostazione predefinita 34.118.224.0/20, eliminando la necessità di specificare un intervallo personale per i Servizi. Si applicano le seguenti considerazioni:

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

Gestita dall'utente

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

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

Attenzione: gli intervalli gestiti dall'utente consentono di utilizzare intervalli secondari di subnet più piccoli di quanto non sia possibile quando si utilizzano intervalli gestiti da GKE. Fai attenzione quando crei intervalli di indirizzi dei pod minori di /21, poiché potresti esaurire gli indirizzi IP dei pod man mano che il cluster cresce.

L'intervallo di indirizzi IP più piccolo che puoi creare senza utilizzare un CIDR multi-pod discreto è /28, ma questo intervallo ti consente di creare solo un nodo con un massimo di 8 pod. Dovresti usare un intervallo abbastanza grande per il numero massimo di nodi necessario. L'intervallo minimo utilizzabile dipende anche dal numero massimo di pod per nodo.

Fai riferimento alla tabella in Ottimizzazione dell'allocazione di indirizzi IP per l'intervallo CIDR minimo utilizzabile per i diversi valori di Numero massimo di pod 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 pool di nodi dopo aver ridotto il valore --max-pods-per-node per i pool di nodi.
• Espandi l'intervallo di indirizzi IP del pod secondario utilizzando un CIDR di più pod discontinui.

Differenze con i cluster basati su route

Lo schema di allocazione per gli indirizzi di pod e servizi (ClusterIP) è diverso da quello utilizzato da un cluster basato su route. Anziché specificare un unico CIDR per pod e 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 sui VPC condiviso

Quando crei un cluster nativo di VPC in un ambiente VPC condiviso, un proprietario, un editor o un'entità IAM (Identity and Access Management) del progetto con il ruolo Amministratore di rete nel progetto host del VPC condiviso deve creare manualmente gli intervalli di subnet e 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. Un amministratore di rete nel progetto host del VPC condiviso deve creare gli intervalli di indirizzi IP secondari e di subnet prima di poter creare il cluster. Per un esempio che mostra come configurare un cluster nativo di VPC in una rete VPC condivisa, consulta Configurazione dei cluster con un VPC condiviso.

Pianificazione dell'intervallo 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 principali della subnet

Ogni subnet deve avere un intervallo di indirizzi IP principali. Questo è l'intervallo di indirizzi IP che GKE utilizza per allocare indirizzi IP per nodi e bilanciatori del carico interni.

Non puoi ridurre o modificare l'intervallo di indirizzi IP principali di una subnet dopo la creazione della subnet.

I primi due e gli ultimi due indirizzi IP di un intervallo di indirizzi IP principali vengono prenotati da Google Cloud.

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

Intervallo IP principale subnet	Numero massimo di nodi
/29 Dimensione minima per l'intervallo IP principale di una subnet	4 nodi
/28	12 nodi
/27	28 nodi
/26	60 nodi
/25	124 nodi
/24	252 nodi
/23	508 nodi
/22	1020 nodi
/21	2044 nodi
/20 Dimensione predefinita dell'intervallo IP principale di una subnet nelle reti in modalità automatica	4092 nodi
/19	8188 nodi
/8 Dimensione massima per l'intervallo IP principale di una subnet	16.777.212 nodi

Espandi l'intervallo di indirizzi IP principali

Se esaurisci gli indirizzi IP nell'intervallo di indirizzi IP principali, puoi espandere l'intervallo di indirizzi IP principali in qualsiasi momento, anche quando le risorse Google Cloud, ad esempio bilanciatori del carico e gruppi di endpoint di rete, utilizzano la subnet.

Prima di espandere l'intervallo di indirizzi IP principali, considera quanto segue:

• La subnet non deve contenere intervalli di indirizzi IP sovrapposti.
• GKE usa l'intervallo di indirizzi IP principali per allocare indirizzi IP per nodi e bilanciatori del carico interni.

Formule utili

Puoi utilizzare le seguenti formule per:

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

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

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

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

  ⌈⌉ è la funzione soffitto (meno numero intero), ovvero arrotonda per eccesso al numero intero successivo. L'intervallo valido per la dimensione della netmask, S, è compreso tra 8 e 29 inclusi.

Intervallo di indirizzi IP secondari della subnet per i pod

Pianifica attentamente l'intervallo di indirizzi IP secondari 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 secondari della subnet utilizzato dai pod. Questa tabella presuppone che il numero massimo di pod per nodo sia 110, ovvero la densità predefinita dei pod.

Intervallo IP secondario delle subnet per i pod	Numero massimo di indirizzi IP di pod	Numero massimo di nodi	Numero massimo di pod
/24 Intervallo IP di pod più piccolo possibile quando il metodo di assegnazione dell'intervallo secondario è gestito dall'utente	256 indirizzi	1 nodo	Autopilot: 32 pod Standard: 110 pod
/23 Possibile solo quando il metodo di assegnazione dell'intervallo secondario è gestito dall'utente	512 indirizzi	2 nodi	Autopilot: 64 pod Standard: 220 pod
/22 Possibile solo quando il metodo di assegnazione dell'intervallo secondario è gestito dall'utente	1024 indirizzi	4 nodi	Autopilot: 128 pod Standard: 440 pod
/21 Intervallo IP di pod più piccolo possibile quando il metodo di assegnazione dell'intervallo secondario è gestito da GKE	2048 indirizzi	8 nodi	Autopilot: 256 pod Standard: 880 pod
/20	4096 indirizzi	16 nodi	Autopilot: 512 pod Standard: 1760 pod
/19	8192 indirizzi	32 nodi	Autopilot: 1024 pod Standard: 3520 pod
/18	16.384 indirizzi	64 nodi	Autopilot: 2048 pod Standard: 7040 pod
/17	32.768 indirizzi	128 nodi	Autopilot: 4096 pod Standard: 14.080 pod
/16	65.536 indirizzi	256 nodi	Autopilot: 8192 pod Standard: 28.160 pod
/15	131.072 indirizzi	512 nodi	Autopilot: 16.384 pod Standard: 56.320 pod
/14 Dimensione predefinita per l'intervallo IP secondario della subnet per i pod quando il metodo di assegnazione dell'intervallo secondario è gestito da GKE	262.144 indirizzi	1024 nodi	Autopilot: 32.768 pod Standard: 112.640 pod
/13	524.288 indirizzi	2048 nodi	Autopilot: 65.536 pod Standard: 225.280 pod
/12	1.048.576 indirizzi	4096 nodi	Autopilot: 131.072 pod Standard: 450.560 pod
/11	2.097.152 indirizzi	8192 nodi	Autopilot: 262.144 pod Standard: 901.120 pod
/10	4.194.304 indirizzi	16.384 nodi	Autopilot: 524.288 pod Standard: 1.802.240 pod
/9 L'intervallo di indirizzi dei pod più grande possibile	8.388.608 indirizzi	32.768 nodi	Autopilot: 1.048.576 pod Standard: 3.604.480 pod

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 secondari di una subnet per i pod:

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

   • Q è il numero di pod per nodo
   • ⌈⌉ è la funzione massima (meno numero intero), vale a dire arrotondare per eccesso al numero intero successivo
   • Ad esempio, se Q è 110, allora M = 24

2. Calcola il numero massimo di nodi, N, che può essere supportato dall'intervallo di indirizzi IP secondari 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 secondari della subnet
   • Ad esempio, se M è 24 e S è 20, allora N = 16

3. Calcola il numero massimo di pod, P, che l'intervallo di indirizzi IP secondari della subnet per i pod può supportare:
   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 discreto.

Intervallo di indirizzi IP secondari della subnet per i servizi

Pianifica attentamente l'intervallo di indirizzi IP secondari per i servizi. Poiché questo è anche un intervallo di indirizzi IP secondari della subnet, questo intervallo 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 nuovi cluster Autopilot che eseguono GKE versione 1.27 e successive, GKE assegna per impostazione predefinita indirizzi IP per i servizi da un intervallo gestito da Google: 34.118.224.0/20. In questo modo non sarà necessario specificare il tuo intervallo di indirizzi IP per i servizi. Si applicano le seguenti considerazioni:

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

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

Intervallo IP secondario per i servizi	Numero massimo di servizi
/28 Intervallo di indirizzi di servizio più piccolo possibile quando il metodo di assegnazione dell'intervallo secondario è gestito dall'utente	16 servizi
/27 Intervallo di indirizzi di servizio più piccolo possibile quando il metodo di assegnazione dell'intervallo secondario è gestito da GKE	32 Servizi
/26	64 Servizi
/25	128 servizi
/24	256 servizi
/23	512 servizi
/22	1.024 servizi
/21	2.048 servizi
/20 Dimensione predefinita per l'intervallo IP secondario della subnet per i servizi quando il metodo di assegnazione dell'intervallo secondario è gestito da GKE	4.096 servizi
/19	8.192 servizi
/18	16.384 servizi
/17	32.768 servizi
/16 Il più grande intervallo di indirizzi di servizio possibile	65.536 Servizi

Condivisione di intervalli di indirizzi IP tra cluster GKE

Puoi condividere l'intervallo di indirizzi IP principali, secondari per i pod e l'intervallo di indirizzi IP secondari per i servizi tra i cluster nella stessa subnet.

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

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

Condivisione dell'intervallo di indirizzi IP principali per i nodi

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

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

• Se condividi l'intervallo di indirizzi IP principali per i nodi con due o più cluster nativi VPC, un cluster può utilizzare una grande porzione dell'intervallo di indirizzi IP condiviso, lasciando gli altri cluster senza un numero sufficiente di indirizzi IP per l'espansione.

Condivisione dell'intervallo di indirizzi IP secondari per i pod

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

Nota: tra i diversi tipi di intervalli secondari, gli intervalli di pod aggiuntivi non sono condivisibili tra cluster.

La condivisione dell'intervallo di indirizzi IP secondari per i pod ha le seguenti limitazioni:

• Se condividi l'intervallo di indirizzi IP secondari per i pod con due o più cluster nativi VPC, un cluster può utilizzare una grande porzione dell'intervallo di indirizzi IP condiviso, lasciando gli altri cluster senza un numero sufficiente di indirizzi IP per l'espansione.

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

• Per condividere un intervallo IP secondario, passalo nella riga di comando con --cluster-secondary-range non puoi utilizzare un intervallo secondario condiviso durante la creazione dei cluster nella UI.

Condivisione dell'intervallo di indirizzi IP secondari 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 per condividere 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 è necessario un 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 secondari 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 di servizio non sono instradabili all'interno della rete VPC del cluster. Gli indirizzi IP del servizio sono utilizzabili solo dai pod client all'interno dello stesso cluster del servizio.

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

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

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

La condivisione dell'intervallo di indirizzi IP secondari per i servizi ha le seguenti limitazioni:

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

• Non puoi condividere intervalli che corrispondono alla seguente regex:

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

• Per condividere un intervallo IP secondario per i servizi, passalo nella riga di comando con --cluster-secondary-range. Non puoi utilizzare un intervallo secondario condiviso per i servizi durante la creazione dei cluster nella UI.

Intervalli di limitazione dei nodi

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

Il seguente messaggio di errore indica che l'intervallo di indirizzi IP principali della subnet o l'intervallo di indirizzi IP dei pod del cluster (l'intervallo di indirizzi IP secondari della subnet per i pod) è stato 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 il CIDR multi-pod discreto. Per maggiori informazioni, consulta Spazio di indirizzi IP libero insufficiente per i pod.

Reti a doppio stack IPv4/IPv6

Con il networking a doppio stack IPv4/IPv6, puoi definire la modalità di allocazione degli indirizzi IP (ipFamilies) da parte di GKE ai seguenti oggetti:

• Per pod e 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 1.24 o versioni successive, puoi abilitare il networking a doppio stack per i nuovi cluster GKE su reti VPC autonome e condivise. Puoi anche applicare criteri di rete con il networking a doppio stack abilitato.

Nota: se visualizzi errori di convalida quando abiliti il networking a doppio stack sui cluster GKE di cui è stato eseguito l'upgrade dalla versione 1.24 alle versioni 1.25 o 1.26, contatta il team di assistenza di Google Cloud.

Vantaggi

Il networking a due stack offre i seguenti vantaggi:

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

Disponibilità

Il networking a due stack con GKE ha le seguenti limitazioni:

• Il networking a due stack è disponibile solo per i cluster cluster nativi VPC in cui è abilitato GKE Dataplane V2.
• Il networking a due stack è supportato solo sulle subnet nei VPC in modalità personalizzata. Per saperne di più, 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 i cluster IPv4 che IPv6 rispetto ai cluster solo IPv4. Considera questa caratteristica durante la configurazione di cluster su larga scala.
• I cluster a doppio stack non supportano l'accesso privato Google su IPv6.
• Le versioni di GKE 1.26.0-gke.2200 e successive supportano IPv6 (record AAAA) con Cloud DNS per le operazioni interne del 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.

Prima di creare un cluster con networking a doppio stack, considera le limitazioni precedenti. Per ulteriori informazioni, scopri come creare un cluster nativo di VPC con networking a doppio stack.

Assegnazione di indirizzi IPv6 pubblico e privato

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

Flag ipv6-access-type	Assegnazione indirizzo IP	Intervallo di subnet
EXTERNAL	GKE assegna indirizzi IPv6 esterni instradabili su internet.	Da 2600:1900/28
INTERNAL	GKE assegna indirizzi IPv6 interni non instradabili su internet. I cluster con tipo di accesso IPv6 INTERNAL non possono accedere a internet tramite indirizzi IPv6. Cloud NAT non supporta gli indirizzi IPv6.	Da fd20::/20 (che è un sottoinsieme dell'intervallo ULA complessivo: fc00::/7).

Per saperne di più, consulta Come utilizzare una rete dual stack per un cluster nativo di VPC.

Architettura

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

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

• Un intervallo di indirizzi IP di /112 per nodo dall'intervallo di indirizzi IP del nodo principale da utilizzare come intervallo di indirizzi IP del pod per quel nodo. Con il networking a doppio stack, i pod ricevono gli indirizzi IPv6 dall'intervallo di indirizzi IP dei pod generali (simile ai nodi) e non dall'intervallo secondario per i pod riservati agli indirizzi IPv4.

  L'intervallo di indirizzi IP del pod complessivo è composto da intervalli non sovrapposti dall'intervallo IP del nodo principale. Di conseguenza, questo intervallo IP di pod è discontinuo.

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

Il seguente diagramma mostra in che modo Google Cloud e GKE assegnano 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 nel 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 dei servizi secondari /112.

Nota: GKE seleziona automaticamente l'intervallo di indirizzi IP IPv6 per l'intervallo di indirizzi IP del pod e l'intervallo di indirizzi IP dei servizi secondari.

Servizi

Puoi creare un servizio IPv6 di tipo ClusterIP, NodePort o LoadBalancer.

Puoi esporre un deployment con un servizio di tipo ClusterIP, NodePort o LoadBalancer. Per ognuno di questi tipi di servizi, puoi definire i campi ipFamilies e ipFamilyPolicy come servizio IPv4, IPv6 o a doppio 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 di VPC.
• Scopri di più sugli insight sull'utilizzo degli indirizzi IP di GKE.