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.

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) = 210 = 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) = 218 = 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) = 212 = 4096 indirizzi IP.

Per ulteriori informazioni, consulta l'intervallo degli indirizzi IP secondari della subnet per i servizi.

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.

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.

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.

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 - ⌈log2(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.

Passaggi successivi