Topologien für die Bereitstellung des HAProxy-Lastausgleichsdiensts

Überprüfen Sie die möglichen Topologien, die Sie für den HAProxy-Lastausgleichsdienst bei einem mit VDS-Netzwerk konfigurierten Supervisor implementieren können. Bei Verwendung von vSphere IaaS control plane mit VDS-Netzwerk bietet HAProxy Lastausgleich für Entwickler, die auf die Tanzu Kubernetes Grid-Steuerungsebene zugreifen, sowie für Kubernetes-Dienste vom Typ „Lastausgleichsdienst“.

Arbeitslastnetzwerke auf dem Supervisor

Zum Konfigurieren eines Supervisors mit dem VDS-Netzwerk müssen Sie alle Hosts aus dem Cluster mit einem VDS verbinden. Je nach der von Ihnen für die Supervisor-Arbeitslastnetzwerke implementierten Topologie können Sie eine oder mehrere verteilte Portgruppen erstellen. Sie bestimmen die Portgruppen als Arbeitslastnetzwerke für vSphere-Namespaces.

Arbeitslastnetzwerke bieten eine Verbindung zu den Knoten von Tanzu Kubernetes Grid-Clustern und zu den VMs der Supervisor Control Plane. Das Arbeitslastnetzwerk, das Konnektivität zu den Kubernetes-Steuerungsebenen-VMs bereitstellt, wird als „primäres Arbeitslastnetzwerk“ bezeichnet. Jeder Supervisor muss über ein primäres Arbeitslastnetzwerk verfügen. Sie müssen eine der verteilten Portgruppen als primäres Arbeitslastnetzwerk für den Supervisor festlegen.

Hinweis: Arbeitslastnetzwerke werden nur während der Supervisor-Aktivierung hinzugefügt und können später nicht mehr hinzugefügt werden.

Die Kubernetes-Steuerungsebenen-VMs im Supervisor verwenden drei IP-Adressen aus dem IP-Adressbereich, der dem primären Arbeitslastnetzwerk zugewiesen ist. Jeder Knoten eines Tanzu Kubernetes Grid-Clusters verfügt über eine eigene, aus dem Adressbereich des Arbeitslastnetzwerks zugewiesene IP-Adresse. Das Arbeitslastnetzwerk ist mit dem Namespace konfiguriert ist, in dem der Tanzu Kubernetes Grid-Cluster ausgeführt wird.

Zuteilung von IP-Bereichen

Wenn Sie die Planung für die Netzwerktopologie des Supervisors mit dem HAProxy-Lastausgleichsdienst vornehmen, sollten Sie die Verwendung von zwei IP-Bereichstypen einplanen:

• Ein Bereich für die Zuteilung virtueller IPs für HAProxy. Der IP-Bereich, den Sie für die virtuellen Server von HAProxy konfigurieren, ist von der Lastausgleichsdienst-Appliance reserviert. Wenn der Bereich für virtuelle IPs beispielsweise 192.168.1.0/24 lautet, sind sämtliche Hosts in diesem Bereich für keinen anderen Datenverkehr als den Datenverkehr über virtuelle IPs verfügbar.
  Hinweis: Sie dürfen kein Gateway innerhalb des virtuellen HAProxy-IP-Bereichs konfigurieren, da alle Routen zu einem solchen Gateway fehlschlagen.
• Ein IP-Bereich für die Knoten des Supervisors und der Tanzu Kubernetes Grid-Cluster. Jeder Kubernetes-Steuerungsebenen-VM im Supervisor ist eine IP-Adresse zugewiesen, in der Summe sind dies drei IP-Adressen. Jedem Knoten eines Tanzu Kubernetes Grid-Clusters ist auch eine eigene IP-Adresse zugewiesen. Sie müssen jedem Arbeitslastnetzwerk auf dem Supervisor, das Sie für einen Namespace konfigurieren, einen eindeutigen IP-Bereich zuweisen.

Beispiel für eine Konfiguration mit einem /24-Netzwerk:

• Netzwerk: 192.168.120.0/24
• HAProxy-VIPs: 192.168.120.128/25
• 1 IP-Adresse für die HAProxy-Arbeitslastschnittstelle: 192.168.120.5

Abhängig von den IPs, die innerhalb der ersten 128 Adressen frei sind, können Sie IP-Bereiche für Arbeitslastnetzwerke auf dem Supervisor definieren, z. B.:

• 192.168.120.31-192.168.120.40 für das primäre Arbeitslastnetzwerk
• 192.168.120.51-192.168.120.60 für ein weiteres Arbeitslastnetzwerk

Hinweis: Die Bereiche, die Sie für Arbeitslastnetzwerke definieren, dürfen sich nicht mit dem HAProxy-VIP-Bereich überschneiden.

HAProxy-Netzwerktopologie

Es gibt zwei Optionen für die Netzwerkkonfiguration für die Bereitstellung von HAProxy: Standard und Frontend. Das Standardnetzwerk verfügt über zwei Netzwerkkarten: eine für das Verwaltungsnetzwerk und eine für das Arbeitslastnetzwerk. Das Frontend-Netzwerk verfügt über 3 NICs: Verwaltungsnetzwerk, Arbeitslastnetzwerk und das Frontend-Netzwerk für Clients. In der Tabelle sind die Merkmale jedes Netzwerks aufgelistet und beschrieben.

Für Produktionsinstallationen empfiehlt es sich, den HAProxy-Lastausgleichsdienst mit der Konfiguration für das Frontend-Netzwerk zu implementieren. Wenn Sie den HAProxy-Lastausgleichsdienst mit der Standardkonfiguration bereitstellen, wird empfohlen, dass Sie dem Arbeitslastnetzwerk eine /24-IP-Adressblockgröße zuweisen. Für beide Konfigurationsoptionen wird DHCP nicht empfohlen.

Netzwerk	Merkmale
Verwaltung	Der Supervisor-Cluster nutzt das Verwaltungsnetzwerk, um eine Verbindung zum HAProxy-Lastausgleichsdienst herzustellen und diesen zu programmieren. Der HAProxy-Datenebenen-API-Endpoint ist an die mit dem Verwaltungsnetzwerk verbundene Netzwerkschnittstelle gebunden. Die der HAProxy-Steuerungsebenen-VM zugewiesene Verwaltungs-IP-Adresse muss eine statische IP im Verwaltungsnetzwerk sein, damit der Supervisor-Cluster zuverlässig eine Verbindung mit der Lastausgleichsdienst-API herstellen kann. Das Standard-Gateway für die HAProxy-VM sollte sich in diesem Netzwerk befinden. DNS-Abfragen sollten in diesem Netzwerk ausgeführt werden.
Arbeitslast	Die HAProxy-Steuerungsebenen-VM nutzt das Arbeitslastennetzwerk, um auf die Dienste im Supervisor-Cluster und auf den Tanzu Kubernetes-Clusterknoten zuzugreifen. Die HAProxy-Steuerungsebenen-VM leitet Datenverkehr an die Supervisor und die Tanzu Kubernetes-Clusterknoten in diesem Netzwerk weiter. Wenn die HAProxy-Steuerungsebenen-VM im Standardmodus (zwei Netzwerkkarten) bereitgestellt wird, muss das Arbeitslastnetzwerk die logischen Netzwerke bereitstellen, die für den Zugriff auf die Lastausgleichsdienste verwendet werden. In der Standardkonfiguration kommen die virtuellen IPs des Lastausgleichsdiensts und die IPs der Kubernetes-Clusterknoten von diesem Netzwerk. Sie werden als getrennte, nicht überlappende Bereiche innerhalb des Netzwerks definiert. Hinweis: Das Arbeitslastnetzwerk muss sich in einem anderen Subnetz als das Verwaltungsnetzwerk befinden. Weitere Informationen finden Sie in den Systemanforderungen.
Frontend (optional)	Externe Clients (z. B. Benutzer oder Anwendungen), die auf Clusterarbeitslasten zugreifen, verwenden das Frontend-Netzwerk, um über virtuelle IP-Adressen auf Backend-Lastausgleichsdienste zuzugreifen. Das Frontend-Netzwerk wird nur dann verwendet, wenn die HAProxy-Steuerungsebenen-VM mit drei Netzwerkkarten bereitgestellt wird. Empfohlen für Produktionsinstallationen. Das Frontend-Netzwerk ist der Ort, an dem Sie die virtuelle IP-Adresse (VIP) angeben. HAProxy sorgt für einen Ausgleich des Datenverkehrs und leitet diesen an das entsprechende Backend weiter.

Das folgende Diagramm veranschaulicht eine HAProxy-Bereitstellung mithilfe einer Frontend-Netzwerk-Topologie. Das Diagrammverzeichnis gibt an, wo während des Installations- und Konfigurationsvorgangs Konfigurationsfelder erwartet werden.

Supervisor-Topologie mit einem Arbeitslastnetzwerk und HAProxy mit zwei virtuellen Netzwerkkarten

In dieser Topologie konfigurieren Sie einen Supervisor mit einem Arbeitslastnetzwerk für die folgenden Komponenten:

• Kubernetes-Steuerungsebenen-VMs
• Die Knoten von Tanzu Kubernetes Grid-Clustern.
• Der virtuelle HAProxy-Bereich für Verbindungen externer Dienste und DevOps-Benutzer. In dieser Konfiguration wird HAProxy mit zwei virtuellen NICs (Standard-Konfiguration) bereitgestellt, wobei eine mit dem Verwaltungsnetzwerk und eine zweite mit dem primären Arbeitslastnetzwerk verbunden ist. Sie müssen die Zuteilung virtueller IPs in einem Subnetz planen, das vom primären Arbeitslastnetzwerk getrennt ist.

Sie legen eine Portgruppe als primäres Arbeitslastnetzwerk für den Supervisor fest und verwenden dann dieselbe Portgruppe als Arbeitslastnetzwerk für vSphere-Namespaces. Supervisor, Tanzu Kubernetes Grid-Cluster, HAProxy, DevOps-Benutzer und externe Dienste stellen alle eine Verbindung mit derselben verteilten Portgruppe her, die als primäres Arbeitslastnetzwerk festgelegt ist.

Abbildung 1. Von einem Netzwerk gestützter Supervisor

Der Datenverkehrspfad für die DevOps-Benutzer oder externe Anwendungen lautet wie folgt:

1. Der DevOps-Benutzer oder der externe Dienst sendet Datenverkehr an eine virtuelle IP-Adresse in einem Subnetz des Arbeitslastnetzwerks der verteilten Portgruppe.
2. HAProxy gleicht die Last des virtuellen IP-Datenverkehrs aus, der zur IP des Tanzu Kubernetes Grid-Clusterknotens oder zur IP der Steuerungsebenen-VM fließt. HAProxy beansprucht die virtuelle IP-Adresse, damit er die Last des auf dieser IP eingehenden Datenverkehrs ausgleichen kann.
3. Die Steuerungsebenen-VM oder der Tanzu Kubernetes Grid-Clusterknoten leitet den Datenverkehr an die Ziel-Pods weiter, die jeweils innerhalb des Supervisors oder des Tanzu Kubernetes Grid-Clusters ausgeführt werden.

Supervisor-Topologie mit einem isolierten Arbeitslastnetzwerk und einem HAProxy mit zwei virtuellen Netzwerkkarten

In dieser Topologie konfigurieren Sie Netzwerke für die folgenden Komponenten:

• Kubernetes-Steuerungsebenen-VMs. Ein primäres Arbeitslastnetzwerk für die Verarbeitung des Datenverkehrs für die Kubernetes-Steuerungsebenen-VMs.
• Tanzu Kubernetes Grid-Clusterknoten Ein Arbeitslastnetzwerk, das Sie allen Namespaces auf dem Supervisor zuweisen. Dieses Netzwerk verbindet die Tanzu Kubernetes Grid-Clusterknoten.
• Virtuelle HAProxy-IPs. In dieser Konfiguration wird die HAProxy-VM mit zwei virtuellen NICs bereitgestellt (Standard-Konfiguration). Sie können die HAProxy-VM entweder mit dem primären Arbeitslastnetzwerk oder mit dem Arbeitslastnetzwerk verbinden, das Sie für Namespaces verwenden. Sie können HAProxy auch mit einem VM-Netzwerk verbinden, das bereits in vSphere vorhanden ist und für das Routing in das primäre Arbeitslastnetzwerk und die Arbeitslastnetzwerke möglich ist.

Der Supervisor ist mit der verteilten Portgruppe verbunden, die das primäre Arbeitslastnetzwerk unterstützt, und Tanzu Kubernetes Grid-Cluster sind mit einer verteilten Portgruppe verbunden, die das Arbeitslastnetzwerk unterstützt. Die beiden Portgruppen müssen für Schicht-3-Routing geeignet sein. Sie können die Schicht 2-Isolierung über VLANs implementieren. Die Filterung des Schicht-3-Datenverkehrs ist über IP-Firewalls und -Gateways möglich.

Abbildung 2. Supervisor mit einem isolierten Arbeitslastnetzwerk

Der Datenverkehrspfad für DevOps-Benutzer oder den externen Dienst lautet wie folgt:

1. Der DevOps-Benutzer oder der externe Dienst sendet Datenverkehr an eine virtuelle IP. Der Datenverkehr wird an das Netzwerk weitergeleitet, mit dem HAProxy verbunden ist.
2. HAProxy gleicht die Last des virtuellen IP-Datenverkehrs aus, der zur IP des Tanzu Kubernetes Grid-Knotens oder zur Steuerungsebenen-VM fließt. HAProxy beansprucht die virtuelle IP-Adresse, damit er die Last des auf dieser IP eingehenden Datenverkehrs ausgleichen kann.
3. Die Steuerungsebenen-VM oder der Tanzu Kubernetes Grid-Clusterknoten leitet den Datenverkehr an die Ziel-Pods weiter, die innerhalb des Tanzu Kubernetes Grid-Clusters ausgeführt werden.

Supervisor-Topologie mit mehreren Arbeitslastnetzwerken und HAProxy mit zwei virtuellen Netzwerkkarten

In dieser Topologie können Sie eine Portgruppe so konfigurieren, dass sie als primäres Arbeitslastnetzwerk agiert, und Sie können eine dedizierte Portgruppe als Arbeitslastnetzwerk für jeden Namespace konfigurieren. HAProxy wird mit zwei virtuellen Netzwerkkarten bereitgestellt (Standard-Konfiguration), und Sie können eine Verbindung mit dem primären Arbeitslastnetzwerk oder den anderen Arbeitslastnetzwerken herstellen. Sie können auch ein vorhandenes VM-Netzwerk verwenden, für das Routing in das primäre Arbeitslastnetzwerk und die Arbeitslastnetzwerke möglich ist.

Der Datenverkehrspfad für die DevOps-Benutzer und externe Dienste in dieser Topologie ist identisch mit demjenigen der Topologie mit einem isolierten Arbeitslastnetzwerk.

Abbildung 3. Von mehreren isolierten Arbeitslastnetzwerken gestützter Supervisor

Supervisor-Topologie mit mehreren Arbeitslastnetzwerken und HAProxy mit drei virtuellen Netzwerkkarten

In dieser Konfiguration stellen Sie die HAProxy-VM mit drei virtuellen NICs bereit und verbinden damit HAProxy mit einem Frontend-Netzwerk. DevOps Benutzer und externe Dienste können über virtuelle IPs im Frontend-Netzwerk auf HAProxy zugreifen. Die Bereitstellung von HAProxy mit drei virtuellen Netzwerkkarten wird für Produktionsumgebungen empfohlen.

Abbildung 4. HAProxy-Bereitstellung mit drei virtuellen NICs

Auswählen zwischen den möglichen Topologien

Bevor Sie zwischen den möglichen Topologien auswählen, analysieren Sie die Anforderungen Ihrer Umgebung:

1. Benötigen Sie eine Schicht-2-Isolierung zwischen dem Supervisor und Tanzu Kubernetes Grid-Clustern?
   1. Nein: die einfachste Topologie mit einem Arbeitslastnetzwerk, das alle Komponenten bedient.
   2. Ja: die isolierte Arbeitslastnetzwerk-Topologie mit getrennten primären und Arbeitslastnetzwerken.
2. Benötigen Sie eine weitere Schicht-2-Isolierung zwischen Ihren Tanzu Kubernetes Grid-Clustern?
   1. Nein: isolierte Arbeitslastnetzwerk-Topologie mit getrennten primärem Arbeitslastnetzwerk und Arbeitslastnetzwerken.
   2. Ja: mehrere Arbeitslastnetzwerk-Topologien mit einem getrennten Arbeitslastnetzwerk für jeden Namespace und einem dedizierten primären Arbeitslastnetzwerk.
3. Möchten Sie verhindern, dass Ihre DevOps-Benutzer und externe Dienste ein direktes Routing zu VMs der Steuerungsebene von Kubernetes und Tanzu Kubernetes Grid-Clusterknoten ausführen?
   1. Nein: HAProxy-Konfiguration mit zwei NICs.
   2. Ja: HAProxy-Konfiguration mit drei NICs Diese Konfiguration wird für Produktionsumgebungen empfohlen.

Überlegungen zur Verwendung des HAProxy-Lastausgleichsdiensts mit vSphere IaaS control plane

Beachten Sie beim Planen eines vSphere IaaS control plane mit dem HAProxy-Lastausgleichsdienst Folgendes.

• Ein Support-Vertrag mit HAProxy ist erforderlich, um technischen Support für den HAProxy-Lastausgleichsdienst zu erhalten. VMware GSS kann für die HAProxy-Appliance keinen Support bieten.
• Die HAProxy-Appliance ist ein Singleton ohne Möglichkeit für eine hochverfügbare Topologie. Für hochverfügbare Umgebungen empfiehlt VMware die Verwendung einer vollständigen Installation von NSX oder den NSX Advanced Load Balancer.
• Es ist nicht möglich, den für das Front-End verwendeten IP-Adressbereich zu einem späteren Zeitpunkt zu erweitern. Dies bedeutet, dass das Netzwerk für das gesamte zukünftige Wachstum dimensioniert werden sollte.