Cluster VPC nativi

Questa pagina offre 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 gli 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.

Nota: per i cluster GKE Autopilot, il routing del traffico VPC nativo è abilitato per impostazione predefinita.

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 sono riservati nella rete VPC prima della creazione dei pod nel cluster. Questo impedisce conflitti con altre risorse nella rete VPC e ti consente di pianificare meglio le allocazioni degli indirizzi IP.

• Gli intervalli di indirizzi IP dei pod non dipendono dalle route statiche personalizzate. Non consumano la quota di route statiche generate dal sistema e personalizzate. Invece, le route della 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 nei 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.

Modalità di rete predefinita del cluster

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 predefinita del cluster dipende da come si crea il cluster.

La tabella seguente 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	Google Cloud Console	Rete VPC nativa
1.21.0-gke.1500 e versioni successive	API Kubernetes Engine o interfaccia a riga di comando di Google Cloud	Rete VPC nativa
Prima di 1.21.0-gke.1500	API Kubernetes Engine o interfaccia a riga di comando di Google Cloud	Basato su route

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 nativi di VPC

Quando crei un cluster nativo di VPC, devi specificare una subnet in una rete VPC. Il cluster utilizza tre intervalli di indirizzi IP di subnet univoci:

• in quanto utilizza l'intervallo di indirizzi IP principali della subnet per tutti gli indirizzi IP dei nodi.
• Utilizza un intervallo di indirizzi IP secondari per tutti gli indirizzi IP dei pod.
• in quanto utilizza un altro intervallo di indirizzi IP secondari per tutti gli indirizzi di emergenza del cluster.

La tabella seguente fornisce un riepilogo degli intervalli di indirizzi IP per nodi, pod e servizi:

Range	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 le dimensioni dell'intervallo di indirizzi IP secondari della subnet per i pod limitano il numero di nodi supportati da un cluster. Per ulteriori informazioni, consulta Intervalli di limiti dei nodi.	Se prevedi di creare un cluster a 900 nodi, l'intervallo di indirizzi IP principali della subnet del cluster deve essere almeno pari a /22 (2^(32-22) = 2^10 = 1004 indirizzi. Di questi 1024, 1020 sono utilizzabili perché quattro indirizzi IP sono riservati in ogni intervallo di indirizzi IP principale. Fai riferimento a Intervallo di indirizzi IP principali di subnet e all'intervallo di indirizzi IP secondari di subnet per i pod per ulteriori informazioni.
Pod	Gli indirizzi IP dei pod sono presi dall'intervallo di indirizzi IP secondari della subnet del cluster per i pod. A meno che non imposti un numero massimo di pod diverso per nodo, GKE alloca un /24 intervallo IP alias (256 indirizzi) a ciascun nodo per i pod in esecuzione. Su ogni nodo, tali indirizzi IP a 256 alias vengono utilizzati per supportare fino a 110 pod.	Per un cluster a 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 rete 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 di intervalli IP secondari fornisce 2^(32-14) = 2^18 = 262.144 indirizzi IP per i pod. Per ulteriori informazioni, consulta Intervallo di indirizzi IP secondari subnet per i pod.
Servizi	Gli indirizzi di servizio (IP cluster) sono presi dall'intervallo di indirizzi IP secondari 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.	Per un cluster che esegue fino a 3000 servizi, sono necessari 3000 indirizzi IP del cluster. È necessario un intervallo secondario di dimensioni pari o superiori a 20. Un intervallo /20 di indirizzi IP risulta in 2^(32-20) = 2^12 = 4096 indirizzi IP. Per ulteriori informazioni, consulta l'intervallo degli indirizzi IP secondari della subnet per i servizi.

Importante: gli intervalli di indirizzi IP di nodi, pod e servizi devono essere tutti univoci. Non puoi creare una subnet i cui intervalli di indirizzi IP principali e secondari si sovrappongono.

Indirizzi IP interni

Gli indirizzi IP utilizzati per le subnet del cluster VPC nativo 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 Intervalli validi e Intervalli limitati nella documentazione del VPC.

Consulta la sezione Utilizzo di intervalli di indirizzi IP privati non RFC 1918 per istruzioni sull'abilitazione di questi intervalli.

Consulta la sezione Attivare gli intervalli di indirizzi IP pubblici utilizzati privatamente per le istruzioni sull'utilizzo di questi intervalli nei cluster privati.

Metodi di assegnazione secondari per l'intervallo

Puoi assegnare intervalli di indirizzi IP e intervalli di indirizzi di servizio (ClusterIP) a un cluster nativo di VPC utilizzando uno dei due metodi seguenti:

Gestiti da GKE (impostazione predefinita)

GKE può creare e gestire gli intervalli secondari delle subnet. Quando crei il cluster, devi specificare un intervallo CIDR completo o le dimensioni di una netmask sia per i pod sia per i servizi. Ad esempio, puoi specificare 10.1.0.0/16 per i pod e 10.2.0.0/20 per i servizi oppure /16 per i pod e /20 per i servizi.

Se crei il cluster e la subnet contemporaneamente, gli intervalli di indirizzi IP di pod e servizi sono gestiti da GKE.

Attenzione: se specifichi un intervallo di indirizzi di pod inferiore a un intervallo /21, rischi di esaurire gli indirizzi IP dei pod man mano che il cluster cresce, a seconda del numero di numero massimo di pod per nodo che hai configurato. L'interfaccia a riga di comando di Google Cloud non ti impedirà di specificare un intervallo inferiore a un intervallo /21.

Gestita dall'utente

Puoi creare gli intervalli di indirizzi IP secondari della subnet, quindi creare un cluster che li utilizza. Se crei manualmente gli intervalli secondari, devi gestirli autonomamente.

Attenzione: gli intervalli gestiti dagli utenti ti consentono di utilizzare intervalli secondari di subnet inferiori a quelli possibili quando utilizzi gli intervalli gestiti da GKE. Fai attenzione quando crei intervalli di indirizzi dei pod inferiori a /21 poiché potresti esaurire gli indirizzi IP dei pod man mano che il cluster cresce.

L'intervallo di indirizzi IP più piccolo che puoi creare è /28. Tuttavia, devi utilizzare un intervallo abbastanza ampio da consentire la creazione di almeno un nodo. L'intervallo minimo utilizzabile dipende dal numero massimo di pod per nodo. Fai riferimento alla tabella Ottimizzare l'allocazione degli indirizzi IP per conoscere l'intervallo minimo utilizzabile di CIDR per valori diversi dei pod massimi per nodo.

Se esaurisci l'intervallo di indirizzi IP per i pod, devi creare un nuovo cluster con un intervallo di indirizzi dei pod più ampio o ricreare i pool di nodi dopo aver ridotto la --max-pods-per-node per i pool di nodi.

Nota: l'intervallo principale e l'intervallo secondario del pod possono essere condivisi tra i cluster, ma questa non è una configurazione consigliata.

Nota: anche se è possibile per gli intervalli di indirizzi IP dei pod di due o più cluster nativi VPC per condividere un intervallo di indirizzi IP secondari comuni della subnet per i pod, questa configurazione non è consigliata perché un cluster può utilizzare una vasta porzione dell'intervallo di indirizzi IP del pod condiviso. A ogni cluster nativo di VPC viene assegnato un intervallo di indirizzi IP secondari univoco per i relativi servizi (intervallo di indirizzi IP del cluster). Come best practice, crea intervalli di indirizzi IP secondari su subnet in modo che ogni cluster abbia l'utilizzo esclusivo di due intervalli secondari: uno per i suoi pod e uno per i relativi servizi.

Differenze con i cluster basati su route

Lo schema di allocazione per gli indirizzi di pod e servizi (ClusterIP) è diverso da quello usato da un cluster basato su route. Anziché specificare un unico ID cliente per pod e 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 (Gestione di identità e accessi) con il ruolo Amministratore di rete nel progetto host del VPC condiviso deve creare manualmente gli intervalli di indirizzi IP secondari e di subnet del cluster. Un amministratore di 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, GKE non può gestire intervalli di indirizzi IP secondari. Prima di poter creare il cluster, un amministratore di rete nel progetto host del VPC condiviso deve creare gli intervalli di indirizzi IP di subnet e secondari. Per un esempio di configurazione di un cluster nativo di VPC in una rete VPC condivisa, consulta la sezione Configurare i cluster con VPC condiviso.

la pianificazione degli intervalli 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 tuo cluster.

Intervallo di indirizzi IP principali di subnet

Ogni subnet deve avere un intervallo di indirizzi IP principali. Puoi espandere l'intervallo di indirizzi IP principali in qualsiasi momento, anche quando le risorse Google Cloud utilizzano la subnet; tuttavia, non puoi ridurre o modificare uno schema 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 riservati da Google Cloud.

La tabella seguente mostra il numero massimo di nodi che puoi creare in tutti i cluster che utilizzano la subnet, considerate le dimensioni dell'intervallo di indirizzi IP principali della subnet.

Intervallo IP principale subnet	Numero massimo di nodi
/29 Dimensioni minime per l'intervallo IP principale di una subnet	4 nodi
/28	12 nodi
/27	28 nodi
/26	60 nodi
/25	124 nodi
/24	252 nodi
/23	508 nodi
/22	1020 nodi
/21	2044 nodi
/20 Dimensioni predefinite dell'intervallo IP principale di una subnet nelle reti in modalità automatica	4092 nodi
/19	8188 nodi
/8 Dimensioni massime per un intervallo IP principale di subnet 39;s	16.777.212 nodi

Formule utili

Puoi utilizzare le seguenti formule per:

• Calcola il numero massimo di nodi N supportato da una determinata netmask. Utilizza S per la dimensione della netmask, il cui intervallo valido è compreso tra 8 e 29 (inclusi).

  N = 2^{(32 -S)} - 4

• Calcola la dimensione della netmask, S, necessaria per supportare un massimo di N nodi:

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

  ⌈⌉ è la funzione di soffitto (meno intero), vale a dire l'arrotondamento al numero intero successivo. L'intervallo valido per la dimensione della maschera della rete, S, è compreso tra 8 e 29 inclusi.

Intervallo di indirizzi IP secondari della subnet per i pod

Pianifica con attenzione l'intervallo di indirizzi IP secondari per i pod. Anche se è possibile sostituire l'intervallo di indirizzi IP secondari di una subnet, questa operazione non è supportata perché potrebbe causare l'instabilità del cluster.

Tuttavia, puoi creare intervalli di indirizzi IP di pod aggiuntivi utilizzando il CIDR multi-pod non continua.

La tabella seguente mostra il numero massimo di nodi e pod che puoi creare in tutti i cluster che utilizzano la subnet, considerate 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 (la densità predefinita dei pod massima possibile).

Intervallo IP secondario subnet per i pod	Numero massimo di indirizzi IP del pod	Numero massimo di nodi	Numero massimo di pod
/24 L'intervallo IP pod più piccolo possibile quando il metodo di assegnazione secondario dell'intervallo è gestito dall'utente	256 indirizzi	1 nodo	110 pod
/23 Solo possibile quando il metodo di assegnazione dell'intervallo secondario è gestito dall'utente	512 indirizzi	2 nodi	220 pod
/22 Solo possibile quando il metodo di assegnazione dell'intervallo secondario è gestito dall'utente	1024 indirizzi	4 nodi	440 pod
/21 L'intervallo IP del pod più piccolo possibile quando il metodo di assegnazione secondario dell'intervallo è gestito da GKE	2048 indirizzi	8 nodi	880 pod
/20	4096 indirizzi	16 nodi	1760 pod
/19	8192 indirizzi	32 nodi	3520 pod
/18	16.384 indirizzi	64 nodi	7040 pod
/17	32.768 indirizzi	128 nodi	14.080 pod
/16	65.536 indirizzi	256 nodi	28.160 pod
/15	131.072 indirizzi	512 nodi	56.320 pod
/14 Dimensione predefinita per l'intervallo IP secondario della subnet per i pod quando il metodo di assegnazione dell'intervallo secondario è gestito da GKE	262.144 indirizzi	1024 nodi	112.640 pod
/13	524.288 indirizzi	2048 nodi	225.280 pod
/12	1.048.576 indirizzi	4096 nodi	450.560 pod
/11	2.097.152 indirizzi	8192 nodi	901.120 pod
/10	4.194.304 indirizzi	16.384 nodi	1.802.240 pod
/9 L'intervallo di indirizzi del pod più grande possibile	8.388.608 indirizzi	32.768 nodi	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 da una subnet per l'intervallo di indirizzi IP secondari:

1. Calcola la dimensione della maschera di rete di ogni intervallo di pod di ciascun nodo, M.
   M = 31 - ⌈log2(Q)⌉ dove:

   • Q è il numero di pod per nodo
   • ⌈⌉ è la funzione soffitto (meno numero intero), vale a dire arrotondato al numero intero successivo

2. Calcola il numero massimo di nodi, N, supportato dall'intervallo di indirizzi IP secondari della subnet per i pod:
   N = 2(M - S) dove:

   • M è la dimensione della maschera di rete di ciascun 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

3. Calcola il numero massimo di pod P consentito dall'intervallo di indirizzi IP secondari della subnet per i pod:
   P = N × Q dove:

   • N è il numero massimo di nodi, calcolato nel passaggio precedente
   • Q è il numero di pod per nodo

Intervallo di indirizzi IP secondari di subnet per i servizi

Pianifica con attenzione l'intervallo di indirizzi IP secondari per i servizi. Poiché questo è anche un intervallo di indirizzi IP secondari di subnet, puoi sostituirlo solo quando non è utilizzato da alcuna risorsa di Google Cloud. Questo intervallo non può essere modificato fintanto che un cluster lo utilizza per i servizi (indirizzi IP del cluster).

A differenza degli intervalli di indirizzi IP dei nodi e dei pod, ogni cluster deve avere un intervallo di indirizzi IP secondari di subnet univoco per i servizi e non può provenire da un intervallo IP principale o secondario condiviso.

Se utilizzi servizi multi-cluster, l'oggetto ServiceImport utilizza gli indirizzi IP dell'intervallo IP secondario per i servizi.

La tabella seguente mostra il numero massimo di servizi che puoi creare in un unico 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 L'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	1.024 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	4.096 servizi
/19	8.192 servizi
/18	16.384 servizi
/17	32.768 servizi
/16 Intervallo di indirizzi del servizio più ampio possibile	65.536 servizi

Intervalli che limitano i 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.

Cloud Console mostra messaggi di errore simili ai seguenti per indicare che l'intervallo di indirizzi IP principali della subnet o dell'intervallo di indirizzi IP secondari del pod (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 oppure aggiungere nuovi indirizzi IP per i pod utilizzando il CIDR multi-pod non continua. Per ulteriori informazioni, consulta la sezione Spazio IP gratuito non sufficiente per i pod.

Nota: le subnet secondarie non sono visibili in Cloud Console. Se non riesci a trovare l'elemento [cluster subnet], l'errore è causato dall'esaurimento dell'IP in una subnet secondaria. In questo caso, controlla gli intervalli secondari della subnet principale.

Passaggi successivi

• Scopri di più sul peering di rete VPC.
• Scopri come creare un cluster nativo di VPC nel bilanciatore del carico HTTP(S) interno.