Questa pagina è stata tradotta dall'API Cloud Translation.

Cluster VPC nativi

Autopilot . . Standard

Questa pagina fornisce una panoramica generale delle in Google Kubernetes Engine (GKE).

Panoramica

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

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

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

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 dal peering di rete VPC.
Gli indirizzi IP dei pod vengono prenotati nella rete VPC prima che i pod creato nel tuo 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 dei pod non dipendono da route statiche personalizzate. Non consumano quota di 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 all'IP del pod di indirizzi IP esterni invece di indirizzi 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 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 un 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 Servizi che utilizzano intervalli distinti all'interno della subnet specificata, come descritto di seguito.

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 aggiuntivi di indirizzi IPv4 secondari della subnet configurazione multi-pod discontinuo CIDR.
Indirizzi IP del servizio: il cluster utilizza un IP secondario separato per tutti gli indirizzi di servizio (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 il doppio stack l'indirizzo IPv6 del nodo e tutti gli indirizzi IPv6 dei pod hanno origine dall'intervallo di indirizzi IPv6 /96 designato del nodo. L'indirizzo IP del nodo stesso è il primo /128 (indirizzo IPv6 singolo) in questo intervallo. Per ulteriori 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

Intervallo	Spiegazione	Esempio
Nodi	Gli indirizzi IP dei nodi vengono assegnati IP principale di indirizzi IP 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 limita il numero di nodi che un cluster può supportare. Consulta intervalli di limitazione dei nodi per ulteriori informazioni.	Se prevedi di creare un cluster di 900 nodi, l'intervallo di indirizzi IP principali la subnet del cluster deve essere almeno `/22` (2^(32-22) = 2¹⁰ = 1024 indirizzi). Di questi 1024 1020 sono utilizzabili perché quattro indirizzi IP indirizzi IP sono riservati in ogni intervallo di indirizzi IP principali. Fai riferimento a Subnet principale di indirizzi IP e IP secondario subnet di indirizzi IP esterni per i pod.
Pod	Gli indirizzi IP dei pod vengono presi dall'IP secondario della subnet del cluster di indirizzi IP esterni per i pod. 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 necessarie 900 × 256 = 230.400 indirizzi IP per i pod. (a ogni nodo viene allocato un alias intervallo IP 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¹⁸ = 262.144 indirizzi IP per i pod. Fai riferimento a Subnet secondaria di indirizzi IP per i pod.
Servizi	Gli indirizzi di servizio (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 sarà necessario specificare un proprio intervallo di indirizzi IP Servizi. Per maggiori dettagli, vedi 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. Intervallo A /20 di indirizzi IP restituisce 2^(32-20) = 2¹² = 4096 IP indirizzi IP esterni. Fai riferimento a Subnet secondaria Intervallo di indirizzi IP per i servizi per ulteriori informazioni.

Gli indirizzi IP dei nodi vengono assegnati IP principale di indirizzi IP 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 limita il numero di nodi che un cluster può supportare. Consulta intervalli di limitazione dei nodi per ulteriori informazioni.

Se prevedi di creare un cluster di 900 nodi, l'intervallo di indirizzi IP principali la subnet del cluster deve essere almeno /22 (2^(32-22) = 2¹⁰ = 1024 indirizzi). Di questi 1024 1020 sono utilizzabili perché quattro indirizzi IP indirizzi IP sono riservati in ogni intervallo di indirizzi IP principali.

Fai riferimento a Subnet principale di indirizzi IP e IP secondario subnet di indirizzi IP esterni per i pod.

Pod

Gli indirizzi IP dei pod vengono presi dall'IP secondario della subnet del cluster di indirizzi IP esterni per i pod. 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 necessarie 900 × 256 = 230.400 indirizzi IP per i pod. (a ogni nodo viene allocato un alias intervallo IP 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¹⁸ = 262.144 indirizzi IP per i pod.

Fai riferimento a Subnet secondaria di indirizzi IP per i pod.

Servizi

Gli indirizzi di servizio (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 sarà necessario specificare un proprio intervallo di indirizzi IP Servizi. Per maggiori dettagli, vedi 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. Intervallo A /20 di indirizzi IP restituisce 2^(32-20) = 2¹² = 4096 IP indirizzi IP esterni.

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

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

Consulta Abilita intervalli di indirizzi IP pubblici utilizzati privatamente per istruzioni sull'uso di questi intervalli.

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.

Devi conoscere i seguenti termini chiave per comprendere l'intervallo secondario metodi di assegnazione.

Assegnazione: l'assegnazione di intervalli di indirizzi IP è la procedura di allocazione di un intervallo di subnet specifico a un cluster nativo di VPC. Questo stabilisce un pool di indirizzi IP che i componenti possono utilizzare all'interno del cluster, ad esempio di 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 nei cluster GKE Standard che eseguono le versioni 1.29 e successive, GKE assegna indirizzi IP per i servizi di un intervallo gestito da GKE per impostazione predefinita: 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 un controllo completo sull'allocazione degli indirizzi IP, puoi gestire manualmente delle subnet del cluster nativo di VPC.

Puoi creare un indirizzo IP secondario della subnet , quindi crea un che utilizza questi intervalli. Durante la creazione del cluster, specifica la subnet per pod e servizi. Se crei manualmente gli intervalli secondari, devi gestirle autonomamente.

L'intervallo di indirizzi IP più ridotto che è possibile creare senza utilizzare CIDR multi-pod è /28, ma questo consente di creare solo 1 nodo con un massimo di 8 pod. Dovresti usare un intervallo abbastanza grande per il numero massimo di nodi di cui hai bisogno.

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

Fai riferimento alla tabella in Ottimizzare l'allocazione degli indirizzi IP per l'intervallo CIDR minimo utilizzabile per i diversi valori del 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 --max-pods-per-node per i pool di nodi.
Espandi l'intervallo di indirizzi IP del pod secondario utilizzando multi-pod discontinui CIDR.

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. Invece di specificare un singolo CIDR per pod e servizi insieme, devi scegliere o creare due IP secondari di indirizzi IP 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 progetto di servizio che crea un cluster deve avere almeno autorizzazioni a livello di 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 esempio che mostra come configurare un cluster nativo di VPC in una rete VPC condiviso, consulta le Configurazione di cluster con VPC condiviso

Pianificazione dell'intervallo di indirizzi IP

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

Intervallo di indirizzi IP principali della subnet

Quando pianifichi l'intervallo di indirizzi IP del nodo principale, considera le seguenti condizioni:

Ogni subnet deve avere un intervallo di indirizzi IP principali. 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 di indirizzi IP principali sono riservati in 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ù, 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 date le dimensioni dell'intervallo di indirizzi IP principali della subnet e la 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 intervallo IP principale	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	11 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 Dimensione massima per una subnet intervallo IP principale	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:

La subnet non deve contenere intervalli di indirizzi IP sovrapposti.
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 netmask può per i cluster che usano la subnet predefinita. Utilizza S per la dimensione della netmask, il cui intervallo valido è tra 8 e 29 inclusi.

N = 2^{(32 -S)} - 4
Calcola la dimensione 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 private-endpoint-subnetwork, puoi utilizzare le formule precedenti, ma riduci il valore di N di 1.

Intervallo di indirizzi IP secondari 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 tutti i cluster che utilizzano la subnet, date le dimensioni dell'IP secondario della subnet di indirizzi IP usati dai pod.

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

Intervallo IP secondario 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 Possibili 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 Dimensione predefinita per l'intervallo di indirizzi IP secondari 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 a cui un di indirizzi IP secondari per i pod di una subnet può supportare:

Calcola la dimensione della netmask dell'intervallo di pod di ciascun nodo, M.
M = 31 - ⌈log₂(Q)⌉ dove:
- Q è il numero di pod per nodo
- ⌈⌉ è la funzione massimale (meno intero), che significa arrotondare per eccesso al numero intero successivo
- Ad esempio, se Q è 110, allora M = 24
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 Pod, calcolati nel primo passaggio
- S è la dimensione della subnet mask dell'IP secondario della subnet intervallo di indirizzi
- Ad esempio, se M è 24 e S è 20, allora N = 16
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 un CIDR multi-pod discontinuo.

Intervallo di indirizzi IP secondari della subnet per i servizi

Pianifica con attenzione l'intervallo di indirizzi IP secondari per i servizi. Poiché anche questo è un intervallo di indirizzi IP secondari della subnet, questo intervallo non può essere modificato una volta creato il cluster.

Se utilizzi servizi multi-cluster, l'oggetto ServiceImport utilizza gli indirizzi IP dell'intervallo di indirizzi IP secondari 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 per i servizi di un intervallo gestito da GKE per impostazione predefinita: 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 Flag --services-ipv4-cidr o --services-secondary-range-name flag.
Se specifichi solo un intervallo size utilizzando il flag --services-ipv4-cidr (ad esempio /22), GKE utilizza ancora Intervallo gestito da GKE per ottenere il sottointervallo degli indirizzi.
GKE non crea un intervallo di indirizzi IP secondari separato Servizi quando viene utilizzato l'intervallo gestito da Google. L'intervallo gestito da GKE non utilizza la quota dell'intervallo di indirizzi IP secondari per la subnet.

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

Intervallo IP secondario per i servizi	Numero massimo di servizi
/28 Intervallo di indirizzi del servizio più piccolo possibile quando il metodo di assegnazione dell'intervallo secondario è gestito dall'utente	16 Servizi
/27 Intervallo di indirizzi del 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	1024 servizi
/21	2048 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	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 secondari per i pod di indirizzi IP secondari per i servizi tra i cluster nella 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 dei 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 secondari per i pod

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

La condivisione dell'intervallo di indirizzi IP secondari per i pod include quanto segue limitazioni:

Se condividi l'intervallo di indirizzi IP secondari per i pod 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.
Tra i diversi tipi di intervalli secondari, sia il parametro Gestita da GKE e intervalli di pod aggiuntivi non sono condivisibili tra i cluster.
Per condividere un intervallo IP secondario, passalo alla riga di comando con --cluster-secondary-range non puoi utilizzare un intervallo secondario condiviso durante la creazione di cluster nella UI.

Condivisione dell'intervallo di indirizzi IP secondari 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 per condividere un IPv4 secondario di subnet comune per i servizi, usa lo stesso intervallo di indirizzi IPv4 secondario della subnet quando crei ciascun 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 la classe interno all'intero intervallo di indirizzi IPv4 secondari della subnet per i servizi. L'IP per i servizi sono programmati all'interno di ciascun nodo del cluster, ma non assegnato all'interfaccia di rete di alcun nodo. Gli indirizzi IP dei servizi non sono instradabile all'interno della rete VPC del cluster. Indirizzi IP dei servizi utilizzabili solo dai pod client all'interno dello stesso cluster del servizio.

Quando un pod invia un pacchetto all'indirizzo IP di un servizio, il server iptables o eBPF sul nodo esegue la traduzione degli indirizzi di rete di destinazione (NAT), la modifica dell'indirizzo IP di destinazione del pacchetto dall'IP del servizio all'indirizzo IP di un pod di pubblicazione. Il pacchetto viene instradato in base all'indirizzo IP del pod di destinazione.

La condivisione dell'intervallo di indirizzi IP secondari per i servizi fornisce quanto segue 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 che corrispondono alla seguente regex:
```
^gke-.*-services-[abcdef0-9]{8}
```
Per condividere un intervallo di indirizzi IP secondari per i servizi, passalo alla riga di comando con --cluster-secondary-range non puoi utilizzare un intervallo secondario condiviso per i servizi quando crei cluster nella UI.

Intervalli di limitazione dei nodi

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

Il seguente messaggio di errore indica che l'IP principale della subnet di indirizzi IP o l'intervallo di indirizzi IP dei pod del cluster (l'intervallo di indirizzi l'intervallo di indirizzi IP 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 ulteriori informazioni, vedi Spazio di indirizzi IP libero insufficiente 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 stack singolo (solo IPv4 o IPv6) o indirizzi a doppio stack.

In GKE 1.24 o versioni successive, puoi abilitare il dual stack per i nuovi cluster GKE in modalità standalone in reti VPC condiviso. Puoi anche applicare criteri di rete con dual stack di networking abilitato.

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 limitazioni:

Il networking a doppio stack è disponibile solo per i cluster 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 per 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.
GKE 1.26.0-gke.2200 e successive supporta IPv6 (record AAAA) con Cloud DNS per operazioni interne al cluster e query DNS esterne.
I servizi a doppio stack sono supportati per i servizi ClusterIP, NodePort e LoadBalancer.

Il protocollo 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 La tabella seguente fornisce un riepilogo degli indirizzi IPv6 pubblici e privati con networking a doppio stack comportamento e configurazioni:

ipv6-access-type flag Assegnazione di indirizzi IP Intervallo di subnet

`ipv6-access-type` flag	Assegnazione di indirizzi IP	Intervallo di subnet
`EXTERNAL`	GKE assegna indirizzi IPv6 esterni che sono instradabili a 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`).

EXTERNAL

GKE assegna indirizzi IPv6 esterni che sono instradabili a 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.
Intervallo per nodo /96 dall'intervallo principale da utilizzare come di indirizzi IP del nodo primario.
Un intervallo per nodo /112 dall'IP del nodo primario da utilizzare come intervallo di indirizzi IP del pod per quel nodo. Con dual stack i pod ricevono gli indirizzi IPv6 dall'intervallo di indirizzi IP dei pod complessivo (simile ai nodi) e non dall'intervallo secondario per i pod prenotati con indirizzi IPv4.

L'intervallo complessivo di indirizzi IP del pod è composto da intervalli che non si sovrappongono: nell'intervallo IP del nodo primario. 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 come Google Cloud e GKE alloca 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 dell'intervallo di indirizzi IP del nodo primario e un intervallo /112 per l'indirizzo IP del pod intervallo. Il cluster ha anche un intervallo di indirizzi IP dei servizi secondari /112.

Servizi

Puoi creare un servizio IPv6 di tipo ClusterIP, NodePort o 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 esempio di come configurare un deployment.

Passaggi successivi

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