Questa pagina fornisce una panoramica generale dei cluster nativi VPC in Google Kubernetes Engine (GKE).
Questa pagina è rivolta agli architetti cloud e agli esperti di networking che progettano e progettano la rete per la propria organizzazione. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.
Panoramica
In GKE, i cluster possono essere distinti in base al modo in cui indirizzano il traffico da un pod all'altro.
Un cluster che utilizza intervalli di indirizzi IP alias è chiamato cluster nativo VPC.
Un cluster che utilizza route statiche personalizzate in una rete VPC è chiamato cluster basato su route.
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 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 evitano conflitti con altre risorse nella rete VPC e puoi pianificare meglio le allocazioni degli indirizzi IP.
Gli intervalli di indirizzi IP del pod non dipendono dalle route statiche personalizzate. Non consumano la quota per le route statiche personalizzate e generate dal sistema. Al loro posto, il routing per i cluster VPC-native viene gestito dalle route delle subnet generate automaticamente.
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 tramite router Cloud.
Alcune funzionalità, come i gruppi di endpoint di rete (NEG), funzionano solo con i cluster VPC-native.
Modalità di rete del cluster predefinita
VPC-native è 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 viene creato il cluster.
La tabella seguente elenca la modalità di rete del cluster predefinita per le versioni e i metodi di creazione dei cluster GKE.
| Versioni di 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 al momento della creazione.
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 come segue.
Indirizzi IP dei nodi: il cluster utilizza l'intervallo di indirizzi IPv4 primario 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 un CIDR multi-pod disgiunto.
Indirizzi IP dei servizi: il cluster utilizza un intervallo di indirizzi IP secondario distinto per tutti gli indirizzi dei servizi (IP cluster). Per informazioni su come attivare più cluster per condividere lo stesso intervallo IPv4 dei servizi, consulta Condividere intervalli di indirizzi IP tra i cluster GKE.
Allocazione di indirizzi IPv6 (networking dual-stack)
- Indirizzi IPv6 di nodi e pod: nei cluster abilitati per la rete a doppio stack, l'indirizzo IPv6 del nodo e tutti gli indirizzi IPv6 dei pod provengono dall'intervallo di indirizzi IPv6
/96designato del nodo. L'indirizzo IP del nodo è il primo/128(singolo indirizzo IPv6) all'interno di questo intervallo. Per ulteriori informazioni, consulta la sezione relativa alla 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 primario della subnet associata al cluster. Sia gli indirizzi IP dei nodi sia le dimensioni dell'intervallo di indirizzi IP secondario della subnet per i pod limitano il numero di nodi che un cluster può supportare. Per ulteriori informazioni, consulta gli intervalli di limiti dei nodi. |
Se prevedi di creare un cluster di 900 nodi, l'intervallo di indirizzi IP principale della subnet del cluster deve essere di almeno Per ulteriori informazioni, consulta Intervallo di indirizzi IP primario della subnet e Intervallo di indirizzi IP secondario della subnet per i pod. |
| Pod |
Gli indirizzi IP dei pod vengono ricavati dall'intervallo di indirizzi IP secondario per i pod della subnet del cluster. A meno che non imposti un numero massimo di pod per nodo diverso, GKE alloca un |
Per un cluster di 900 nodi che supporta fino a 110 pod per nodo, sono necessari 900 × 256 = 230.400 indirizzi IP per i pod. A ogni nodo viene allocato un intervallo IP alias la cui dimensione della netmask è /24. Questo cluster richiede una subnet il cui intervallo IP secondario per i pod ha una subnet mask non superiore a /14. Questo intervallo IP secondario fornisce 2(32-14) = 218 = 262.144 indirizzi IP per i pod. Per ulteriori informazioni, consulta Intervallo di indirizzi IP secondario della subnet per i pod. |
| Servizi |
Gli indirizzi dei servizi (IP del cluster) vengono ricavati dall'intervallo di indirizzi IP secondario per i servizi della subnet del cluster. Devi assicurarti che questo intervallo sia sufficientemente ampio 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 gli indirizzi IP per i servizi GKE da un intervallo gestito da GKE: |
Per un cluster che esegue fino a 3000 servizi, sono necessari 3000 indirizzi IP del cluster. Devi avere un intervallo secondario di dimensioni pari o superiori a /20. Un intervallo /20 di indirizzi IP genera 2(32-20) = 212 = 4096 indirizzi IP. Per ulteriori informazioni, consulta Intervallo di indirizzi IP della subnet secondaria 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. Per ulteriori informazioni sugli intervalli di sottoreti validi, consulta Intervalli validi e Intervalli con limitazioni nella documentazione VPC.
Consulta Utilizzare intervalli di indirizzi IP privati non RFC 1918 per istruzioni su come attivare l'utilizzo di questi intervalli.
Per istruzioni sull'utilizzo di questi intervalli, consulta Abilitare intervalli di indirizzi IP pubblici utilizzati privatamente.
Metodi di assegnazione degli intervalli secondari
Puoi assegnare intervalli di indirizzi IP dei pod e intervalli di indirizzi dei 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. 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 (creazione, aggiornamento, eliminazione, lettura) in corso 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 per i cluster GKE Standard che eseguono le versioni 1.29 e successive, per impostazione predefinita GKE assegna gli indirizzi IP per i servizi da un intervallo gestito da GKE: 34.118.224.0/20. In questo modo non è più necessario specificare il tuo
proprio intervallo di indirizzi IP per i servizi. Si applicano le seguenti considerazioni:
- Se vuoi, puoi specificare intervalli personalizzati per i servizi utilizzando il 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 l'intervallo parziale di indirizzi. - GKE non crea un intervallo di indirizzi IP secondario separato per i servizi quando viene utilizzato l'intervallo gestito da GKE.
Gestita dall'utente
Per il controllo completo dell'allocazione degli indirizzi IP, puoi gestire manualmente le subnet del tuo cluster nativo di VPC.
Puoi creare gli intervalli di indirizzi IP secondari della subnet, quindi creare un cluster che li utilizzi. Durante la creazione del cluster, specifica il nome dell'intervallo della sottorete per i pod e i 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 disgiunto è /28, ma questo intervallo ti consente di creare solo un nodo con un massimo di 8 pod. Devi utilizzare un intervallo sufficientemente ampio per il numero massimo di nodi di cui hai bisogno.
L'intervallo minimo utilizzabile dipende anche dal numero massimo di pod per nodo.
Consulta la tabella in Ottimizzazione dell'allocazione degli indirizzi IP per l'intervallo CIDR minimo utilizzabile per diversi valori di pod massimi per nodo.
Se esaurisci l'intervallo di indirizzi IP per i pod, devi eseguire una delle seguenti operazioni:
- Crea un nuovo cluster con un intervallo di indirizzi dei pod più ampio.
- Ricrea i node pool dopo aver ridotto il valore
--max-pods-per-nodeper i node pool. - Espandi l'intervallo di indirizzi IP del pod secondario utilizzando il CIDR multi-pod disgiunto.
Differenze con i cluster basati su route
Lo schema di allocazione degli indirizzi di pod e servizio (ClusterIP) è diverso da quello utilizzato da un cluster basato su route. Anziché specificare un singolo CIDR per i pod e i servizi, devi scegliere o creare due intervalli di indirizzi IP secondari nella subnet del cluster: uno per i pod e un altro per i servizi.
Considerazioni sul VPC condiviso
Quando crei un cluster nativo di VPC in un ambiente VPC condiviso, un proprietario del progetto, un editor o un'entità IAM (Identity and Access Management) con il ruolo Amministratore di rete 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. Prima di poter creare il cluster, un amministratore di rete nel progetto host VPC condiviso deve creare la subnet e gli intervalli di indirizzi IP secondari. Per un example che mostra come configurare un cluster nativo di VPC in una rete VPC condivisa, consulta Configurazione di cluster con VPC condiviso.
Pianificazione degli intervalli di indirizzi IP
Utilizza le informazioni riportate nelle sezioni seguenti per calcolare le dimensioni degli intervalli di indirizzi IP principali e secondari della subnet utilizzata dal cluster.
Intervallo di indirizzi IP principale della subnet
Prendi in considerazione le seguenti condizioni quando pianifichi l'intervallo di indirizzi IP del nodo principale:
- Ogni subnet deve avere un intervallo di indirizzi IP principale. Si tratta dell'intervallo di indirizzi IP utilizzato da GKE per allocare indirizzi IP per i bilanciatori del carico e i nodi interni.
- Non puoi ridurre o modificare l'intervallo di indirizzi IP principale di una subnet dopo la sua creazione.
- I primi due e gli ultimi due indirizzi IP di un intervallo IP principale sono riservati da Google Cloud.
- I cluster con Private Service Connect utilizzano l'intervallo della subnet principale per eseguire il provisioning dell'indirizzo IP interno assegnato all'endpoint del piano di controllo. Tuttavia, puoi ignorare questo provisioning dell'indirizzo IP con il flag
private-endpoint-subnetwork. Per saperne di più, consulta Creare un cluster e selezionare l'intervallo di indirizzi IP del piano di controllo.
La tabella seguente mostra il numero massimo di nodi che puoi creare in base alle dimensioni dell'intervallo di indirizzi IP principale della subnet e alla configurazione del cluster:
- Scenario 1: numero massimo di nodi in un cluster che utilizza la subnet predefinita.
- Scenario 2: numero massimo di nodi in un cluster Private Service Connect che non utilizza il flag
private-endpoint-subnetwork.
| Intervallo IP principale della subnet | Scenario 1 | Scenario 2 |
|---|---|---|
| /29 Dimensioni minime per l'intervallo IP primario di una subnet |
4 nodi | 3 nodi |
| /28 | 12 nodi | 11 nodi |
| /27 | 28 nodi | 27 nodi |
| /26 | 60 nodi | 59 nodi |
| /25 | 124 nodi | 123 nodi |
| /24 | 252 nodi | 251 nodi |
| /23 | 508 nodi | 507 nodi |
| /22 | 1020 nodi | 1019 nodi |
| /21 | 2044 nodi | 2043 nodi |
| /20 Dimensioni predefinite dell'intervallo IP principale di una subnet nelle reti in modalità automatica |
4092 nodi | 4091 nodi |
| /19 | 8188 nodi | 8187 nodi |
| /8 Dimensioni massime per l'intervallo IP primario di una subnet |
16.777.212 nodi | 16.777.211 nodi |
Espandi l'intervallo di indirizzi IP principale
Se non hai più indirizzi IP nell'intervallo IP principale, puoi espandere l'intervallo IP principale in qualsiasi momento, anche quando le risorse Google Cloud, come i bilanciatori di carico e i gruppi di endpoint di rete, utilizzano la subnet.
Prima di espandere l'intervallo di indirizzi IP principale, tieni presente quanto segue:
- Non devono essere presenti intervalli di indirizzi IP sovrapposti nella subnet.
- GKE utilizza l'intervallo di indirizzi IP principale per allocare indirizzi IP per i bilanciatori del carico e i nodi interni.
Formule utili
Puoi utilizzare le seguenti formule per:
Calcola il numero massimo di nodi, N, che una determinata subnet può supportare nei cluster che utilizzano la subnet predefinita. Utilizza S per la dimensione della subnet mask, il cui intervallo valido è compreso tra
8e29, inclusi.N = 2(32 -S) - 4
Calcola la dimensione della subnet mask, S, necessaria per supportare un massimo di N nodi:
S = 32 - ⌈log2(N + 4)⌉
⌈⌉è la funzione ceil (intero minimo), che significa arrotondamento per eccesso al numero intero successivo. L'intervallo valido per la dimensione della maschera di rete, S, è compreso tra8e29, inclusi.
Nei cluster Private Service Connect che non utilizzano il flag private-endpoint-subnetwork, puoi utilizzare le formule precedenti, ma ridurre il valore di N di 1.
Intervallo di indirizzi IP secondario della subnet per i pod
Pianifica con attenzione l'intervallo di indirizzi IP secondario per i pod.
La tabella seguente mostra il numero massimo di nodi e pod che puoi creare in tutti i cluster che utilizzano la subnet, in base alle dimensioni dell'intervallo di indirizzi IP secondario della subnet utilizzato dai pod.
Questa tabella presuppone che il numero massimo di pod per nodo sia 110, ovvero la densità del pod predefinita.
| Intervallo IP secondario della subnet per i pod | Indirizzi IP pod massimi | Numero massimo di nodi | Pod massimi |
|---|---|---|---|
| /24 Il più piccolo intervallo IP del 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 Minimo intervallo IP del 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 Dimensioni predefinite per l'intervallo di indirizzi IP secondario della subnet per i pod quando il metodo di assegnazione dell'intervallo secondario è gestito da GKE |
262.144 indirizzi | 1024 nodi |
Autopilot: 32.768 pod Standard: 112.640 pod |
| /13 | 524.288 indirizzi | 2048 nodi |
Autopilot: 65.536 pod Standard: 225.280 pod |
| /12 | 1.048.576 indirizzi | 4096 nodi |
Autopilot: 131.072 pod Standard: 450.560 pod |
| /11 | 2.097.152 indirizzi | 8192 nodi |
Autopilot: 262.144 pod Standard: 901.120 pod |
| /10 | 4.194.304 indirizzi | 16.384 nodi |
Autopilot: 524.288 pod Standard: 1.802.240 pod |
| /9 Intervallo di indirizzi dei pod più grande possibile |
8.388.608 indirizzi | 32.768 nodi |
Autopilot: 1.048.576 pod Standard: 3.604.480 pod |
Se hai modificato il numero massimo di pod per nodo, puoi utilizzare le seguenti formule per calcolare il numero massimo di nodi e pod supportati dall'intervallo di indirizzi IP secondari per i pod di una subnet:
Calcola la dimensione della netmask dell'intervallo di pod di ogni nodo, M.
M = 31 - ⌈log2(Q)⌉dove:- Q è il numero di pod per nodo
⌈⌉è la funzione di soffitto (intero minimo), ovvero arrotondamento per eccesso al numero intero successivo- Ad esempio, se Q è 110, then
M = 24
Calcola il numero massimo di nodi, N, supportato dall'intervallo di indirizzi IP secondario della subnet per i pod:
N = 2(M - S)dove:- M è la dimensione della netmask dell'intervallo di indirizzi IP alias di ciascun nodo per i pod, calcolata nel primo passaggio
- S è la dimensione della subnet mask dell'intervallo di indirizzi IP secondario della subnet
- Ad esempio, se M è 24 e S è 20, allora
N = 16
Calcola il numero massimo di pod, P, supportato dall'intervallo di indirizzi IP secondario per i pod della subnet:
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 attentamente l'intervallo di indirizzi IP secondario per i servizi. Poiché si tratta anche di un intervallo di indirizzi IP secondari della sottorete, non può essere modificato dopo la creazione del cluster.
Se utilizzi
servizi multi-cluster,
l'oggetto ServiceImport utilizza gli indirizzi IP dell'intervallo IP secondario per
i servizi.
Nei cluster GKE Autopilot che eseguono la versione 1.27 e successive
e nei cluster GKE Standard che eseguono le versioni 1.29 e successive,
per impostazione predefinita GKE assegna gli indirizzi IP per i servizi da un intervallo gestito da GKE: 34.118.224.0/20. In questo modo non è più necessario specificare il tuo
proprio intervallo di indirizzi IP per i servizi. Si applicano le seguenti considerazioni:
- Se vuoi, puoi specificare intervalli personalizzati per i servizi utilizzando il
--services-ipv4-cidro il--services-secondary-range-name. - Se specifichi solo una dimensione dell'intervallo utilizzando il flag
--services-ipv4-cidr(ad esempio/22), GKE utilizza comunque l'intervallo gestito da GKE per ottenere l'intervallo di sottoindirizzi. - GKE non crea un intervallo di indirizzi IP secondario separato per i servizi quando viene utilizzato l'intervallo gestito da Google. L'intervallo gestito da GKE non utilizza la quota dell'intervallo di indirizzi IP secondario per la tua subnet.
La tabella seguente mostra il numero massimo di servizi che puoi creare in un singolo cluster utilizzando la subnet, in base alle dimensioni dell'intervallo di indirizzi IP secondario della subnet per i servizi.
| Intervallo IP secondario per i servizi | Numero massimo di servizi |
|---|---|
| /28 Minimo intervallo di indirizzi di servizio possibile quando il metodo di assegnazione dell'intervallo secondario è gestito dall'utente |
16 servizi |
| /27 Minimo intervallo di indirizzi di servizio possibile quando il metodo di assegnazione dell'intervallo secondario è gestito da GKE |
32 servizi |
| /26 | 64 servizi |
| /25 | 128 servizi |
| /24 | 256 servizi |
| /23 | 512 Services |
| /22 | 1024 servizi |
| /21 | 2048 servizi |
| /20 Dimensioni predefinite 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 Maggiore intervallo di indirizzi di servizio possibile |
65.536 servizi |
Condivisione di intervalli di indirizzi IP tra i cluster GKE
Puoi condividere l'intervallo principale, l'intervallo di indirizzi IP secondario per i pod e l'intervallo di indirizzi IP secondario per i servizi tra i cluster della stessa subnet.
Questo comportamento è disponibile sia per 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 il sovraccarico 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 da parte degli amministratori di rete, in quanto non è necessario creare sottoreti specifiche per ogni cluster.
Condivisione dell'intervallo di subnet personalizzato per il piano di controllo
Per impostazione predefinita, GKE utilizza l'intervallo della subnet principale per eseguire il provisioning dell'endpoint interno del piano di controllo. Tuttavia, nei cluster con Private Service Connect, puoi configurare GKE in modo da 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 la VPC condiviso.
Condivisione dell'intervallo di indirizzi IP principale per i nodi
Se crei più di un cluster nella subnet, l'intervallo di indirizzi IP principali per i nodi è condiviso per impostazione predefinita.
La condivisione dell'indirizzo IP principale per i nodi presenta le seguenti limitazioni:
- Se condividi l'intervallo di indirizzi IP principale per i nodi con due o più cluster nativi VPC, un cluster può utilizzare una porzione ampia dell' intervallo di indirizzi IP condiviso, lasciando gli altri cluster senza indirizzi IP sufficienti per espandersi.
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 secondario per i pod con due o più cluster nativi VPC, un cluster può utilizzare una porzione ampia dell'intervallo di indirizzi IP condiviso, lasciando gli altri cluster senza indirizzi IP sufficienti per espandersi.
Tra i diversi tipi di intervalli secondari, sia quelli gestiti da GKE sia gli intervalli di pod aggiuntivi non sono condivisibili tra i cluster.
Per condividere un intervallo di indirizzi IP secondario, passalo alla riga di comando con
--cluster-secondary-range. Non puoi utilizzare un intervallo secondario condiviso durante la creazione di cluster nell'interfaccia utente.
Condivisione dell'intervallo di indirizzi IP secondario per i servizi
Due o più cluster possono utilizzare contemporaneamente lo stesso 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 è richiesto alcun flag di configurazione distinto per condividere un intervallo di indirizzi IPv4 comune per i servizi.
Quando condividi un intervallo di indirizzi IPv4 comune per i servizi, ogni cluster utilizza internamente l'intero intervallo di indirizzi IPv4 secondario della subnet per i servizi. Gli indirizzi IP per i servizi sono programmati all'interno del nodo di ciascun cluster, ma non sono assegnati all'interfaccia di rete di nessun nodo. Gli indirizzi IP dei servizi non sono instradabili all'interno della rete VPC del cluster. Gli indirizzi IP dei servizi sono utilizzabili solo dai pod client nello stesso cluster del servizio.
Quando un pod invia un pacchetto a un indirizzo IP di un servizio, la configurazione iptables o eBPF sul nodo esegue la Network Address Translation (NAT) di destinazione, modificando l'indirizzo IP di destinazione del pacchetto dall'indirizzo IP del servizio a un indirizzo IP del pod di servizio. Il pacchetto viene indirizzato in base all'indirizzo IP del pod di destinazione.
La condivisione dell'intervallo di indirizzi IP secondario per i servizi offre i seguenti vantaggi:
- Riduci il numero di intervalli di indirizzi IP secondari univoci per i servizi creati su una subnet
- Utilizza meno indirizzi IP
La condivisione dell'intervallo di indirizzi IP secondario per i servizi presenta le seguenti limitazioni:
- La condivisione dell'intervallo di indirizzi IP secondari per i servizi non è supportata con Cloud DNS per GKE nell'ambito VPC.
Non puoi condividere intervalli corrispondenti alla seguente regex:
^gke-.*-services-[abcdef0-9]{8}Per condividere un intervallo di indirizzi IP secondario per i servizi, passalo alla riga di comando con
--cluster-secondary-rangenon puoi utilizzare un intervallo secondario condiviso per i servizi quando crei i cluster nell'interfaccia utente.
Intervalli di limitazione dei nodi
Il numero massimo di pod e servizi per un determinato cluster GKE è limitato dalle dimensioni degli intervalli secondari del cluster. Il numero massimo di nodi nel cluster è limitato dalle dimensioni dell'intervallo di indirizzi IP principale della subnet del cluster e dall'intervallo di indirizzi pod del cluster.
Il seguente messaggio di errore indica che l'intervallo IP primario della subnet o l'intervallo IP del pod del cluster (l'intervallo IP secondario della subnet per i pod) è esaurito:
Instance [node name] creation failed: IP space of [cluster subnet] is
exhausted
Puoi aggiungere altri indirizzi IP per i nodi espandendo la subnet principale o aggiungere nuovi indirizzi IP per i pod utilizzando CIDR multi-pod non contigui. Per saperne di più, consulta Spazio di indirizzi IP non sufficiente per i pod.
Rete a doppio stack IPv4/IPv6
Con la rete 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 sia indirizzi IPv4 sia indirizzi IPv6.
- Per i servizi, GKE alloca indirizzi a stack singolo (solo IPv4 o solo IPv6) o a doppio stack.
In GKE versione 1.24 o successive, puoi attivare la rete dual-stack per i nuovi cluster GKE su reti VPC autonome e condivise. Puoi anche applicare i criteri di rete con la rete dual-stack attivata. Se visualizzi errori di convalida durante l'attivazione della rete dual-stack sui cluster GKE di cui è stato eseguito l'upgrade dalle versioni 1.24 alle versioni 1.25 o 1.26, contatta il team di assistenza di Google Cloud.
Vantaggi
La rete 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. Questo risultato viene ottenuto perché non esiste una traduzione da IPv6 a IPv4.
Disponibilità
La rete dual-stack con GKE presenta le seguenti limitazioni:
- Il networking dual-stack è disponibile solo per i cluster VPC nativi con GKE Dataplane V2 abilitato.
- La rete a doppio stack è supportata solo nelle subnet delle 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. Tieni conto di questa caratteristica quando configuri cluster su larga scala.
- I cluster dual-stack non supportano l'accesso privato Google tramite IPv6.
- Le versioni GKE 1.26.0-gke.2200 e successive supportano IPv6 (record AAAA) con Cloud DNS per le operazioni interne al cluster e le query DNS esterne.
- I servizi dual-stack sono supportati per i servizi
ClusterIP,NodePorteLoadBalancer.
- IPv6 non è supportato per i nodi Windows.
Tieni conto delle limitazioni precedenti prima di creare un cluster con la rete dual-stack. Per saperne di più, scopri come creare un cluster nativo di VPC con la rete dual-stack.
Assegnazione di indirizzi IPv6 pubblici e privati
La tabella seguente fornisce un riepilogo degli indirizzi IPv6 pubblici e privati con configurazioni e comportamenti di rete a doppio stack:
ipv6-access-type flag |
Assegnazione degli indirizzi IP | Intervallo di subnet |
|---|---|---|
EXTERNAL |
GKE assegna indirizzi IPv6 esterni che possono essere instradati su internet. |
Da 2600:1900/28
|
INTERNAL |
GKE assegna indirizzi IPv6 interni non instradabili su internet. I cluster con tipo di accesso IPv6 |
Da fd20::/20 (che è un sottoinsieme dell'intervallo ULA complessivo: fc00::/7).
|
Per scoprire di più, consulta come utilizzare una rete dual-stack per un cluster nativo della VPC.
Architettura
Un cluster con rete a doppio stack IPv4/IPv6 ha gli intervalli seguenti allocati:
- Un intervallo /64 a ogni subnet come intervallo principale.
- Un intervallo per nodo di 96 bit dall'intervallo principale da utilizzare come intervallo di indirizzi IP del nodo principale.
Un intervallo per nodo /112 dall'intervallo di indirizzi IP del nodo principale da utilizzare come intervallo di indirizzi IP del pod per quel nodo. Con la rete a doppio stack, i pod ricevono i propri indirizzi IPv6 dall'intervallo di indirizzi IP dei pod complessivo (in modo simile ai nodi) e non dall'intervallo secondario per i pod riservato agli indirizzi IPv4.
L'intervallo di indirizzi IP del pod complessivo è costituito da intervalli non sovrapposti dell'intervallo di indirizzi IP del nodo principale. 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 che è stato riservato per l'intervallo di indirizzi IP dei servizi secondari di GKE.
Il seguente diagramma mostra in che modo Google Cloud e GKE allocano gli indirizzi IPv6:
Nel diagramma, l'intervallo principale della subnet VPC è2600:1900:0:1::/64 e l'intervallo riservato per i servizi GKE è2600:2D00:0:4::0:0/64. Ogni nodo del cluster ha un intervallo /96 per l'intervallo di indirizzi IP del nodo principale e un intervallo /112 per l'intervallo di indirizzi IP del pod. Il cluster ha anche un intervallo di indirizzi IP secondario dei servizi /112.
Servizi
Puoi creare un servizio IPv4/IPv6 a doppio stack 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 come servizio
dual-stack. Per ulteriori informazioni, consulta un
esempio di come configurare un deployment.