Questo documento mostra come pianificare i tuoi indirizzi IP per l'installazione di Cluster Anthos su VMware (GKE On-Prem).
Prima di iniziare
Leggi la panoramica di Anthos clusters on 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 includa i seguenti elementi:
Una workstation di amministrazione
Un cluster di amministrazione
Un cluster utente ad alta disponibilità (HA) con cinque nodi worker
Un cluster utente non ad alta disponibilità con quattro nodi worker
Nodi cluster di amministrazione
Il cluster di amministrazione ha sette 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
- Tre nodi che eseguono il piano di controllo per il cluster utente ad alta disponibilità
- Un nodo che esegue il piano di controllo per il cluster utente non ad alta disponibilità
Bilanciamento del carico
Per questo esempio, supponi 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 abbia la propria VLAN e che i cluster si trovino in queste subnet:
| VM | Subnet | Gateway predefinito |
|---|---|---|
| Workstation e cluster di amministrazione | 172.16.20.0/24 | 162.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. Tieni presente che i VIP non vengono visualizzati associati a nessun 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 presentare l'annuncio 172.16.21.31, mentre un nodo worker diverso potrebbe indicare 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 sarebbe adatto alla workstation di amministrazione. Ad esempio, 172.16.20.20.
Esempi di indirizzi IP: nodi del cluster di amministrazione
Per un cluster di amministrazione con sette nodi, devi riservare otto indirizzi IP. L'indirizzo aggiuntivo è obbligatorio perché è necessario durante l'upgrade del cluster, l'aggiornamento e la riparazione automatica. Ad esempio, puoi 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.9 |
Esempi di indirizzi IP: VIP nella subnet del cluster di amministrazione
La tabella seguente mostra un esempio di come designare i VIP sul bilanciatore del carico per il cluster di amministrazione. Tieni presente che i VIP per i server API di Kubernetes dei cluster utente si trovano nella subnet dei cluster di amministrazione. Questo perché, in questo esempio, il server API di Kubernetes per un cluster utente viene eseguito su un nodo nel cluster di amministrazione. Tieni presente che nei file di configurazione del cluster, il campo in cui specifichi il VIP per un server API di Kubernetes è denominato controlPlaneVIP:
| VIP | Indirizzo IP |
|---|---|
| VIP per il server API di Kubernetes del cluster di amministrazione | 172.16.20.30 |
| VIP per i componenti aggiuntivi del cluster di amministrazione | 162/16/20/31 |
| VIP per il server API di Kubernetes del cluster utente 1 | 162/16/20/32 |
| VIP per il server API di Kubernetes del cluster utente 2 | 172.16.20.33 |
Indirizzi IP di esempio: nodi del cluster utente 1
Per un cluster utente con cinque nodi, devi riservare sei indirizzi IP. L'indirizzo aggiuntivo è obbligatorio perché è necessario durante l'upgrade del cluster, l'aggiornamento e la riparazione automatica. Ad esempio, puoi 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.7 |
Esempi di indirizzi IP: VIP nella subnet del cluster utente 1
La tabella seguente fornisce un esempio di come designare i VIP sul bilanciatore del carico per il cluster utente 1:
| VIP | Descrizione | Indirizzo IP |
|---|---|---|
| VIP in entrata per il cluster utente 1 | Configurato sul bilanciatore del carico per il cluster utente 1 | 172.16.21.30 |
| VIP di servizio per cluster utente 1 | Dieci indirizzi di servizi di tipo LoadBalancer.Configurato in base alle esigenze sul bilanciatore del carico per il cluster utente 1. Tieni presente che questo intervallo include il VIP Ingress. Questo è un requisito per il bilanciatore del carico MetalLB. |
172/16/21.30 - 172/16/21.39 |
Indirizzi IP di esempio: nodi del cluster utente 2
Per un cluster utente con quattro nodi, devi riservare cinque indirizzi IP. L'indirizzo aggiuntivo è obbligatorio perché è necessario durante l'upgrade del cluster, l'aggiornamento e la riparazione automatica. Ad esempio, puoi 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.6 |
Esempi di indirizzi IP: VIP nella subnet del cluster utente 2
La tabella seguente mostra un esempio di come designare i VIP sul bilanciatore del carico per il cluster utente 2:
| VIP | Descrizione | Indirizzo IP |
|---|---|---|
| VIP Ingress per cluster utente 2 | Configurato sul bilanciatore del carico per il cluster utente 2 | 172.16.22.30 |
| VIP di servizio per cluster utente 2 | Dieci indirizzi di servizi di tipo LoadBalancer.Configurato in base alle esigenze sul bilanciatore del carico per il cluster utente 2. Tieni presente che questo intervallo include il VIP Ingress. Questo è un requisito per il bilanciatore del carico MetalLB. |
172/16/22.30 - 172/16/22.39 |
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 da utilizzare per gli indirizzi ClusterIP dei servizi Kubernetes.
Decidi quali intervalli CIDR utilizzare per i pod e i servizi. Ecco alcuni esempi:
| 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 pod può essere uguale per più cluster.
In genere sono necessari più pod che servizi, quindi per un dato cluster è probabile che tu voglia un intervallo CIDR pod superiore all'intervallo CIDR 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, che ha solo 2^(32-20) = 2^12 indirizzi.
Evita sovrapposizioni
Ti consigliamo di utilizzare intervalli CIDR non predefiniti per evitare la sovrapposizione di indirizzi IP raggiungibili nella tua rete. Gli intervalli di servizi e pod non devono sovrapporsi ad alcun indirizzo esterno al cluster che vuoi raggiungere dall'interno del cluster.
Supponiamo, ad esempio, che il tuo intervallo di servizi sia 10.96.232.0/24 e che l'intervallo 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à considerato come traffico in-cluster e non raggiungerà alcuna destinazione all'esterno 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 dei server vCenter, server DNS e server NTP
Consigliamo di inserire gli intervalli di servizi e pod nello spazio di indirizzi privato RFC 1918.
Ecco un motivo per cui è consigliabile utilizzare indirizzi RFC 1918. Supponiamo che l'intervallo di pod o servizi contenga indirizzi IP esterni. Tutto il traffico inviato da un pod a uno di questi indirizzi esterni verrà considerato come traffico in-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 ogni subnet. Negli esempi precedenti, il gateway predefinito per ogni subnet è il primo indirizzo nell'intervallo. Ad esempio, nella subnet per il cluster di amministrazione, il gateway predefinito viene visualizzato come 172.16.20.1.
Informazioni dettagliate
Gestisci gli indirizzi IP dei nodi