Questo documento mostra come pianificare gli indirizzi IP per un'installazione 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 una 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, i cluster utente Piano di controllo V2 in un bucket con il controllo delle versioni attivo. Con Controlplane V2, i nodi del piano di controllo per un cluster utente si trovano per il cluster utente stesso.
Se non vuoi abilitare il piano di controllo V2 per i cluster utente, consulta Pianifica gli indirizzi IP (kubeception). Il termine kubeception si riferisce al caso in cui il piano di controllo per un utente in esecuzione su uno o più nodi nel cluster di amministrazione. Sconsigliamo di utilizzare e kubeception. Ti consigliamo di abilitare il piano di controllo V2.
Nodi del cluster di amministrazione
Un cluster di amministrazione include tre nodi, ognuno dei quali esegue i componenti del piano di controllo.
Bilanciamento del carico
Per questo esempio, supponiamo che i cluster utilizzino MetalLB con il bilanciatore del carico di rete passthrough esterno regionale. Questo bilanciatore del carico viene eseguito sui nodi del cluster, quindi non Le VM sono necessarie per il bilanciamento del carico.
Subnet
Per questo esempio, supponiamo che ogni cluster si trovi sulla propria VLAN e che i cluster si trovano 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 i VIP associati a nodi specifici in un cluster. Questo perché il bilanciatore del carico MetalLB può scegliere quale nodo annuncia il VIP per servizio individuale. Ad esempio, nel cluster utente 1, un nodo worker potrebbe annuncia 172.16.21.31 e un nodo worker diverso 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 dell'amministratore cluster: 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 indirizzi IP esterni. Ad esempio, potresti riservare 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 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 essere nello stesso
VLAN come IP dei nodi del piano di controllo specificati in network.controlPlaneIPBlock.
Esempi di indirizzi IP: nodi del cluster utente 1
Per un cluster utente con otto nodi, devi riservare nove indirizzi IP indirizzi IP esterni. L'indirizzo aggiuntivo è obbligatorio perché è necessario durante l'upgrade dei 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 riportata di seguito offre un esempio di come puoi designare i VIP configurato 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 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. 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 |
Tieni presente che il VIP per il server API Kubernetes è specificato in loadBalancer.vips.controlPlaneVIP del file di configurazione del cluster. Quando
Il piano di controllo V2 è abilitato. controlPlaneVIP
deve essere nello stesso
VLAN come IP dei nodi del piano di controllo specificati in network.controlPlaneIPBlock.
Esempi di indirizzi IP: nodi del cluster utente 2
Per un cluster utente con cinque nodi, devi riservare sei indirizzi indirizzi IP esterni. L'indirizzo aggiuntivo è obbligatorio perché è necessario durante l'upgrade dei 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 |
Esempio di indirizzi IP: VIP per il cluster utente 2
La tabella riportata di seguito offre un esempio di come puoi designare i VIP configurato sul bilanciatore del carico per il cluster utente 2:
VIP | Descrizione | Indirizzo IP |
---|---|---|
VIP del 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 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. 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 |
Tieni presente che il VIP per il server API Kubernetes è specificato in loadBalancer.vips.controlPlaneVIP del file di configurazione del cluster. Quando
Il piano di controllo V2 è abilitato. controlPlaneVIP
deve essere nello stesso
VLAN come IP dei nodi del piano di controllo specificati in network.controlPlaneIPBlock.
Indirizzi IP di esempio: pod e servizi
Prima di creare un cluster, devi specificare
CIDR
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 dei pod può essere lo stesso per più cluster.
In genere hai bisogno di più pod che servizi, quindi per un dato cluster probabilmente vorrai un intervallo CIDR pod più grande dell'intervallo CIDR servizio. L'intervallo di pod di esempio per un cluster utente è 192.168.0.0/16, che ha 2^(32-16) = 2^16 indirizzi. Un intervallo di servizi di esempio per un utente il cluster è 10.96.0.0/20, che ha solo 2^(32-20) = 2^12 indirizzi.
Evita sovrapposizioni
Potresti voler utilizzare intervalli CIDR non predefiniti per evitare la sovrapposizione con indirizzi IP raggiungibili nella tua rete. Gli intervalli di servizi e pod devono Non sovrapporsi ad alcun indirizzo esterno al cluster da cui vuoi effettuare la copertura all'interno del cluster.
Ad esempio, supponiamo che l'intervallo di servizi sia 10.96.232.0/24 e che 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 sarà considerato traffico nel cluster 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 dei bilanciatori 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 far rientrare gli intervalli di servizi e pod RFC 1918 di indirizzi IP privati.
Ecco uno dei motivi per cui si consiglia di utilizzare indirizzi RFC 1918. Supponiamo che se il pod o l'intervallo di servizi contiene indirizzi IP esterni. Qualsiasi 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 inoltre conoscere l'indirizzo IP del gateway predefinito subnet. Negli esempi precedenti, il gateway predefinito per ogni subnet è il primo indirizzo dell'intervallo. Ad esempio, nella subnet per l'amministratore cluster, il gateway predefinito è 172.16.20.1.
Ulteriori informazioni
Gestisci gli indirizzi IP dei nodi