Questa pagina fornisce una panoramica generale dei cluster VPC nativi in Google Kubernetes Engine (GKE).
Questa pagina è rivolta agli architetti cloud e agli specialisti di networking che progettano e realizzano l'architettura di rete per la loro organizzazione. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli e attività comuni degli utenti GKE. Google Cloud
Panoramica
In GKE, i cluster possono essere distinti in base al modo in cui instradano il traffico da un pod a un altro.
Un cluster che utilizza intervalli di indirizzi IP alias è chiamato cluster nativo di VPC. Un cluster che utilizza route statiche personalizzate in una rete VPC è denominato cluster basato su route.
Pianifica e progetta la configurazione del cluster con gli architetti di rete, gli amministratori di rete o qualsiasi altro team di ingegneri di rete della tua organizzazione responsabile della definizione, dell'implementazione e della manutenzione dell'architettura di rete.
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 che vi sono collegate tramite il peering di rete VPC.
Gli indirizzi IP dei pod vengono riservati nella rete VPC prima che i pod vengano creati nel cluster. In questo modo si evita il conflitto con altre risorse nella rete VPC e si pianificano meglio le allocazioni degli indirizzi IP.
Gli intervalli di indirizzi IP del pod non dipendono dalle route statiche personalizzate. Non consumano la quota di route statiche personalizzate e generate dal sistema. Al contrario, le route di subnet generate automaticamente gestiscono il routing per i cluster VPC nativi.
Puoi creare regole firewall che si applicano solo agli intervalli di indirizzi IP dei pod anziché a qualsiasi indirizzo IP sui nodi del cluster.
Gli intervalli di indirizzi IP dei pod e gli intervalli di indirizzi IP secondari delle subnet in generale sono accessibili dalle reti on-premise connesse a Cloud VPN o Cloud Interconnect utilizzando i router Cloud.
Alcune funzionalità, come i gruppi di endpoint di rete (NEG), funzionano solo con i cluster VPC nativi.
Modalità di rete del cluster predefinita
VPC nativo è la modalità di rete predefinita per tutti i cluster in GKE 1.21.0-gke.1500 e versioni successive. Per le versioni precedenti, la modalità di rete del cluster predefinita dipende da come crei il cluster.
La seguente tabella elenca la modalità di rete del cluster predefinita per le versioni dei cluster GKE e i metodi di creazione dei cluster.
| Versioni di GKE | Metodo di creazione del cluster | Modalità di rete del cluster |
|---|---|---|
| Tutte le versioni | La console Google Cloud | Rete VPC nativa |
| 1.21.0-gke.1500 e versioni successive | API GKE 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 i cluster VPC nativi
Quando crei un cluster nativo di VPC, specifichi una subnet in una rete VPC. Il cluster utilizza i seguenti intervalli di indirizzi IP della subnet:
Allocazione degli indirizzi IPv4
I cluster nativi di VPC allocano indirizzi IPv4 per nodi, pod e servizi utilizzando intervalli distinti all'interno della subnet specificata nel seguente modo.
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 secondario all'interno della subnet per tutti gli indirizzi IPv4 dei pod all'interno del cluster. Per una maggiore flessibilità, puoi utilizzare intervalli di indirizzi IPv4 secondari della subnet aggiuntivi configurando il CIDR multi-pod discontinuo.
Indirizzi IP del servizio: il cluster utilizza un intervallo di indirizzi IP secondari separato per tutti gli indirizzi del servizio (IP cluster). Per informazioni su come consentire a più cluster di condividere lo stesso intervallo IPv4 di servizi, consulta Condividere intervalli di indirizzi IP tra cluster GKE.
Assegnazione di indirizzi IPv6 (rete dual-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 del nodo. L'indirizzo IP del nodo stesso è il primo/128(singolo indirizzo IPv6) all'interno di questo intervallo. Per ulteriori informazioni, consulta la sezione Networking dual-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 principale della subnet associata al cluster. Sia gli indirizzi IP dei nodi sia la dimensione dell'intervallo di indirizzi IP secondari della subnet per i pod limitano il numero di nodi che un cluster può supportare. Per ulteriori informazioni, consulta intervalli di limitazione dei nodi. |
Se prevedi di creare un cluster di 900 nodi, l'intervallo di indirizzi IP primari della subnet del cluster deve essere almeno un Per saperne di più, consulta Intervallo di indirizzi IP principali della subnet e Intervallo di indirizzi IP secondari della subnet per i pod. |
| Pod |
Gli indirizzi IP dei pod vengono presi dall'intervallo di indirizzi IP secondario
della subnet del cluster per i pod. A meno che tu non imposti un
numero massimo
diverso di pod per nodo, GKE alloca un
intervallo IP alias (256 indirizzi) a ogni
nodo per i pod in esecuzione. |
Per un cluster di 900 nodi che supporta fino a 110 pod per nodo, hai bisogno di 900 × 256 = 230.400 indirizzi IP per i pod. A ogni nodo viene allocato un intervallo IP alias la cui netmask ha dimensioni /24. Questo cluster richiede una subnet il cui intervallo IP secondario per i pod abbia una subnet mask non superiore a /14. Questo intervallo IP secondario fornisce 2(32-14) = 218 = 262.144 indirizzi IP per i pod. Per saperne di più, consulta Intervallo di indirizzi IP secondario della subnet per i pod. |
| Servizi |
Gli indirizzi del servizio (IP cluster) vengono presi dall'intervallo di indirizzi IP secondario della subnet del cluster 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 successive e nei cluster GKE Standard che eseguono la versione 1.29 e successive, GKE assegna indirizzi IP per i servizi GKE da un intervallo gestito da GKE: |
Per un cluster che esegue fino a 3000 servizi, hai bisogno di 3000 indirizzi IP cluster. Devi avere un intervallo secondario di dimensioni /20 o superiore. Un intervallo /20 di indirizzi IP genera 2(32-20) = 212 = 4096 indirizzi IP. Per saperne di più, consulta Intervallo di indirizzi IP secondari della subnet per i servizi. |
Indirizzi IP interni
Gli indirizzi IP utilizzati per le subnet del cluster nativo di VPC devono provenire da un intervallo di subnet valido. Gli intervalli validi includono indirizzi IP privati (RFC 1918 e altri) e indirizzi IP pubblici utilizzati privatamente. Per ulteriori informazioni sugli intervalli di subnet validi, consulta le sezioni Intervalli validi e Intervalli con limitazioni nella documentazione di VPC.
Consulta Utilizzo di intervalli di indirizzi IP privati non RFC 1918 per istruzioni sull'attivazione dell'utilizzo di questi intervalli.
Per istruzioni sull'utilizzo di questi intervalli, consulta Abilitare intervalli di indirizzi IP pubblici utilizzati privatamente.
Metodi di assegnazione dell'intervallo secondario
Puoi assegnare intervalli di indirizzi IP di pod e di servizi (ClusterIP) a un cluster nativo di VPC. Questi intervalli di indirizzi IP possono essere gestiti da GKE o dall'utente.
Per comprendere i metodi di assegnazione dell'intervallo secondario, devi conoscere i seguenti termini chiave.
Assegnazione: l'assegnazione di intervalli di indirizzi IP si riferisce al processo di allocazione di un intervallo di subnet specifico a un cluster nativo di VPC. In questo modo viene creato un pool di indirizzi IP che i componenti possono utilizzare all'interno del cluster, ad esempio pod e servizi.
Gestione: la gestione dell'intervallo di indirizzi IP si riferisce alle operazioni CRUD (creazione, aggiornamento, eliminazione, lettura) continue 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 (impostazione predefinita)
Per i cluster GKE Autopilot che eseguono la versione 1.27 e successive e
i cluster GKE Standard che eseguono la versione 1.29 e successive,
GKE assegna gli indirizzi IP per i servizi da un intervallo gestito da GKE
per impostazione predefinita: 34.118.224.0/20. In questo modo non è più necessario specificare
il tuo intervallo di indirizzi IP per i servizi. Si applicano le seguenti considerazioni:
- Puoi specificare facoltativamente 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 di 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 dell'allocazione degli indirizzi IP, puoi gestire manualmente le subnet del cluster nativo di VPC.
Puoi creare gli intervalli di indirizzi IP secondari della subnet, quindi creare un cluster che utilizzi questi intervalli. Durante la creazione del cluster, specifica il nome dell'intervallo di subnet per pod e servizi. Se crei manualmente gli intervalli secondari, devi gestirli autonomamente.
L'intervallo di indirizzi IP più piccolo che puoi creare senza utilizzare il CIDR multi-pod discontinuo è /28, ma questo intervallo ti consentirebbe di creare un solo nodo con un massimo di 8 pod. Devi utilizzare un intervallo sufficientemente ampio per il numero massimo di nodi di cui hai bisogno.
L'intervallo minimo utilizzabile dipende anche dal numero massimo di pod per nodo.
Consulta la tabella in Ottimizzazione dell'allocazione degli indirizzi IP per l'intervallo CIDR minimo utilizzabile per diversi valori di pod massimi per nodo.
Se esaurisci l'intervallo di indirizzi IP per i pod, devi eseguire una delle seguenti operazioni:
- Crea un nuovo cluster con un intervallo di indirizzi dei pod più ampio.
- Ricrea i node pool dopo aver diminuito il valore di
--max-pods-per-nodeper i node pool. - Espandi l'intervallo di indirizzi IP del pod secondario utilizzando il CIDR multi-pod discontinuo.
Differenze rispetto ai cluster basati su route
Lo schema di allocazione per gli indirizzi di pod e servizi (ClusterIP) è diverso dallo schema utilizzato da un cluster basato su route. Anziché specificare un singolo 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 uno 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 principal Identity and Access Management (IAM) con il ruolo Network Admin nel progetto host VPC condiviso deve creare manualmente la subnet e gli intervalli di indirizzi IP secondari del cluster. Un amministratore del progetto di servizio che crea un cluster deve disporre almeno delle autorizzazioni a livello di subnet per la subnet nel progetto host della rete VPC condiviso.
In un ambiente VPC condiviso, gli intervalli di indirizzi IP secondari non possono essere gestiti da GKE. 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 primari e secondari della subnet utilizzata dal cluster.
Intervallo di indirizzi IP principali della subnet
Quando pianifichi l'intervallo di indirizzi IP del nodo primario, 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 indirizzi IP per bilanciatori del carico e nodi interni.
- Non puoi ridurre o modificare l'intervallo di indirizzi IP principali di una subnet dopo la creazione della subnet.
- I primi due e gli ultimi due indirizzi IP di un intervallo di indirizzi IP principali sono riservati da Google Cloud.
- I cluster con Private Service Connect utilizzano l'intervallo di subnet primaria
per eseguire il provisioning dell'indirizzo IP interno assegnato all'endpoint del control plane. 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 control plane.
La seguente tabella mostra il numero massimo di nodi che puoi creare in base alle dimensioni dell'intervallo di indirizzi IP primari 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 della 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 | 507 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 le risorse Google Cloud , come i bilanciatori del carico e i gruppi di endpoint di rete, utilizzano la subnet.
Prima di espandere l'intervallo di indirizzi IP primari, tieni presente quanto segue:
- Non devono esserci intervalli di indirizzi IP sovrapposti nella subnet.
- GKE utilizza l'intervallo di indirizzi IP principale per allocare gli indirizzi IP per i bilanciatori del carico interni e i nodi.
Formule utili
Puoi utilizzare le seguenti formule per:
Calcola il numero massimo di nodi, N, che una determinata maschera di rete può supportare nei cluster che utilizzano la subnet predefinita. Utilizza S per la dimensione della maschera di rete, il cui intervallo valido è compreso tra
8e29inclusi.N = 2(32 -S) - 4
Calcola la dimensione della maschera di rete, S, necessaria per supportare un massimo di N nodi:
S = 32 - ⌈log2(N + 4)⌉
⌈⌉è la funzione CEILING (intero più piccolo), che arrotonda per eccesso 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
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 seguente tabella mostra il numero massimo di nodi e pod che puoi creare in tutti i cluster che utilizzano la subnet, data la dimensione dell'intervallo di indirizzi IP secondari della subnet utilizzato dai pod.
Questa tabella presuppone che il numero massimo di pod per nodo sia 110, ovvero la densità del pod predefinita.
| Intervallo IP secondario della subnet per i pod | Numero massimo di indirizzi IP del pod | Numero massimo di nodi | Numero massimo di pod |
|---|---|---|---|
| /24 Il più piccolo intervallo IP di pod 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 Il più piccolo intervallo IP dei pod 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 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 Pods |
| /10 | 4.194.304 indirizzi | 16.384 nodi |
Autopilot: 524.288 pod Standard: 1.802.240 pod |
| /9 Intervallo di indirizzi dei pod più grande possibile |
8.388.608 indirizzi | 32.768 nodi |
Autopilot: 1.048.576 pod Standard: 3.604.480 pod |
Se hai modificato il numero massimo di pod per nodo, puoi utilizzare le seguenti formule per calcolare il numero massimo di nodi e pod che un intervallo di indirizzi IP secondari di una subnet per i pod può supportare:
Calcola la dimensione della maschera di rete dell'intervallo di pod di ogni nodo, M.
M = 31 - ⌈log2(Q)⌉dove:- Q è il numero di pod per nodo
⌈⌉è la funzione di arrotondamento per eccesso (numero intero più piccolo), ovvero arrotonda per eccesso al numero intero successivo- Ad esempio, se Q è 110, allora
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, allora
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 il CIDR multi-pod non contiguo.
Intervallo di indirizzi IP secondari della subnet per i servizi
Pianifica con attenzione l'intervallo di indirizzi IP secondari per i servizi. Poiché si tratta anche di un intervallo di indirizzi IP secondari della subnet, questo intervallo non può essere modificato dopo la creazione del cluster.
Se utilizzi i
servizi multicluster,
l'oggetto ServiceImport utilizza indirizzi IP dell'intervallo di indirizzi IP secondario per i
servizi.
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 indirizzi IP per i servizi da un intervallo gestito da GKE
per impostazione predefinita: 34.118.224.0/20. In questo modo non è più necessario specificare
il tuo intervallo di indirizzi IP per i servizi. Si applicano le seguenti considerazioni:
- Puoi specificare facoltativamente intervalli personalizzati per i servizi utilizzando il flag
--services-ipv4-cidro il flag--services-secondary-range-name. - Se specifichi solo un size dell'intervallo utilizzando il flag
--services-ipv4-cidr(ad esempio,/22), GKE utilizza comunque l'intervallo gestito da GKE per ottenere il sottointervallo di indirizzi. - GKE non crea un intervallo di indirizzi IP secondari separato per i servizi quando viene utilizzato l'intervallo gestito da Google. L'intervallo gestito da 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, data la dimensione dell'intervallo di indirizzi IP secondari della subnet per i servizi.
| Intervallo IP secondario per i servizi | Numero massimo di servizi |
|---|---|
| /28 Il più piccolo intervallo di indirizzi di emergenza possibile quando il metodo di assegnazione dell'intervallo secondario è gestito dall'utente |
16 servizi |
| /27 Il più piccolo 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 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ù grande possibile |
65.536 servizi |
Condivisione di intervalli di indirizzi IP tra 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 quelli Autopilot.
Potresti voler 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. Inoltre, può semplificare la gestione degli indirizzi IP per gli amministratori di rete, in quanto non richiede la creazione di subnet specifiche per ogni cluster.
Condivisione dell'intervallo di subnet personalizzato per il control plane
Per impostazione predefinita, GKE utilizza l'intervallo di subnet principale per eseguire il provisioning dell'endpoint interno del control plane. Tuttavia, nei cluster con Private Service Connect, puoi configurare GKE per eseguire il provisioning dell'endpoint interno da una subnet diversa che hai creato. Puoi condividere questa subnet con altri cluster o tra progetti se utilizzi VPC condivisoa.
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 primario per i nodi presenta le seguenti limitazioni:
- Se condividi l'intervallo di indirizzi IP primari per i nodi con due o più cluster nativi di VPC, un cluster può utilizzare una parte ampia dell'intervallo di indirizzi IP condiviso, lasciando gli altri cluster senza indirizzi IP sufficienti per l'espansione.
Condivisione dell'intervallo di indirizzi IP secondario per i pod
Quando condividi l'intervallo secondario per i pod, ogni pod riceve comunque un indirizzo IP univoco.
La condivisione dell'intervallo di indirizzi IP secondario per i pod presenta le seguenti limitazioni:
Se condividi l'intervallo di indirizzi IP secondari per i pod con due o più cluster nativi della VPC, un cluster può utilizzare una parte consistente dell'intervallo di indirizzi IP condiviso, lasciando gli altri cluster senza indirizzi IP sufficienti per l'espansione.
Tra i diversi tipi di intervalli secondari, sia gli intervalli gestiti da GKE sia gli intervalli di pod aggiuntivi non sono condivisibili tra i cluster.
Per condividere un intervallo di indirizzi IP secondari, trasmettilo nella riga di comando con
--cluster-secondary-range. Non puoi utilizzare un intervallo secondario condiviso quando crei cluster nella UI.
Condivisione dell'intervallo di indirizzi IP secondario per i servizi
Due o più cluster possono utilizzare contemporaneamente lo stesso intervallo di indirizzi IPv4 secondari della subnet per i servizi quando utilizzi intervalli secondari gestiti dall'utente.
Per configurare due o più cluster in modo che condividano un intervallo di indirizzi IPv4 secondari della subnet comune per i servizi, utilizza lo stesso intervallo di indirizzi IPv4 secondari della subnet quando crei ogni cluster. Non è necessario un flag di configurazione separato per condividere un intervallo di indirizzi IPv4 comune per i servizi.
Quando condividono un intervallo di indirizzi IPv4 comune per i servizi, ogni cluster utilizza internamente l'intero intervallo di indirizzi IPv4 secondari della subnet per i servizi. Gli indirizzi IP per i servizi sono programmati all'interno di ciascun nodo del cluster, ma non sono assegnati all'interfaccia di rete di alcun nodo. Gli indirizzi IP del servizio non sono instradabili all'interno della rete VPC del cluster. Gli indirizzi IP del servizio sono utilizzabili solo dai pod client all'interno dello stesso cluster del servizio.
Quando un pod invia un pacchetto a un indirizzo IP del 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:
- Ridurre il numero di intervalli di indirizzi IP secondari unici per i servizi creati in una subnet
- Utilizzare meno indirizzi IP
La condivisione dell'intervallo di indirizzi IP secondario per i servizi presenta le seguenti 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 espressione regolare:
^gke-.*-services-[abcdef0-9]{8}Per condividere un intervallo di indirizzi IP secondari per i servizi, passalo nella riga di comando con
--cluster-secondary-rangenon 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 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 primario della subnet del cluster e dall'intervallo di indirizzi pod del cluster.
Il seguente messaggio di errore indica che l'intervallo di indirizzi IP primario della subnet o l'intervallo di indirizzi IP dei pod del cluster (l'intervallo di indirizzi 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 primaria o aggiungere nuovi indirizzi IP per i pod utilizzando il CIDR multi-pod non contiguo. Per saperne di più, vedi Spazio di indirizzi IP liberi insufficiente per i pod.
Networking dual-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 i pod e i nodi, GKE alloca indirizzi IPv4 e IPv6.
- Per i servizi, GKE alloca indirizzi a stack singolo (solo IPv4 o solo IPv6) o a doppio stack.
In GKE versione 1.24 o successive, puoi abilitare il networking dual-stack per i nuovi cluster GKE su reti VPC autonome e condivise. Puoi anche applicare i criteri di rete con il networking dual-stack abilitato. Se visualizzi errori di convalida quando abiliti il networking dual-stack sui cluster GKE di cui è stato eseguito l'upgrade dalle versioni 1.24 alle versioni 1.25 o 1.26, contatta il Google Cloud team di assistenza.
Vantaggi
Il networking dual-stack offre i seguenti vantaggi:
- Consente la comunicazione IPv6 end-to-end.
- Consente prestazioni migliori rispetto alla Network Address Translation (NAT) o al tunneling IP. Ciò è possibile perché non esiste una traduzione da IPv6 a IPv4.
Disponibilità
Il networking dual-stack con GKE presenta le seguenti limitazioni:
- Il networking dual-stack è disponibile solo per i cluster VPC nativi con GKE Dataplane V2 abilitato.
- Il networking dual-stack è supportato solo sulle subnet dei VPC in modalità personalizzata. Per maggiori informazioni, consulta Tipi di reti VPC.Google Cloud
- Gli indirizzi IPv6 a stack singolo per pod o nodi non sono supportati.
- I cluster a doppio stack consumano memoria aggiuntiva per nodo per supportare sia IPv4 che IPv6 rispetto ai cluster solo IPv4. Tieni presente questa caratteristica quando configuri cluster su larga scala.
- I cluster dual-stack non supportano l'accesso privato Google tramite IPv6.
- GKE versione 1.26.0-gke.2200 e successive supporta IPv6 (record AAAA) con Cloud DNS per le operazioni interne al cluster e le query DNS esterne.
- I servizi dual-stack sono supportati per i servizi
ClusterIP,NodePorteLoadBalancer. - IPv6 non è supportato per i nodi Windows.
Tieni presente le limitazioni precedenti prima di creare un cluster con networking dual-stack. Per saperne di più, scopri come creare un cluster nativo di VPC con rete dual-stack.
Assegnazione di indirizzi IPv6 pubblici e privati
La tabella seguente fornisce un riepilogo degli indirizzi IPv6 pubblici e privati con comportamenti e configurazioni di rete a doppio stack:
Flag ipv6-access-type |
Assegnazione di indirizzi IP | Intervallo di subnet |
|---|---|---|
EXTERNAL |
GKE assegna indirizzi IPv6 esterni instradabili a internet. |
Da 2600:1900/28
|
INTERNAL |
GKE assegna indirizzi IPv6 interni non instradabili a internet. I cluster con tipo di accesso IPv6 |
A partire da fd20::/20 (che è un sottoinsieme dell'intervallo ULA complessivo: fc00::/7).
|
Per saperne di più, consulta come utilizzare una rete dual-stack per un cluster nativo di VPC.
Architettura
A un cluster con rete a doppio stack IPv4/IPv6 vengono allocati i seguenti intervalli:
- Un intervallo /64 per ogni subnet come intervallo principale.
- Un intervallo /96 per nodo dall'intervallo principale da utilizzare come intervallo di indirizzi IP del nodo principale.
Un intervallo /112 per nodo dall'intervallo di indirizzi IP del nodo principale da utilizzare come intervallo di indirizzi IP del pod per quel nodo. Con il networking a doppio stack, i pod ricevono i loro 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 è composto da intervalli non sovrapposti dell'intervallo IP del nodo primario. Pertanto, questo intervallo IP del pod non è contiguo.
Un intervallo /112 da utilizzare per i servizi. Questo intervallo proviene da un intervallo /64 dell'intervallo di indirizzi privati di Google riservato all'intervallo di indirizzi IP secondari dei servizi di GKE.
Il seguente diagramma mostra come 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 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 secondario /112.
Servizi
Puoi creare un servizio a doppio stack IPv4/IPv6 di tipo
ClusterIP
o
NodePort.
I nuovi cluster GKE che eseguono la versione 1.29 o successive supportano
i servizi dual-stack di tipo
LoadBalancer.
Puoi esporre un deployment con un servizio di tipo ClusterIP, NodePort o
LoadBalancer. Per ciascuno di questi tipi di servizio, puoi definire i campi ipFamilies e ipFamilyPolicy come IPv4, IPv6 o un servizio dual-stack. Per maggiori 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 approfondimenti sull'utilizzo degli indirizzi IP di GKE.