Topologien für die Bereitstellung des HAProxy-Lastausgleichsdiensts

Bei Verwendung von vSphere with Tanzu mit vDS-Netzwerk bietet HAProxy Lastausgleich für Entwickler, die auf die Tanzu Kubernetes-Steuerungsebene zugreifen, sowie für Kubernetes-Dienste vom Typ „Lastausgleichsdienst“. Überprüfen Sie die möglichen Topologien, die Sie für den HAProxy-Lastausgleichsdienst implementieren können.

Arbeitslastnetzwerke auf dem Supervisor-Cluster

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

Bevor Sie einen Host zu einem Supervisor-Cluster hinzufügen, müssen Sie ihn zu allen vSphere Distributed Switches hinzufügen, die Teil des Clusters sind.

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

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

Die Kubernetes-Steuerungsebenen-VMs im Supervisor-Cluster verwenden drei IP-Adressen aus dem IP-Adressbereich, der dem primären Arbeitslastnetzwerk zugewiesen ist. Jeder Knoten eines Tanzu Kubernetes-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-Cluster ausgeführt wird.

Zuteilung von IP-Bereichen

Wenn Sie die Planung für die Netzwerktopologie des Supervisor-Clusters 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 Supervisor-Clusters und der Tanzu Kubernetes-Cluster. Jeder Kubernetes-Steuerungsebenen-VM im Supervisor-Cluster ist eine IP-Adresse zugewiesen, in der Summe sind dies drei IP-Adressen. Jedem Knoten eines Tanzu Kubernetes-Clusters ist auch eine eigene IP-Adresse zugewiesen. Sie müssen jedem Arbeitslastnetzwerk auf dem Supervisor-Cluster, 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-Cluster 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 2 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-Cluster-Topologie mit einem Arbeitslastnetzwerk und HAProxy mit zwei virtuellen Netzwerkkarten

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

• Kubernetes-Steuerungsebenen-VMs
• Die Knoten von Tanzu Kubernetes-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-Cluster fest und verwenden dann dieselbe Portgruppe als Arbeitslastnetzwerk für vSphere-Namespaces. Supervisor-Cluster, Tanzu Kubernetes-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-Cluster

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-Knotens 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-Clusterknoten leitet den Datenverkehr an die Ziel-Pods weiter, die jeweils innerhalb des Supervisor-Clusters oder des Tanzu Kubernetes-Clusters ausgeführt werden.

Supervisor-Cluster-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-Clusterknoten Ein Arbeitslastnetzwerk, das Sie allen Namespaces auf dem Supervisor-Cluster zuweisen. Dieses Netzwerk verbindet die Tanzu Kubernetes-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-Cluster ist mit der verteilten Portgruppe verbunden, die das primäre Arbeitslastnetzwerk unterstützt, und Tanzu Kubernetes-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-Cluster 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-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-Clusterknoten leitet den Datenverkehr an die Ziel-Pods weiter, die innerhalb des Tanzu Kubernetes-Clusters ausgeführt werden.

Supervisor-Cluster-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-Cluster

Supervisor-Cluster-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-Cluster und Tanzu Kubernetes-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-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-Clusterknoten ausführen?
   1. Nein: HAProxy-Konfiguration mit zwei NICs.
   2. Ja: HAProxy-Konfiguration mit drei NICs Diese Konfiguration wird für Produktionsumgebungen empfohlen.