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 e fare clic su Visualizza limiti oppure seguire questo link.
Requisiti per un cluster di gestione, Edge e di dominio 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.
| 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 |
| 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:
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:
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:
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.
|
