Questo documento mostra come pianificare gli indirizzi IP per un'installazione di Google Distributed Cloud.
Prima di iniziare
Leggi la panoramica di Google Distributed Cloud 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 questi elementi:
Una workstation di amministrazione
Un cluster di amministrazione ad alta disponibilità (HA)
Un cluster utente ad alta disponibilità con cinque nodi worker
Un cluster utente non HA con quattro nodi worker
In questo esempio, i cluster utente hanno Controlplane V2 abilitato. Con Controlplane V2, i nodi del control plane per un cluster utente si trovano nel cluster utente stesso.
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 control plane per un cluster utente viene eseguito su uno o più nodi nel cluster di amministrazione. Non è consigliabile utilizzare kubeception. 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 control plane.
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 le subnet. Tieni presente che gli IP virtuali non vengono mostrati 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.
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 sarebbe adatto per la workstation di amministrazione. Ad esempio, 172.16.20.20.
Indirizzi IP di esempio: nodi del cluster di amministrazione
Il cluster di amministrazione in questo esempio ha tre nodi, quindi devi impostare tre indirizzi IP. Ad esempio, puoi riservare i seguenti indirizzi IP per i nodi nel cluster di amministrazione:
Cluster di amministrazione | Indirizzi IP |
---|---|
Cluster di amministrazione HA | 172.16.20.2 - 172.16.20.4 |
Indirizzi IP di esempio: VIP per il cluster di amministrazione
Devi riservare 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, puoi riservare 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.20.30 |
Tieni presente che per i cluster di amministrazione ad alta disponibilità, controlPlaneVIP
deve trovarsi nella stessa
VLAN degli IP dei nodi del control plane specificati in network.controlPlaneIPBlock.
Indirizzi IP di esempio: nodi del cluster utente 1
Per un cluster utente con otto nodi, devi riservare nove indirizzi IP. L'indirizzo aggiuntivo è necessario perché viene utilizzato durante l'upgrade, l'aggiornamento e la riparazione automatica del cluster. Ad esempio, potresti riservare 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 mostra un esempio di come potresti 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 | Configurato sul bilanciatore del carico per il cluster utente 1 | 172.16.21.30 |
VIP in entrata per il cluster utente 1 | Configurato 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 .Configurato in base alle esigenze sul bilanciatore del carico per il cluster utente 1. Tieni presente che questo intervallo include l'IP virtuale Ingress. Questo è un requisito per il bilanciatore del carico MetalLB. |
172.16.21.31 - 172.16.21.40 |
Tieni presente che il VIP per il server API Kubernetes è specificato in loadBalancer.vips.controlPlaneVIP del file di configurazione del cluster. Quando
ControlPlane V2 è abilitato, controlPlaneVIP
deve trovarsi nella stessa
VLAN degli IP dei nodi del control plane specificati in network.controlPlaneIPBlock.
Indirizzi IP di esempio: 2 nodi del cluster utente
Per un cluster utente con cinque nodi, devi riservare sei indirizzi IP. L'indirizzo aggiuntivo è necessario perché viene utilizzato durante l'upgrade, l'aggiornamento e la riparazione automatica del cluster. Ad esempio, potresti riservare 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 mostra un esempio di come potresti 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 .Configurato in base alle esigenze sul bilanciatore del carico per il cluster utente 2. Tieni presente che questo intervallo include l'IP virtuale Ingress. Questo è un requisito per il bilanciatore del carico MetalLB. |
172.16.22.31 - 172.16.22.40 |
Tieni presente che il VIP per il server API Kubernetes è specificato in loadBalancer.vips.controlPlaneVIP del file di configurazione del cluster. Quando
ControlPlane V2 è abilitato, controlPlaneVIP
deve trovarsi nella stessa
VLAN degli IP dei nodi del control plane specificati in network.controlPlaneIPBlock.
Indirizzi IP di esempio: 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 vuoi 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 del pod può essere lo stesso per più cluster.
In genere hai bisogno di più pod che servizi, quindi per un determinato cluster, probabilmente vuoi un intervallo CIDR pod più grande 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 servizio di esempio per un cluster di utenti è 10.96.0.0/20, che ha solo 2^(32-20) = 2^12 indirizzi.
Evitare la sovrapposizione
Potresti voler utilizzare intervalli CIDR non predefiniti per evitare sovrapposizioni con gli indirizzi IP raggiungibili nella tua rete. Gli intervalli di servizi e pod non devono sovrapporsi a indirizzi esterni al cluster che vuoi raggiungere dall'interno del cluster.
Ad esempio, supponiamo che l'intervallo di servizio 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). Qualsiasi traffico inviato da un pod a un indirizzo in uno di questi intervalli verrà trattato come traffico in-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 control plane e dai bilanciatori del carico
Indirizzi IP di server vCenter, server DNS e server NTP
Ti consigliamo di utilizzare intervalli di servizi e pod nello spazio di indirizzi privati RFC 1918.
Ecco un motivo per cui è consigliabile utilizzare gli indirizzi RFC 1918. Supponiamo che l'intervallo di pod o servizi contenga indirizzi IP esterni. Il traffico inviato da un pod a uno di questi indirizzi esterni verrà trattato 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 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 viene visualizzato come 172.16.20.1.
Ulteriori informazioni
Gestire gli indirizzi IP dei nodi