Cluster VPC nativi

Autopilota Standard

---

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

Questa pagina è rivolta agli architetti cloud e agli esperti di networking che progettano e progettano la rete per la propria organizzazione. Per scoprire di più sui ruoli comuni e sulle attività di esempio 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.

Best practice:

Pianifica e progetta la configurazione del cluster con i Network Architect, gli amministratori di rete o altri team di tecnici di rete della tua organizzazione responsabili della definizione, dell'implementazione e della gestione dell'architettura di rete.

Vantaggi dei cluster nativi di VPC

I cluster nativi di VPC offrono diversi vantaggi:

• Pod Gli indirizzi IP sono instradabili in modo nativo all'interno alla rete VPC e ad altre reti VPC connesse 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 rete VPC e consente di pianificare meglio l'indirizzo IP allocazioni.

• 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. Invece, handle di route subnet generato automaticamente il routing per 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 della subnet in generale, sono accessibili da reti on-premise connesse tramite Cloud VPN o Cloud Interconnect Router Cloud.

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

Modalità di rete del cluster predefinita

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

La tabella seguente elenca la modalità di rete cluster predefinita per Versioni cluster GKE e metodi di creazione del cluster.

Versioni GKE	Metodo di creazione del cluster	Modalità di rete del cluster
Tutte le versioni	Nella console Google Cloud	Rete VPC nativa
1.21.0-gke.1500 e versioni successive	API Kubernetes Engine oppure Google Cloud CLI	Rete VPC nativa

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

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 il seguente indirizzo IP della subnet intervalli:

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'IPv4 principale della subnet per assegnare indirizzi IP a tutti i nodi.

• Indirizzi IP dei pod: il cluster utilizza l'intervallo di indirizzi IPv4 secondari nella subnet per tutti gli indirizzi IPv4 dei pod nel cluster. Per una maggiore flessibilità, puoi utilizzare intervalli di indirizzi IPv4 secondari della 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 che consente a più cluster di condividere lo stesso intervallo IPv4 dei servizi, consulta Condivisione di intervalli di indirizzi IP in GKE cluster.

Allocazione degli indirizzi IPv6 (networking a doppio 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 maggiori informazioni vedi le informazioni sul networking a doppio stack.

La tabella seguente 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 primario della subnet associata al cluster. Sia gli indirizzi IP dei nodi sia le dimensioni dell'intervallo di indirizzi IP secondario della subnet per i pod limitano il numero di nodi che un cluster può supportare. Per ulteriori informazioni, consulta gli intervalli di limiti dei nodi.	Se prevedi di creare un cluster di 900 nodi, l'intervallo di indirizzi IP principale della subnet del cluster deve essere di almeno /22 (2^(32-22) = 2^10 = 1024 indirizzi). Di questi 1024 1020 sono utilizzabili perché quattro indirizzi IP indirizzi IP sono riservati in ogni intervallo di indirizzi IP principali. Per ulteriori informazioni, consulta Intervallo di indirizzi IP primario della subnet e Intervallo di indirizzi IP secondario della subnet per i pod.
Pod	Gli indirizzi IP dei pod vengono ricavati dall'intervallo di indirizzi IP secondario per i pod della subnet del cluster. A meno che non imposti un valore numero massimo di pod per nodo, GKE alloca un /24 intervallo IP alias (256 indirizzi) a ciascuno per i pod in esecuzione. Su ciascun nodo, i 256 indirizzi IP alias e gli indirizzi IP 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 viene 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 secondario della subnet per i pod.
Servizi	Gli indirizzi dei servizi (IP cluster) vengono presi dalla subnet del cluster di indirizzi IP secondari per i servizi. Devi assicurarti che questo intervallo sia abbastanza grande da fornire indirizzi per tutti i servizi Kubernetes che ospiti nel tuo cluster. Nei cluster GKE Autopilot che eseguono la versione 1.27 e successivi e i cluster GKE Standard che eseguono la versione 1.29 e successive, GKE assegna indirizzi IP per GKE Servizi di un intervallo gestito da GKE: 34.118.224.0/20 per impostazione predefinita. In questo modo non è più necessario specificare il tuo intervallo di indirizzi IP per i servizi. Per maggiori dettagli, consulta Intervallo di indirizzi IP secondari della subnet per i servizi.	Per un cluster che esegue fino a 3000 servizi, hai bisogno di un IP cluster 3000 indirizzi IP esterni. Ti serve un intervallo secondario di dimensione /20 o superiore. Un intervallo /20 di indirizzi IP genera 2^(32-20) = 2^12 = 4096 indirizzi IP. Fai riferimento a Subnet secondaria Intervallo di indirizzi IP per i servizi per ulteriori informazioni.

Indirizzi IP interni

Gli indirizzi IP che utilizzi per le subnet del cluster nativo di VPC deve 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: Utilizzo di intervalli di indirizzi IP privati non RFC 1918 per istruzioni su come abilitare 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 del pod e intervalli di indirizzi di servizi (ClusterIP) a un cluster nativo di VPC. Questi intervalli di indirizzi IP possono essere gestiti GKE o gestita 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 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 alla gestione (creazione, aggiornamento, eliminazione, lettura) Operazioni CRUD a livello di cluster, pool di nodi a livello di pod o di pod, in base agli intervalli di subnet assegnati e all'allocazione delle risorse all'interno del tuo 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 sarà necessario specificare per i servizi. Si applicano le seguenti considerazioni:

• Puoi facoltativamente specificare intervalli personalizzati per i servizi utilizzando il metodo --services-ipv4-cidr flag.
• Se specifichi solo un intervallo size utilizzando il flag --services-ipv4-cidr (ad esempio, /22), GKE utilizza ancora l'intervallo gestito da GKE per ottenere il sottointervallo di indirizzi.
• GKE non crea un intervallo di indirizzi IP secondari separato 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 VPC.

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

Attenzione: gli intervalli gestiti dall'utente ti consentono di utilizzare intervalli secondari della subnet più piccoli di quanto sia possibile quando utilizzi gli intervalli gestiti da GKE. Presta attenzione quando creando intervalli di indirizzi dei pod più piccoli di /21, in quanto potresti esaurire gli indirizzi IP dei pod di lavoro man mano che il cluster cresce.

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 pool di nodi dopo aver ridotto --max-pods-per-node per i pool di nodi.
• Espandi l'intervallo di indirizzi IP del pod secondario utilizzando il CIDR multi-pod disgiunto.

Differenze rispetto ai cluster basati su route

Lo schema di allocazione per gli indirizzi di pod e servizi (ClusterIP) è diverso rispetto allo schema 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 una VPC condiviso un proprietario o un editor del progetto oppure un'entità IAM (Identity and Access Management) con il ruolo Amministratore rete nel progetto host del VPC condiviso deve creare gli intervalli di indirizzi IP secondari e la subnet 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 con GKE. Un amministratore di rete nel progetto host del VPC condiviso deve la subnet e gli intervalli di indirizzi IP secondari prima di poter creare il cluster. 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 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 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. Questo è l'intervallo di indirizzi IP che GKE utilizza per allocare gli indirizzi IP per il carico interno bilanciatori e nodi.
• Non puoi ridurre o modificare l'intervallo di indirizzi IP principali di una subnet dopo il è stata creata.
• 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 di subnet principale per eseguire il provisioning dell'indirizzo IP interno assegnato all'endpoint del piano di controllo. Tuttavia, puoi eseguire l'override del provisioning di questo indirizzo IP con il flag private-endpoint-subnetwork. Per saperne di più, consulta 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.

Intervallo IP principale subnet	Scenario 1	Scenario 2
/29 Dimensioni minime per l'intervallo IP primario di una subnet	4 nodi	3 nodi
/28	12 nodi	11 nodi
/27	28 nodi	27 nodi
/26	60 nodi	59 nodi
/25	124 nodi	123 nodi
/24	252 nodi	251 nodi
/23	508 nodi	507 nodi
/22	1020 nodi	1019 nodi
/21	2044 nodi	2043 nodi
/20 Dimensione predefinita dell'intervallo IP principale di una subnet in reti in modalità automatica	4092 nodi	4091 nodi
/19	8188 nodi	8187 nodi
/8 Dimensioni massime per l'intervallo IP primario di una subnet	16.777.212 nodi	16.777.211 nodi

Espandi l'intervallo di indirizzi IP principali

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

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

• Non devono essere presenti intervalli di indirizzi IP sovrapposti nella subnet.
• GKE utilizza l'intervallo di indirizzi IP principali per allocare gli 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 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 le dimensioni della netmask, S, necessaria per supportare un di N nodi:

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

  ⌈⌉ è il massimo (minimo numero intero) funzione, ovvero arrotondare per eccesso al numero intero successivo. L'intervallo valido per la dimensione La netmask, S, è compresa 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 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 secondario della subnet utilizzato dai pod.

Questa tabella presuppone che numero massimo di pod per nodo è 110, che è la densità predefinita dei pod.

Intervallo IP secondario della subnet per i pod	Numero massimo di indirizzi IP di pod	Numero massimo di nodi	Pod massimi
/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 Possibili 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 Dimensioni predefinite per l'intervallo di indirizzi 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 Intervallo di indirizzi dei pod più ampio 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 per i pod di una subnet:

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 soffitto (meno intero), che significa arrotondare per eccesso al numero intero successivo
   • Ad esempio, se Q è 110, then M = 24

2. Calcola il numero massimo di nodi, N, che la subnet di indirizzi IP secondari per i pod può supportare:
   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, di cui la subnet di indirizzi IP secondari per i pod può supportare:
   P = N × Q dove:

   • N è il numero massimo di nodi, calcolato nell'esperienza precedente passo
   • 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 GKE Standard che eseguono le versioni 1.29 e successive, GKE assegna indirizzi IP ai servizi di un intervallo gestito da GKE per impostazione predefinita: 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.

Intervallo IP secondario per i servizi	Numero massimo di servizi
/28 Minimo intervallo di indirizzi di servizio possibile quando il metodo di assegnazione dell'intervallo secondario è gestito dall'utente	16 servizi
/27 Minimo intervallo di indirizzi di servizio 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	1024 servizi
/21	2048 servizi
/20 Dimensioni predefinite per l'intervallo IP secondario della sottorete per i servizi quando il metodo di assegnazione dell'intervallo secondario è gestito da GKE	4096 servizi
/19	8192 servizi
/18	16.384 servizi
/17	32.768 servizi
/16 Intervallo di indirizzi dei servizi più ampio possibile	65.536 servizi

Condivisione degli 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 Standard che per Autopilot cluster.

Ti consigliamo di condividere gli intervalli di indirizzi IP se hai un team centralizzato che per la gestione dell'infrastruttura per i cluster. Puoi ridurre l'overhead creando e tre intervalli di valori per pod, servizi e nodi, per poi riutilizzarli o condividerli, in particolare in un modello VPC condiviso. Inoltre, semplifica la gestione agli amministratori di gestire gli indirizzi IP evitando di creare per ogni cluster.

Condivisione dell'intervallo di indirizzi IP principali 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 dei nodi presenta le seguenti limitazioni:

• Se condividi l'intervallo di indirizzi IP principali per i nodi con due o più per i cluster nativi di VPC, un cluster può utilizzare una grande parte di indirizzi IP condivisi, lasciando gli altri cluster senza un numero sufficiente di IP indirizzi IP esterni da espandere.

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.

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

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 IPv4 secondario della subnet per i servizi quando utilizzi l'intervallo di indirizzi gestito dall'utente intervalli di tempo.

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 instradabile 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 instradato 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 secondari per i servizi prevede quanto segue limitazioni:

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

• 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 CIDR multipod discontinuo. Per saperne di più, consulta Spazio di indirizzi IP non sufficiente per i pod.

Networking a doppio stack IPv4/IPv6

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

• Per pod e nodi, GKE alloca sia IPv4 che IPv6 indirizzi IP esterni.
• 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.

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

Vantaggi

Il networking a doppio stack offre i seguenti vantaggi:

• Abilita la comunicazione IPv6 end-to-end.
• Consente prestazioni migliori rispetto alla Network Address Translation (NAT) o al tunneling IP. Ciò si ottiene poiché non è disponibile la traduzione da IPv6 a IPv4.

Disponibilità

Il networking a doppio stack con GKE prevede le seguenti restrizioni:

• Il networking dual-stack è disponibile solo per i cluster VPC nativi con GKE Dataplane V2 abilitato.
• Il networking a doppio stack è supportato solo sulle subnet nei 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 entrambi gli indirizzi IPv4 e IPv6 rispetto ai cluster solo IPv4. Tieni presente questa caratteristica durante la configurazione e cluster su larga scala.
• I cluster a doppio stack non supportano l'accesso privato Google su 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 a doppio stack sono supportati per i servizi ClusterIP, NodePort e LoadBalancer.

• IPv6 non è supportato per i nodi Windows.

Considera le limitazioni precedenti prima di creare un cluster con networking a doppio stack. Per ulteriori informazioni, scopri come creare un cluster nativo di VPC con networking a doppio 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:

ipv6-access-type flag	Assegnazione di indirizzi IP	Intervallo di subnet
EXTERNAL	GKE assegna indirizzi IPv6 esterni che possono essere instradati su internet.	Da 2600:1900/28
INTERNAL	GKE assegna indirizzi IPv6 interni che non sono instradabili a 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ù, scopri come utilizzare una rete a doppio stack per un cluster nativo di VPC.

Architettura

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

• Un intervallo /64 per 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'IP del nodo primario 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. 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 di 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 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 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 secondario dei servizi.

Servizi

È possibile creare un servizio a doppio stack IPv4/IPv6 di tipo ClusterIP o NodePort. Nuovi cluster GKE che eseguono la versione 1.29 o successive con supporto Servizi dual-stack di tipo LoadBalancer

Puoi esporre un deployment con un servizio di tipo ClusterIP, NodePort, LoadBalancer. Per ognuno di questi tipi di servizi, puoi definire ipFamilies e Campi ipFamilyPolicy come IPv4, IPv6 o stack doppio assistenza. 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.