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 sull'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
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 nel cluster utente stesso.
Nodi del cluster di amministrazione
Il cluster di amministrazione ha tre nodi:
- Un nodo che esegue il piano di controllo per il cluster di amministrazione
- Due nodi che eseguono componenti aggiuntivi per il cluster di amministrazione
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, perciò non sono necessarie VM aggiuntive per il bilanciamento del carico.
Subnet
In 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 le subnet. Nota che non vengono mostrati i VIP associati a un nodo specifico in un cluster. Questo perché il bilanciatore del carico MetalLB può scegliere quale nodo 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.
Esempio di indirizzo IP: 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 del cluster di amministrazione
Per un cluster di amministrazione con tre nodi, devi mettere da parte quattro indirizzi IP. L'indirizzo aggiuntivo è obbligatorio, perché lo è durante l'upgrade del cluster, l'aggiornamento e la riparazione automatica. Ad esempio, potresti mettere da parte i seguenti indirizzi IP per i nodi nel cluster di amministrazione:
| Indirizzi IP per i nodi nel cluster di amministrazione |
|---|
| 172.16.20.2 - 172.16.20.5 |
Esempi di indirizzi IP: VIP per il cluster di amministrazione
La tabella seguente fornisce un esempio di come designare i VIP da configurare sul bilanciatore del carico per il cluster di amministrazione. Nei file di configurazione del cluster, il campo in cui specifichi il VIP per un server API Kubernetes è denominato controlPlaneVIP:
| VIP | Indirizzo IP |
|---|---|
| VIP per il server API Kubernetes del cluster di amministrazione | 172.16.20.30 |
| VIP componenti aggiuntivi del cluster di amministrazione | 172.16.20.31 |
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é lo è durante l'upgrade del cluster, l'aggiornamento e la riparazione automatica. 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 |
Esempi di indirizzi IP: VIP per il cluster utente 1
La tabella seguente fornisce un esempio di come 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 secondo necessità sul bilanciatore del carico per il cluster utente 1. Nota 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é lo è durante l'upgrade del cluster, l'aggiornamento e la riparazione automatica. 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 |
Esempi di indirizzi IP: VIP per il cluster utente 2
La tabella seguente fornisce un esempio di come 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 | Configurato sul bilanciatore del carico per il cluster utente 2 | 172.16.22.30 |
| VIP in entrata per il cluster utente 2 | Configurato sul bilanciatore del carico per il cluster utente 2 | 172.16.22.31 |
| VIP di servizio per il cluster utente 2 | Dieci indirizzi per i servizi di tipo LoadBalancer.Configurata secondo necessità sul bilanciatore del carico per il cluster utente 2. Nota 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 quali intervalli CIDR utilizzare per pod e servizi. Ad esempio:
| Finalità | Intervallo CIDR |
|---|---|
| Pod nel cluster di amministrazione | 192.168.0.0/16 |
| Pod nel cluster utente 1 | 192.168.0.0/16 |
| Pod nel cluster utente 2 | 192.168.0.0/16 |
| Servizi nel cluster di amministrazione | 10.96.232.0/24 |
| Servizi nel cluster utente 1 | 10.96.0.0/20 |
| Servizi nel cluster utente 2 | 10.96.128.0/20 |
Gli esempi precedenti illustrano questi punti:
L'intervallo CIDR dei pod può essere lo stesso per più cluster.
In genere, hai bisogno di più pod che servizi, quindi per un determinato cluster, è probabile che tu voglia un intervallo CIDR dei pod maggiore dell'intervallo CIDR del servizio. 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, che ha solo 2^(32-20) = 2^12 indirizzi.
Evita sovrapposizioni
È consigliabile utilizzare intervalli CIDR non predefiniti per evitare la sovrapposizione 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 al di fuori del 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
È consigliabile che gli intervalli di servizi e pod si trovino nello spazio di indirizzi privati RFC 1918.
Ecco uno dei motivi per cui si consiglia di utilizzare indirizzi RFC 1918. Supponi che il tuo pod o intervallo di 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 del cluster di amministrazione, il gateway predefinito è visualizzato come 172.16.20.1.
Informazioni dettagliate
Gestire gli indirizzi IP dei nodi