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 VPC.
Un cluster che utilizza route statiche personalizzate in una rete VPC viene chiamato cluster basato su route.
Vantaggi dei cluster nativi di VPC
I cluster nativi di VPC offrono diversi vantaggi:
Gli indirizzi IP dei pod sono instradabili in modo nativo all'interno della rete VPC del cluster e di altre reti VPC 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 evitano conflitti con altre risorse nella rete VPC e puoi pianificare meglio l'allocazione 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 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 della subnet in generale sono accessibili dalle reti on-premise connesse con Cloud VPN o Cloud Interconnect utilizzando i router Cloud.
Alcune funzionalità, ad esempio i gruppi di endpoint di rete (NEG), funzionano solo con i cluster nativi di VPC.
Modalità di rete del cluster predefinita
VPC nativa è la modalità di rete predefinita per tutti i cluster in GKE 1.21.0-gke.1500 e versioni successive. Per le versioni precedenti, la modalità di rete predefinita del cluster dipende da come crei il cluster.
La seguente tabella elenca la modalità di rete predefinita del cluster per le versioni dei cluster GKE e i 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 o Google Cloud CLI | Rete VPC nativa |
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 della subnet:
Allocazione degli indirizzi IPv4
I cluster nativi di VPC allocano indirizzi IPv4 per nodi, pod e servizi utilizzando intervalli distinti all'interno della subnet specificata come segue.
Indirizzi IP dei nodi: il cluster utilizza l'intervallo di indirizzi IPv4 principale 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 della subnet mediante la configurazione di CIDR multi-pod discontinui.
Indirizzi IP dei servizi: il cluster utilizza un intervallo di indirizzi IP secondari separato per tutti gli indirizzi IP del 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 i cluster GKE.
Allocazione 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
/96designato dal nodo. L'indirizzo IP del nodo stesso è il primo/128(indirizzo IPv6 singolo) in questo intervallo. Per ulteriori informazioni, consulta la sezione Networking a doppio stack.
La tabella seguente fornisce un riepilogo degli intervalli di indirizzi IP per nodi, pod e servizi:
| chiavi | 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. Consulta Intervalli di limitazione dei nodi per ulteriori informazioni. |
Se prevedi di creare un cluster di 900 nodi, l'intervallo di indirizzi IP principali della subnet del cluster deve essere almeno pari a Per ulteriori informazioni, 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 presi dall'intervallo di indirizzi IP secondari della subnet del cluster per i pod. A meno che non imposti un numero massimo di pod per nodo diverso, GKE alloca un intervallo IP alias (256 indirizzi) di |
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) = 218 = 262.144 indirizzi IP per i pod. Per ulteriori informazioni, consulta Intervallo di indirizzi IP secondari della subnet per i pod. |
| Servizi |
Gli indirizzi IP cluster vengono presi dall'intervallo di indirizzi IP secondari della subnet del cluster per i servizi. Devi assicurarti che questo intervallo sia sufficientemente ampio da fornire indirizzi per tutti i servizi Kubernetes che ospiti nel cluster. Nei cluster GKE Autopilot che eseguono la versione 1.27 e successive e nei cluster GKE Standard che eseguono la versione 1.29 e successive, GKE assegna gli indirizzi IP ai servizi GKE da un intervallo gestito da GKE: |
Per un cluster che esegue fino a 3000 servizi, hai bisogno di 3000 indirizzi IP del cluster. Ti serve un intervallo secondario di dimensione /20 o superiore. Un intervallo di indirizzi IP pari a /20 restituisce 2(32-20) = 212 = 4096 indirizzi IP. Per ulteriori informazioni, fai riferimento a Intervallo di indirizzi IP secondari della subnet per i servizi. |
Indirizzi IP interni
Gli indirizzi IP che utilizzi per le subnet del cluster nativo di VPC devono provenire da un intervallo di subnet valido. Gli intervalli validi includono indirizzi IP privati (RFC 1918 e altri) e indirizzi IP pubblici utilizzati privatamente. Consulta Intervalli validi e Intervalli limitati nella documentazione del VPC 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 da GKE o dall'utente.
Devi conoscere i seguenti termini chiave per comprendere i metodi di assegnazione dell'intervallo secondario.
Assegnazione: l'assegnazione di intervalli di indirizzi IP è il 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 di VPC.
Intervalli secondari gestiti da GKE (valore predefinito)
Per i cluster GKE Autopilot che eseguono la versione 1.27 e successive e i cluster GKE Standard che eseguono le versioni 1.29 e successive, GKE assegna per impostazione predefinita indirizzi IP ai servizi da un intervallo gestito da GKE: 34.118.224.0/20. In questo modo non sarà necessario specificare
il proprio 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. - 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 il sottointervallo degli indirizzi. - GKE non crea un intervallo di indirizzi IP secondari separato per i servizi quando viene utilizzato l'intervallo gestito da GKE.
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 e poi 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.
L'intervallo di indirizzi IP più piccolo che puoi creare senza utilizzare un CIDR multipod discontinuo è /28, ma questo intervallo ti consente di creare solo un nodo con un massimo di 8 pod. Dovresti utilizzare un intervallo abbastanza grande per il numero massimo di nodi che ti servono. 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 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-nodeper i pool di nodi. - Espandi l'intervallo di indirizzi IP del pod secondario utilizzando CIDR multi-pod discontinuo.
Differenze rispetto ai 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 insieme, devi scegliere o creare due intervalli di indirizzi IP secondari nella subnet del cluster: uno per i pod e un altro per i servizi.
Considerazioni sul VPC condiviso
Quando crei un cluster nativo di VPC in un ambiente VPC condiviso, un proprietario, un editor o un'entità Identity and Access Management (IAM) del progetto con il ruolo Amministratore di rete nel progetto host del VPC condiviso deve creare manualmente la subnet e gli intervalli di indirizzi IP secondari del cluster. Un amministratore del progetto di servizio che crea un cluster deve disporre almeno delle autorizzazioni a livello di subnet per la subnet nel progetto host della rete VPC condiviso.
In un ambiente VPC condiviso, gli intervalli di indirizzi IP secondari non possono essere gestiti da GKE. Un amministratore di rete nel progetto host del VPC condiviso deve creare 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 condivisa, consulta Configurazione di cluster con VPC condiviso.
Pianificazione dell'intervallo di indirizzi IP
Utilizza le informazioni 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
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 utilizzato da GKE 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 aver creato la subnet.
- I primi due e gli ultimi due indirizzi IP di un intervallo di indirizzi IP principali sono prenotati 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ù, 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 la dimensione 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 per l'intervallo IP principale 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 | 11 nodi |
| /22 | 1020 nodi | 1019 nodi |
| /21 | 2044 nodi | 2043 nodi |
| /20 Dimensione predefinita dell'intervallo IP principale di una subnet nelle reti in modalità automatica |
4092 nodi | 4091 nodi |
| /19 | 8188 nodi | 8187 nodi |
| /8 Dimensione massima per l'intervallo IP principale 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 espandere l'intervallo di indirizzi IP principali in qualsiasi momento, anche quando la subnet viene utilizzata da risorse Google Cloud come bilanciatori del carico e gruppi di endpoint di rete.
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 nei cluster che utilizzano la subnet predefinita. Utilizza S per la dimensione della netmask, il cui intervallo valido è compreso tra
8e29inclusi.N = 2(32 -S) - 4
Calcola la dimensione della netmask, S, necessaria per supportare un massimo di N nodi:
S = 32 - ⌈log2(N + 4)⌉
⌈⌉è la funzione massima (minimo numero intero), ovvero arrotondamento al numero intero successivo. L'intervallo valido per la dimensione della netmask, S, è compreso tra8e29inclusi.
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 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 in tutti i cluster che utilizzano la subnet, date le 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, 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 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 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 che l'intervallo di indirizzi IP secondari di una subnet per i pod può supportare:
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 massimale (meno intero), il che significa arrotondamento al numero intero successivo- Ad esempio, se Q è 110,
M = 24
Calcola il numero massimo di nodi, N, che l'intervallo di indirizzi IP secondari della subnet 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 secondari della subnet
- Ad esempio, se M è 24 e S è 20,
N = 16
Calcola il numero massimo di pod, P, che l'intervallo di indirizzi IP secondari della subnet per i pod può supportare:
P = N × Qdove:- 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 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 per i servizi.
Nei cluster GKE Autopilot che eseguono versione 1.27 e successive e nei cluster GKE Standard che eseguono le versioni 1.29 e successive, GKE assegna per impostazione predefinita indirizzi IP ai servizi da un intervallo gestito da GKE: 34.118.224.0/20. In questo modo non sarà necessario specificare
il proprio 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-cidro--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 il sottointervallo degli indirizzi. - GKE non crea un intervallo di indirizzi IP secondari separato per i servizi quando viene utilizzato l'intervallo gestito da GGKEoogle. L'intervallo gestito da GKE 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, in base alle 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 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 di servizio 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 e l'intervallo di indirizzi IP secondari per i servizi tra i cluster nella stessa subnet.
Questo comportamento è disponibile sia per i cluster Standard che per Autopilot.
Ti consigliamo di condividere gli 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 riutilizzandoli o condividendoli, soprattutto in un modello VPC condiviso. Può anche semplificare la gestione degli indirizzi IP per gli amministratori di rete, in quanto non richiede loro di creare subnet specifiche 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 viene 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ù cluster nativi VPC, un cluster può utilizzare una grande parte dell'intervallo di indirizzi IP condivisi, 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.
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 parte dell'intervallo di indirizzi IP condivisi, lasciando gli altri cluster senza un numero sufficiente di indirizzi IP per l'espansione.
Tra i diversi tipi di intervalli secondari, gli intervalli di pod gestiti da GKE e gli intervalli aggiuntivi non sono condivisibili tra i cluster.
Per condividere un intervallo IP secondario, passalo alla riga di comando con
--cluster-secondary-rangenon 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 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 ciascun cluster. Non è necessario un flag di configurazione separato per condividere un intervallo di indirizzi IPv4 comune per i servizi.
Quando si condivide un intervallo di indirizzi IPv4 comune per i servizi, ciascun 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 di ciascun nodo del cluster, ma non vengono assegnati all'interfaccia di rete di nessun nodo. Gli indirizzi IP dei servizi non sono instradabili all'interno della rete VPC del cluster. Gli indirizzi IP dei servizi possono essere utilizzati 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 Network Address Translation (NAT) di destinazione, modificando l'indirizzo IP di destinazione del pacchetto dall'indirizzo IP di servizio all'indirizzo IP 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 su una subnet
- Utilizza meno indirizzi IP
La condivisione dell'intervallo di indirizzi IP secondari per i servizi presenta le seguenti limitazioni:
- La condivisione dell'intervallo di indirizzi IP secondari per i servizi non è supportata con Cloud DNS nell'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-rangenon puoi utilizzare un intervallo secondario condiviso per i servizi durante la creazione di 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 dell'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) è 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 aggiungi nuovi indirizzi IP per i pod utilizzando il CIDR multipod discontinuo. Per ulteriori informazioni, consulta Spazio di indirizzi IP 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 indirizzi IPv4 che 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.
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ò è possibile perché non è prevista 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 in cui è abilitato GKE Dataplane V2.
- 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 sia IPv4 che IPv6 rispetto ai cluster solo IPv4. Considera questa caratteristica quando configuri 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,NodePorteLoadBalancer.
- 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 tabella seguente fornisce un riepilogo degli indirizzi IPv6 pubblici e privati con comportamento e configurazioni di rete a doppio stack:
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 |
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
A un cluster con networking a doppio stack IPv4/IPv6 sono allocati i seguenti intervalli:
- Un intervallo /64 per ogni subnet come intervallo principale.
- Un intervallo per nodo /96 dall'intervallo principale da utilizzare come intervallo di indirizzi IP del nodo primario.
Un intervallo per nodo /112 dall'intervallo di indirizzi IP del nodo primario da utilizzare come intervallo di indirizzi IP del pod per il nodo in questione. Con il networking a doppio stack, i pod ricevono i propri indirizzi IPv6 dall'intervallo di indirizzi IP dei pod complessivo (simili ai nodi) e non dall'intervallo secondario dei pod riservati agli indirizzi IPv4.
L'intervallo complessivo di indirizzi IP del pod è costituito da intervalli non sovrapposti dell'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 in che modo Google Cloud e GKE allocano 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 primario 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.
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 ciascuno di questi tipi di servizi, puoi definire i campi ipFamilies e
ipFamilyPolicy come IPv4, IPv6 o un
servizio
a doppio stack. Per ulteriori informazioni, vedi 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.