Pianifica gli indirizzi IP

Questo documento mostra come pianificare gli indirizzi IP per un'installazione di GKE su VMware.

Prima di iniziare

Leggi la panoramica di GKE su VMware e la panoramica dell'installazione.

Esempio di allocazione degli indirizzi IP

Questa sezione fornisce un esempio di come allocare indirizzi IP statici in un'installazione che include i seguenti elementi:

  • Una workstation di amministrazione

  • Un cluster di amministrazione ad alta disponibilità

  • Un cluster utente ad alta disponibilità con cinque nodi worker

  • Un cluster utente non ad alta disponibilità con quattro nodi worker

In questo esempio, nei cluster utente è abilitato Controlplane V2. Con Controlplane V2, i nodi del piano di controllo per un cluster utente si trovano nello stesso cluster utente.

Se non vuoi abilitare Controlplane V2 per i tuoi cluster utente, consulta Pianificare gli indirizzi IP (kubeception). Il termine kubeception si riferisce al caso in cui il piano di controllo per un cluster utente viene eseguito su uno o più nodi nel cluster di amministrazione. L'uso di kubeception è sconsigliato. Ti consigliamo di abilitare Controlplane V2.

Nodi del cluster di amministrazione

Un cluster di amministrazione ha tre nodi, ognuno dei quali esegue i componenti del piano di controllo.

Bilanciamento del carico

Per questo esempio, supponiamo che i cluster utilizzino il bilanciatore del carico MetalLB. Questo bilanciatore del carico viene eseguito sui nodi del cluster, quindi non sono necessarie VM aggiuntive per il bilanciamento del carico.

Subnet

Per questo esempio, supponiamo che ogni cluster si trovi sulla propria VLAN e che i cluster si trovino in queste subnet:

VM Subnet Gateway predefinito
Workstation di amministrazione e cluster di amministrazione 172.16.20.0/24 172.16.20.1
Cluster utente 1 172.16.21.0/24 172.16.21.1
Cluster utente 2 172.16.22.0/24 172.16.22.1

Il seguente diagramma illustra le tre VLAN e subnet. Tieni presente che i VIP non vengono mostrati associati a nessun nodo specifico di un cluster. Questo perché il bilanciatore del carico MetalLB può scegliere il nodo che annuncia il VIP per un singolo servizio. Ad esempio, nel cluster utente 1, un nodo worker potrebbe annunciare 172.16.21.31 e un altro nodo worker potrebbe annunciare 172.16.21.32.

Indirizzi IP per un cluster di amministrazione e due cluster utente.
Indirizzi IP per un cluster di amministrazione e due cluster utente (fai clic per ingrandire)

Indirizzo IP di esempio: workstation di amministrazione

In questo esempio, la workstation di amministrazione si trova nella stessa subnet del cluster di amministrazione: 172.16.20.0/24. Un indirizzo vicino agli indirizzi dei nodi è adatto per la workstation di amministrazione. Ad esempio, 172.16.20.20.

Esempi di indirizzi IP: nodi dei cluster di amministrazione

Il cluster di amministrazione in questo esempio ha tre nodi, quindi devi impostare tre indirizzi IP. Ad esempio, potresti mettere da parte i seguenti indirizzi IP per i nodi nel cluster di amministrazione:

Cluster di amministrazione Indirizzi IP
Cluster di amministrazione ad alta disponibilità 172/16/20,2 - 172/16/20,4

Esempi di indirizzi IP: VIP per il cluster di amministrazione

Devi mettere da parte un VIP per il server API Kubernetes del cluster di amministrazione. Tieni presente che nel file di configurazione del cluster, il campo per questo VIP è denominato controlPlaneVIP. Ad esempio, potresti mettere da parte il seguente VIP per il server API Kubernetes del cluster di amministrazione:

VIP Indirizzo IP
VIP per il server API Kubernetes del cluster di amministrazione 172/16/2030

Esempi di indirizzi IP: nodi del cluster utente 1

Per un cluster utente con otto nodi, devi mettere da parte nove indirizzi IP. L'indirizzo aggiuntivo è obbligatorio, perché è necessario durante l'upgrade, l'aggiornamento e la riparazione automatica del cluster. Ad esempio, potresti mettere da parte i seguenti indirizzi IP per i nodi nel cluster utente 1:

Indirizzi IP per i nodi nel cluster utente 1
172.16.21.2 - 172.16.21.10

Indirizzi IP di esempio: VIP per il cluster utente 1

La seguente tabella offre un esempio di come puoi designare i VIP da configurare sul bilanciatore del carico per il cluster utente 1:

VIP Descrizione Indirizzo IP
VIP per il server API Kubernetes del cluster utente 1 Configurata sul bilanciatore del carico per il cluster utente 1 172/16/21/30
VIP in entrata per il cluster utente 1 Configurata sul bilanciatore del carico per il cluster utente 1 172/16/21/31
VIP di servizio per il cluster utente 1 Dieci indirizzi per i servizi di tipo LoadBalancer.
Configurata in base alle esigenze sul bilanciatore del carico per il cluster utente 1.
Tieni presente che questo intervallo include il VIP in entrata.
Questo è un requisito per il bilanciatore del carico MetalLB.		 172.16.21.31 - 172.16.21.40

Esempi di indirizzi IP: nodi del cluster utente 2

Per un cluster utente con cinque nodi, devi mettere da parte sei indirizzi IP. L'indirizzo aggiuntivo è obbligatorio, perché è necessario durante l'upgrade, l'aggiornamento e la riparazione automatica del cluster. Ad esempio, potresti mettere da parte i seguenti indirizzi IP per i nodi nel cluster utente 2:

Indirizzi IP per i nodi nel cluster utente 2
172.16.22.2 - 172.16.22.7

Indirizzi IP di esempio: VIP per il cluster utente 2

La seguente tabella offre un esempio di come puoi designare i VIP da configurare sul bilanciatore del carico per il cluster utente 2:

VIP Descrizione Indirizzo IP
VIP per il server API Kubernetes per il cluster utente 2 Configurata sul bilanciatore del carico per il cluster utente 2 172.16.22.30
VIP in entrata per cluster utente 2 Configurata sul bilanciatore del carico per il cluster utente 2 172/16/22/31
VIP di servizio per cluster utente 2 Dieci indirizzi per i servizi di tipo LoadBalancer.
Configurata secondo necessità sul bilanciatore del carico per il cluster utente 2.
Tieni presente che questo intervallo include il VIP in entrata.
Questo è un requisito per il bilanciatore del carico MetalLB.		 172.16.22.31 - 172.16.22.40

Esempi di indirizzi IP: pod e servizi

Prima di creare un cluster, devi specificare un intervallo CIDR da utilizzare per gli indirizzi IP dei pod e un altro intervallo CIDR per gli indirizzi ClusterIP dei servizi Kubernetes.

Decidi gli intervalli CIDR da utilizzare per pod e servizi. Ad esempio:

FinalitàIntervallo CIDR
Pod nel cluster di amministrazione192.168.0.0/16
Pod nel cluster utente 1192.168.0.0/16
Pod nel cluster utente 2192.168.0.0/16
Servizi nel cluster di amministrazione10.96.232.0/24
Servizi nel cluster utente 110.96.0.0/20
Servizi nel cluster utente 210.96.128.0/20

Gli esempi precedenti illustrano questi punti:

  • L'intervallo CIDR dei pod può essere lo stesso per più cluster.

  • In genere, sono necessari più pod che servizi. Di conseguenza, per un determinato cluster, probabilmente vorrai avere un intervallo CIDR dei pod superiore all'intervallo CIDR dei servizi. L'intervallo di pod di esempio per un cluster utente è 192.168.0.0/16, che ha 2^(32-16) = 2^16 indirizzi. Tuttavia, un intervallo di servizi di esempio per un cluster utente è 10.96.0.0/20, con solo 2^(32-20) = 2^12 indirizzi.

Evita sovrapposizioni

Ti consigliamo di utilizzare intervalli CIDR non predefiniti per evitare sovrapposizioni con gli indirizzi IP raggiungibili nella rete. Gli intervalli di servizi e pod non devono sovrapporsi ad alcun indirizzo esterno al cluster che vuoi raggiungere dall'interno del cluster.

Ad esempio, supponiamo che l'intervallo di Service sia 10.96.232.0/24 e l'intervallo di pod sia 192.168.0.0/16 (192.168.0.1 - 192.168.255.254). Tutto il traffico inviato da un pod a un indirizzo in uno di questi intervalli verrà trattato come traffico nel cluster e non raggiungerà alcuna destinazione esterna al cluster.

In particolare, gli intervalli di servizi e pod non devono sovrapporsi a:

  • Indirizzi IP dei nodi in qualsiasi cluster

  • Indirizzi IP utilizzati dalle macchine del bilanciatore del carico

  • VIP utilizzati dai nodi del piano di controllo e dai bilanciatori del carico

  • Indirizzi IP di server vCenter, server DNS e server NTP

Ti consigliamo di utilizzare gli intervalli di servizi e pod nello spazio di indirizzi privati RFC 1918.

Ecco uno dei motivi per cui si consiglia di utilizzare indirizzi RFC 1918. Supponiamo che il tuo intervallo di pod o servizi contenga indirizzi IP esterni. Tutto il traffico inviato da un pod a uno di questi indirizzi esterni verrà trattato come traffico nel cluster e non raggiungerà la destinazione esterna.

Server DNS e gateway predefinito

Prima di compilare i file di configurazione, devi conoscere l'indirizzo IP di un server DNS che può essere utilizzato dalla workstation di amministrazione e dai nodi del cluster.

Devi anche conoscere l'indirizzo IP del gateway predefinito per ciascuna delle tue subnet. Negli esempi precedenti, il gateway predefinito per ogni subnet è il primo indirizzo dell'intervallo. Ad esempio, nella subnet per il cluster di amministrazione, il gateway predefinito è 172.16.20.1.

Ulteriori informazioni

Gestisci gli indirizzi IP dei nodi