Überprüfen Sie die Systemanforderungen zum Konfigurieren von vSphere with Tanzu auf einem vSphere-Cluster mithilfe des NSX-T Data Center-Netzwerk-Stacks.

Konfigurationsgrenzwerte für vSphere with Tanzu-Cluster

VMware stellt im Tool für die Maximalwerte für die VMware-Konfiguration Konfigurationsgrenzwerte bereit.

Wählen Sie für die für vSphere with Tanzu spezifischen Konfigurationsgrenzwerte, einschließlich Supervisor-Cluster und Tanzu Kubernetes-Clustern, vSphere > vSphere 7.0 > vSphere with Kubernetes > VMware Tanzu Kubernetes Grid Service for vSphere aus und klicken Sie auf Grenzwerte anzeigen oder folgen Sie diesem Link.

Anforderungen für einen Verwaltungs-, Edge- und Arbeitslastdomänen-Cluster

Sie können vSphere with Tanzu mit kombinierten Verwaltungs-, Edge- und Arbeitslastverwaltungsfunktionen in einem einzelnen vSphere-Cluster bereitstellen.
Tabelle 1. Mindestberechnungsanforderungen für Verwaltungs-, Edge- und Arbeitslastverwaltungscluster
System Mindestbereitstellungsgröße CPU Arbeitsspeicher Speicher
vCenter Server 7.0 Klein 2 16 GB 290 GB
ESXi-Hosts 7.0 3 ESXi-Hosts mit 1 statischer IP-Adresse pro Host.

Bei Verwendung von vSAN: 3 ESXi-Hosts mit mindestens 2 physischen NICs pro Host sind mindestens erforderlich. Es werden jedoch 4 ESXi-Hosts für Stabilität beim Patchen und Aktualisieren empfohlen.

Die Hosts müssen in einem Cluster mit aktiviertem vSphere DRS und HA verbunden sein. vSphere DRS muss sich im vollautomatischen oder teilweise automatisierten Modus befinden.

Vorsicht: Deaktivieren Sie nach der Konfiguration des Supervisor-Cluster nicht vSphere DRS. Die ständige Aktivierung von DRS ist eine obligatorische Voraussetzung für die Ausführung von Arbeitslasten auf dem Supervisor-Cluster. Das Deaktivieren von DRS führt zu einem Ausfall Ihrer Tanzu Kubernetes-Cluster.
8 64 GB pro Host Nicht anwendbar
NSX Manager Mittel 6 24 GB 300 GB
NSX Edge 1 Groß 8 32 GB 200 GB
NSX Edge 2 Groß 8 32 GB 200 GB
Kubernetes-Steuerungsebenen-VMs 3 4 16 GB 16 GB

Topologie mit separatem Verwaltungs- und Edge-Cluster und Arbeitslastverwaltungscluster

Sie können vSphere with Tanzu in zwei Clustern bereitstellen: einem Cluster für die Verwaltungs- und Edge-Funktionen und einem weiteren für die Arbeitslastverwaltung.

Tabelle 2. Mindestberechnungsanforderungen für den Verwaltungs- und Edge-Cluster
System Mindestbereitstellungsgröße CPU Arbeitsspeicher Speicher
vCenter Server 7.0 Klein 2 16 GB 290 GB
ESXi-Hosts 7.0 2 ESXi-Hosts 8 64 GB pro Host Nicht anwendbar
NSX Manager Mittel 6 24 GB 300 GB
NSX Edge 1 Groß 8 32 GB 200 GB
NSX Edge 2 Groß 8 32 GB 200 GB
Tabelle 3. Mindestberechnungsanforderungen für den Arbeitslastverwaltungscluster
System Mindestbereitstellungsgröße CPU Arbeitsspeicher Speicher
ESXi-Hosts 7.0 3 ESXi-Hosts mit 1 statischer IP-Adresse pro Host.

Bei Verwendung von vSAN: 3 ESXi-Hosts mit mindestens zwei physischen Netzwerkkarten pro Host sind erforderlich. Während der Durchführung von Patches und Upgrades werden zu Stabilitätszwecken jedoch 4 ESXi-Host empfohlen.

Die Hosts müssen in einem Cluster mit aktiviertem vSphere DRS und HA verbunden sein. vSphere DRS muss im vollautomatisierten Modus ausgeführt werden.

Vorsicht: Deaktivieren Sie nach der Konfiguration des Supervisor-Cluster nicht vSphere DRS. Die ständige Aktivierung von DRS ist eine obligatorische Voraussetzung für die Ausführung von Arbeitslasten auf dem Supervisor-Cluster. Das Deaktivieren von DRS führt zu einem Ausfall Ihrer Tanzu Kubernetes-Cluster.
8 64 GB pro Host Nicht anwendbar
Kubernetes-Steuerungsebenen-VMs 3 4 16 GB 16 GB

Netzwerkanforderungen

Unabhängig von der Topologie, die Sie für die Kubernetes-Arbeitslastverwaltung in vSphere implementieren, muss Ihre Bereitstellung die Netzwerkanforderungen erfüllen, die in der folgenden Tabelle aufgelistet sind.
Hinweis: Sie können weder IPv6-Cluster mit einem vSphere 7- Supervisor-Cluster erstellen noch IPv6-Cluster mit Tanzu Mission Control registrieren.
Komponente Mindestanzahl Erforderliche Konfiguration
Statische IPs für Kubernetes Control Plane-VMs Block mit 5 Ein Block mit 5 aufeinanderfolgenden statischen IP-Adressen, die den Kubernetes-Steuerungsebenen-VMs im Supervisor-Cluster zugewiesen werden.
Verwaltungsdatenverkehr-Netzwerk 1 Ein Verwaltungsnetzwerk, das zu den ESXi-Hosts, vCenter Server und einem DHCP-Server geroutet werden kann. Das Netzwerk muss in der Lage sein, auf eine Container-Registrierung zuzugreifen, und benötigt eine Internetverbindung, wenn sich die Container-Registrierung im externen Netzwerk befindet. Die Container-Registrierung muss über DNS aufgelöst werden können, und die unten beschriebene Egress-Einstellung muss sie erreichen können.
NTP- und DNS-Server 1 Ein DNS-Server und ein NTP-Server, die für den vCenter Server verwendet werden können.
Hinweis: Konfigurieren Sie NTP auf allen ESXi-Hosts, vCenter Server-Systemen und NSX Manager-Instanzen.
DHCP-Server 1 Optional. Konfigurieren Sie einen DHCP-Server, um automatisch IP-Adressen für die Verwaltung zu erfassen. Der DHCP-Server muss Clientbezeichner unterstützen und kompatible DNS-Server, DNS-Suchdomänen und einen NTP-Server bereitstellen.
Image-Registrierung 1 Zugriff auf eine Registrierung für den Dienst.
Verwaltungsnetzwerk-Subnetz 1
Das Subnetz, das für den Verwaltungsdatenverkehr zwischen ESXi-Hosts und vCenter Server, NSX-Appliances und der Kubernetes-Steuerungsebene verwendet wird. Das Subnetz muss folgende Größe haben:
  • 1 IP-Adresse pro VMkernel-Adapter eines Hosts.
  • 1 IP-Adresse für die vCenter Server-Appliance.
  • 1 oder 4 IP-Adressen für NSX Manager. 4 IP-Adressen bei NSX Manager-Clustering von 3 Knoten und 1 virtuellen IP (VIP).
  • 5 IP-Adressen für die Kubernetes-Steuerungsebene. 1 für jeden der 3 Knoten, 1 für virtuelle IP, 1 für fortlaufendes Cluster-Upgrade.
Hinweis: Das Verwaltungsnetzwerk und das Arbeitslastnetzwerk müssen sich in unterschiedlichen Subnetzen befinden. Das Zuweisen desselben Subnetzes zu den Verwaltungs- und Arbeitslastnetzwerken wird nicht unterstützt und kann zu Systemfehlern und Problemen führen.
Verwaltungsnetzwerk-VLAN 1 VLAN-ID des Verwaltungsnetzwerk-Subnetzes.
VLANs 3 Diese VLAN-IPs sind die IP-Adressen für die Tunnel-Endpoints (TEP). Die TEPs des ESXi-Hosts und die Edge-TEPs müssen routingfähig sein.
VLAN-IP-Adressen sind für Folgendes erforderlich:
  • ESXi-Host-VTEP
  • Edge-VTEP mit statischer IP-Adresse
  • Tier-0-Gateway und Uplink für Transportknoten.
Hinweis: Der ESXi-Host-VTEP und der Edge-VTEP müssen eine MTU-Größe von mehr als 1600 aufweisen.

ESXi-Hosts und NSX-T-Edge-Knoten fungieren als Tunnel-Endpoints, und jedem Host sowie jedem Edge-Knoten wird eine TEP-IP zugewiesen.

Da die TEP-IPs für ESXi-Hosts einen Overlay-Tunnel mit TEP-IPs auf den Edge-Knoten erstellen, müssen die VLAN-IPs routingfähig sein.

Ein zusätzliches VLAN ist erforderlich, um Nord-Süd-Konnektivität zum Tier-0-Gateway zu bieten.

IP-Pools können über Cluster hinweg gemeinsam genutzt werden. Der Host-Overlay-IP-Pool/VLAN darf jedoch nicht mit einem Edge-Overlay-IP-Pool/VLAN gemeinsam genutzt werden.

Hinweis: Wenn Host-TEP und Edge-TEP verschiedene physische Netzwerkkarten verwenden, können sie dasselbe VLAN verwenden.
Tier-0-Uplink-IP /24 private IP-Adressen Das IP-Subnetz, das für den Tier-0-Uplink verwendet wird. Für die IP-Adresse des Tier-0-Uplinks gelten folgende Anforderungen:
  • 1 IP, wenn Sie keine Edge-Redundanz verwenden.
  • 4 IPs, wenn Sie BGP und Edge-Redundanz verwenden – 2 IP-Adressen pro Edge.
  • 3 IPs, wenn Sie statische Routen und Edge-Redundanz verwenden.

Die IP, das Subnetz und das Gateway für die Edge-Verwaltung und die IP, das Subnetz und das Gateway für Uplink müssen eindeutig sein.
Physische Netzwerk-MTU 1600 Die MTU-Größe muss für jedes Netzwerk, das Overlay-Datenverkehr überträgt, mindestens 1600 betragen.
CIDR-Bereich für vSphere Pods /23 private IP-Adressen Ein privater-CIDR-Bereich, der IP-Adressen für vSphere-Pods bereitstellt. Diese Adressen werden auch für die Tanzu Kubernetes-Clusterknoten verwendet.
Sie müssen einen eindeutigen vSphere Pod-CIDR-Bereich für jeden Cluster angeben.
Hinweis: Der CIDR-Bereich für vSphere Pods und der CIDR-Bereich für die Kubernetes-Dienstadressen dürfen sich nicht überlappen.
CIDR-Bereich für Kubernetes-Dienste /16 private IP-Adressen Ein privater CIDR-Bereich für die Zuweisung von IP-Adressen zu Kubernetes-Diensten. Sie müssen für jeden Supervisor-Cluster einen eindeutigen CIDR-Bereich für Kubernetes-Dienste angeben.
Egress-CIDR-Bereich /27 statische IP-Adressen Eine CIDR-Anmerkung zur Ermittlung der Egress-IP für Kubernetes-Dienste. Für jeden Namespace im Supervisor-Cluster wird nur eine Egress-IP-Adresse zugewiesen. Die Egress-IP ist die Adresse, die externe Entitäten für die Kommunikation mit den Diensten im Namespace verwenden. Die Anzahl der Egress-IP-Adressen beschränkt die Anzahl der Egress-Richtlinien, die der Supervisor-Cluster haben kann.
Die Mindestanzahl ist ein CIDR von/27 oder mehr. Beispielsweise 10.174.4.96/27
Hinweis: Egress-IP-Adressen und Ingress-IP-Adressen dürfen sich nicht überlappen.
Ingress-CIDR /27 statische IP-Adressen Ein privater CIDR-Bereich, der für Ingress-IP-Adressen verwendet wird. Mit Ingress können Sie Datenverkehrsrichtlinien auf Anforderungen anwenden, die in den Supervisor-Cluster von externen Netzwerken eingehen. Die Anzahl der Ingress-IP-Adressen beschränkt die Anzahl der Ingresses, die der Cluster haben kann.
Die Mindestanzahl ist ein CIDR von/27 oder mehr.
Hinweis: Egress-IP-Adressen und Ingress-IP-Adressen dürfen sich nicht überlappen.