Requisiti di sistema per la configurazione di vSphere with Tanzu con NSX-T Data Center

Esaminare i requisiti di sistema per la configurazione di vSphere with Tanzu in un cluster vSphere utilizzando lo stack di rete NSX-T Data Center.

Limiti di configurazione per i cluster vSphere with Tanzu

VMware fornisce i limiti di configurazione nello strumento Limite massimo configurazione VMware.

Per i limiti di configurazione specifici di vSphere with Tanzu, inclusi i Cluster supervisori e Tanzu Kubernetes, selezionare vSphere > vSphere 7.0 > vSphere with Kubernetes > VMware Tanzu Kubernetes Grid Service for vSphere e fare clic su Visualizza limiti oppure seguire questo link.

Requisiti per un cluster di gestione, Edge e di dominio del carico di lavoro

È possibile distribuire vSphere with Tanzu con le funzioni combinate di gestione, Edge e di gestione del carico di lavoro in un singolo cluster vSphere.

Tabella 1. Requisiti minimi di calcolo per il cluster di gestione, Edge e di gestione del carico di lavoro

Sistema	Dimensioni minime della distribuzione	CPU	Memoria	Storage
vCenter Server 7.0	Piccolo	2	16 GB	290 GB
Host ESXi 7.0	3 host ESXi con 1 IP statico per host. Se si utilizza vSAN: il numero minimo è 3 host ESXi con almeno 2 NIC fisiche per host. Tuttavia, è consigliabile utilizzare 4 host ESXi per la resilienza durante l'installazione delle patch e l'aggiornamento. Gli host devono unirsi a un cluster con vSphere DRS e vSphere HA abilitati. vSphere DRS deve essere in modalità completamente o parzialmente automatizzata. Attenzione: Non disabilitare vSphere DRS dopo aver configurato il Cluster supervisore. Avere DRS sempre abilitato è un prerequisito obbligatorio per l'esecuzione dei carichi di lavoro nel Cluster supervisore. La disabilitazione di DRS comporta l'interruzione dei cluster di Tanzu Kubernetes.	8	64 GB per host	Non applicabile
NSX Manager	Media	6	24 GB	300 GB
NSX Edge 1	Grande	8	32 GB	200 GB
NSX Edge 2	Grande	8	32 GB	200 GB
Macchine virtuali del piano di controllo Kubernetes	3	4	16 GB	16 GB

Topologia con cluster separati per Edge e gestione e per la gestione del carico di lavoro

È possibile distribuire vSphere with Tanzu in due cluster, un cluster per le funzioni Edge e di gestione e un altro dedicato alla gestione del carico di lavoro.

Tabella 2. Requisiti minimi di calcolo per il cluster Edge e di gestione

Sistema	Dimensioni minime della distribuzione	CPU	Memoria	Storage
vCenter Server 7.0	Piccolo	2	16 GB	290 GB
Host ESXi 7.0	2 host ESXi	8	64 GB per host	Non applicabile
NSX Manager	Media	6	24 GB	300 GB
NSX Edge 1	Grande	8	32 GB	200 GB
NSX Edge 2	Grande	8	32 GB	200 GB

Tabella 3. Requisiti minimi di calcolo per il cluster di gestione del carico di lavoro

Sistema	Dimensioni minime della distribuzione	CPU	Memoria	Storage
Host ESXi 7.0	3 host ESXi con 1 IP statico per host. Se si utilizza vSAN: il numero minimo è 3 host ESXi con almeno 2 NIC fisiche per host. Tuttavia, è consigliabile utilizzare 4 host ESXi per la resilienza durante l'installazione delle patch e l'aggiornamento. Gli host devono unirsi a un cluster con vSphere DRS e vSphere HA abilitati. vSphere DRS deve essere in modalità completamente automatizzata. Attenzione: Non disabilitare vSphere DRS dopo aver configurato il Cluster supervisore. Avere DRS sempre abilitato è un prerequisito obbligatorio per l'esecuzione dei carichi di lavoro nel Cluster supervisore. La disabilitazione di DRS comporta l'interruzione dei cluster di Tanzu Kubernetes.	8	64 GB per host	Non applicabile
Macchine virtuali del piano di controllo Kubernetes	3	4	16 GB	16 GB

Requisiti di rete

Indipendentemente dalla topologia implementata per la gestione del carico di lavoro Kubernetes in vSphere, la distribuzione deve soddisfare i seguenti requisiti di rete:

Componente	Quantità minima	Configurazione richiesta
IP statici per le macchine virtuali del piano di controllo Kubernetes	Blocco di 5	Blocco di 5 indirizzi IP statici consecutivi da assegnare alle macchine virtuali del piano di controllo Kubernetes nel Cluster supervisore.
Rete traffico di gestione	1	Una rete di gestione instradabile agli host ESXi, al vCenter Server e a un server DHCP. La rete deve poter accedere a un registro del contenitore e disporre della connettività Internet, se il registro del contenitore si trova sulla rete esterna. Il registro del contenitore deve essere risolvibile tramite DNS e l'impostazione di uscita descritta di seguito deve essere in grado di accedervi.
Server NTP e DNS	1	Un server DNS e un server NTP che possono essere utilizzati per il vCenter Server. Nota: Configurare NTP in tutti gli host ESXi, i sistemi vCenter Server e le istanze di NSX Manager.
DHCP Server	1	Facoltativo. Configurare un server DHCP per acquisire automaticamente gli indirizzi IP per la gestione. Il server DHCP deve supportare gli identificatori client e fornire server DNS compatibili, domini di ricerca DNS e un server NTP.
Registro immagini	1	Consente di accedere a un registro per il servizio.
Subnet della rete di gestione	1	La subnet utilizzata per il traffico di gestione tra gli host ESXi e il vCenter Server, le appliance NSX e il piano di controllo Kubernetes. Le dimensioni della subnet devono essere le seguenti: Un solo indirizzo IP per scheda VMkernel host. Un solo indirizzo IP per l'appliance vCenter Server. Uno o quattro indirizzi IP per NSX Manager. Quattro quando si esegue il clustering NSX Manager di 3 nodi e 1 IP virtuale (VIP). 5 indirizzi IP per il piano di controllo Kubernetes. 1 per ciascuno dei 3 nodi, 1 per l'IP virtuale e 1 per l'aggiornamento in sequenza del cluster. Nota: La rete di gestione e la rete del carico di lavoro devono trovarsi in subnet diverse. L'assegnazione della stessa subnet alla rete di gestione e del carico di lavoro non è supportata e può causare problemi ed errori di sistema.
VLAN della rete di gestione	1	ID VLAN della subnet della rete di gestione.
VLAN	3	Questi IP VLAN sono gli indirizzi IP per gli endpoint del tunnel (TEP). I TEP dell'host ESXi e i TEP Edge devono essere instradabili. Gli indirizzi IP VLAN sono necessari per i seguenti elementi: VTEP dell'host ESXi VTEP Edge che utilizza l'IP statico Gateway di livello 0 e uplink per il nodo di trasporto. Nota: Il VTEP dell'host ESXi e il VTEP Edge devono avere dimensioni di MTU superiori a 1600. Gli host ESXi e i nodi Edge NSX-T fungono da endpoint del tunnel e a ogni host e nodo Edge viene assegnato un IP dell'endpoint del tunnel (TEP). Poiché gli IP del TEP per gli host ESXi creano un tunnel overlay con IP TEP nei nodi Edge, gli IP della VLAN devono essere instradabili. È necessaria una VLAN aggiuntiva per fornire connettività nord-sud al gateway di livello 0. I pool di IP possono essere condivisi tra cluster. La VLAN/il pool di IP di overlay dell'host non devono invece essere condivisi con la VLAN/il pool di IP o di overlay Edge. Nota: Se il TEP host e il TEP Edge utilizzano schede NIC fisiche diverse, possono utilizzare la stessa VLAN.
IP uplink di livello 0	/24 indirizzi IP privati	La subnet IP utilizzata per l'uplink di livello 0. I requisiti per l'indirizzo IP dell'uplink di livello 0 sono i seguenti: 1 IP, se non si utilizza la ridondanza Edge. 4 IP, se si utilizza la ridondanza Edge e BGP, 2 indirizzi IP per Edge. 3 IP, se si utilizzano route statiche e la ridondanza Edge. L'IP di gestione Edge, la subnet, il gateway, l'IP di uplink e il gateway devono essere univoci.
MTU della rete fisica	1600	Le dimensioni di MTU devono essere pari a 1600 o più su qualsiasi rete che supporta il traffico overlay.
Intervallo CIDR Pod vSphere	/23 indirizzi IP privati	Intervallo CIDR privato che fornisce gli indirizzi IP per lPod vSphere. Questi indirizzi vengono utilizzati anche per i nodi del cluster Tanzu Kubernetes. È necessario specificare un intervallo CIDR Pod vSphere univoco per ogni cluster. Nota: L'intervallo CIDR Pod vSphere e l'intervallo CIDR per gli indirizzi del servizio Kubernetes non devono sovrapporsi.
Intervallo CIDR dei servizi Kubernetes	/16 indirizzi IP privati	Un intervallo CIDR privato per l'assegnazione di indirizzi IP ai servizi Kubernetes. È necessario specificare un intervallo CIDR dei servizi Kubernetes univoco per ogni Cluster supervisore.
Intervallo CIDR in uscita	/27 indirizzi IP statici	Annotazione CIDR privata per determinare l'IP in uscita per i servizi Kubernetes. Per ogni spazio dei nomi nel Cluster supervisore viene assegnato un solo indirizzo IP di uscita. L'IP in uscita è l'indirizzo utilizzato dalle entità esterne per comunicare con i servizi nello spazio dei nomi. Il numero di indirizzi IP in uscita limita il numero di criteri in uscita che può avere il Cluster supervisore. Il valore minimo è un CIDR di /27 o superiore. Ad esempio, 10.174.4.96/27. Nota: Gli indirizzi IP in uscita e gli indirizzi IP in entrata non devono sovrapporsi.
CIDR in entrata	/27 indirizzi IP statici	Intervallo CIDR privato da utilizzare per gli indirizzi IP degli ingressi. L'ingresso consente di applicare criteri di traffico alle richieste inserendo il Cluster supervisore da reti esterne. Il numero di indirizzi IP in ingresso limita il numero di ingressi che può avere il cluster. Il valore minimo è un CIDR di /27 o superiore. Nota: Gli indirizzi IP in uscita e gli indirizzi IP in entrata non devono sovrapporsi.