Klassisch: Informationen zu Netzlastausgleichsfunktionen (NLBs)

Netzlastausgleichsfunktionen können nur in klassischen Clustern erstellt werden. Wie der Lastausgleich in VPC-Clustern erfolgt, erfahren Sie unter Apps mit Lastausgleichsfunktionen für VPC zugänglich machen.

Wenn Sie einen Standardcluster erstellen, stellt Red Hat® OpenShift® on IBM Cloud® automatisch ein portierbares öffentliches Teilnetz und ein portierbares privates Teilnetz bereit.

  • Das portierbare öffentliche Teilnetz stellt 5 verwendbare IP-Adressen bereit. 1 portierbare öffentliche IP-Adresse wird vom Standardwert Öffentliche Ingress-ALB verwendet. Die verbleibenden vier portierbaren öffentlichen IP-Adressen können verwendet werden, um einzelne Apps dem Internet zugänglich zu machen, indem öffentliche Netzausgleichsfunktions- (NLB-) Services erstellt werden.
  • Das tragbare private Subnetz bietet 5 nutzbare IP-Adressen. 1 tragbare private IP-Adresse wird vom standardmäßigen privaten Ingress ALB verwendet. Die verbleibenden vier portierbaren privaten IP-Adressen können verwendet werden, um einzelne Apps einem privaten Netz zugänglich zu machen, indem private Services für die Lastausgleichsfunktion erstellt werden.

Um eine App sowohl über ein portierbare öffentliche als auch über eine portierbare private IP-Adresse zugänglich zu machen, müssen Sie sowohl eine öffentliche NLB als auch eine private NLB erstellen. Portierbare öffentliche und private IP-Adressen sind statische variable IP-Adressen und ändern sich nicht, wenn ein Workerknoten entfernt wird. Wenn der Arbeitsknoten, auf dem sich die NLB-IP-Adresse befindet, entfernt wird, verschiebt ein Keepalive-Daemon, der die IP-Adresse ständig überwacht, die IP-Adresse automatisch auf einen anderen Arbeitsknoten. Sie können Ihrer NLB jeden beliebigen Port zuweisen. Die NLB fungiert als externer Einstiegspunkt für eingehende Anforderungen an die App. Für den Zugriff auf die NLB über das Internet können die öffentliche IP-Adresse Ihrer NLB und der zugeordnete Port im Format <IP_address>:<port> verwendet werden. Sie können DNS-Einträge für NLBs auch erstellen, indem Sie die NLB-IP-Adressen mit Unterdomänen registrieren.

Wenn Sie eine App mithilfe eines NLB-Service zugänglich machen, wird Ihre App automatisch auch über die NodePorts des Service bereitgestellt. Auf Knotenports (NodePorts) kann über jede öffentliche und private IP-Adresse jedes Workerknotens innerhalb des Clusters zugegriffen werden. Informationen zum Blockieren des Datenverkehrs an Knotenports während der Verwendung einer NLB finden Sie im Abschnitt Eingehenden Datenverkehr an Netzlastausgleichsfunktion (NLB) oder NodePort-Services steuern.

Obwohl das Kubernetes SCTP-Protokoll im Release der Kubernetes-Community allgemein verfügbar ist, wird die Erstellung von Lastausgleichsfunktionen, die dieses Protokoll verwenden, in IBM Cloud Kubernetes Service-Clustern nicht unterstützt.

Vergleich des Basis- und DSR-Lastausgleichs in NLBs der Versionen 1.0 und 2.0

Wenn Sie eine NLB erstellen, können Sie eine NLB der Version 1.0 auswählen, die einen Basislastausgleich ausführt, oder eine NLB der Version 2.0, die einen DSR-Lastausgleich (DSR - Direct Server Return) ausführt.

Inwiefern sind die NLBs 1.0 und 2.0 ähnlich?
Die NLBs der Versionen 1.0 und 2.0 sind beides Layer 4-Lastausgleichsfunktionen, die sich im Linux-Kernelbereich befinden. Beide Versionen werden innerhalb des Clusters ausgeführt und verwenden Ressourcen von Workerknoten. Deshalb ist die verfügbare Kapazität der NLBs immer Ihrem eigenen Cluster zugeordnet. Darüber hinaus beenden beide Versionen von NLBs die Verbindung nicht. Stattdessen leiten sie Verbindungen an einen App-Pod weiter.
Wie unterscheiden sich die NLBs der Versionen 1.0 und 2.0?
Wenn ein Client eine Anforderung an Ihre App sendet, leitet die NLB Anforderungspakete an die IP-Adresse des Workerknotens weiter, auf dem ein App-Pod vorhanden ist. NLBs der Version 1.0 verwenden NAT (Network Address Translation, Netzadressumsetzung), um die Quellen-IP-Adresse des Anforderungspakets in die IP des Workerknotens umzuschreiben, auf dem ein Lastausgleichsfunktions-Pod vorhanden ist. Wenn der Workerknoten das App-Antwortpaket zurückgibt, wird die IP des Workerknotens, auf dem die NLB vorhanden ist, verwendet. Die NLB muss dann das Antwortpaket an den Client senden. Um zu verhindern, dass die IP-Adresse neu geschrieben wird, können Sie die Beibehaltung der Quellen-IP aktivieren. Die Beibehaltung der Quellen-IP erfordert jedoch, dass Lastausgleichsfunktions-Pods und App-Pods auf demselben Worker ausgeführt werden, sodass die Anforderung nicht an einen anderen Worker weitergeleitet werden muss. Sie müssen Knotenaffinität und -tolerierungen zu App-Pods hinzufügen. Weitere Informationen zum Basislastausgleich mit NLBs der Version 1.0 finden Sie unter Komponenten und Architektur einer NLB der Version 1.0.

Im Gegensatz zu den NLBs der Version 1.0 verwenden die NLBs der Version 2.0 NAT nicht, wenn Anforderungen an App-Pods an andere Worker weitergeleitet werden. Wenn eine NLB der Version 2.0 eine Clientanforderung weiterleitet, verwendet sie IP über IP (IPIP), um das ursprüngliche Anforderungspaket in ein anderes Paket einzubinden. Dieses einbindende IPIP-Paket hat eine Quellen-IP des Workerknotens, auf dem sich der Lastausgleichsfunktions-Pod befindet. Dadurch kann das ursprüngliche Anforderungspaket die Client-IP-Adresse als Quellen-IP-Adresse beibehalten. Der Workerknoten verwendet dann DSR (Direct Server Return), um das App-Antwortpaket an die Client-IP zu senden. Das Antwortpaket überspringt die NLB und wird direkt an den Client gesendet, wodurch der Umfang des Datenverkehrs reduziert wird, den die NLB verarbeiten muss. Weitere Informationen zum DSR-Lastausgleich mit NLBs der Version 2.0 finden Sie unter Komponenten und Architektur einer NLB der Version 2.0.

Komponenten und Architektur eines NLB der Version 1.0

Die TCP/UDP-Netzlastausgleichsfunktion (NLB) der Version 1.0 verwendet 'Iptables', ein Linux-Kernel-Feature, für den Lastausgleich von Anforderungen in den Pods einer App.

Datenfluss in einem Einzelzonencluster

Das folgende Diagramm veranschaulicht, wie eine NLB der Version 1.0 die Kommunikation vom Internet an eine App in einem Einzelzonencluster leitet.

Stellen Sie eine App in einem Single-Zone-Cluster bereit, indem Sie einen NLB verwenden 1.0.
Expose an app in a single-zone cluster by using an NLB 1.0

  1. Eine Anforderung an Ihre App verwendet die öffentliche IP-Adresse der NLB und den zugeordneten Port auf dem Workerknoten. Hinweis: Wenn Sie eine DNS-Unterdomäne für Ihre NLB erstellen, können die Benutzer über die Unterdomäne der NLB auf Ihre App zugreifen. Ein DNS-Systemservice löst die Unterdomäne in die portierbare öffentliche IP-Adresse der NLB auf.

  2. Die NLB empfängt die Anforderung und leitet sie über das private Netz an die private IP-Adresse des App-Pods weiter. Die Quellen-IP-Adresse des Anforderungspakets wird in die öffentliche IP-Adresse des Workerknotens geändert, auf dem der NLB-Pod ausgeführt wird. Wenn mehrere App-Instanzen im Cluster bereitgestellt werden, leitet die NLB die Anforderungen zwischen den App-Pods weiter.

  3. Wenn die App ein Antwortpaket zurückgibt, verwendet sie die IP-Adresse des Workerknotens, auf dem sich die NLB, die die Clientanforderung weitergeleitet hat, befindet. Die NLB sendet dann das Antwortpaket an den Client.

Datenfluss in einem Mehrzonencluster

Das folgende Diagramm veranschaulicht, wie eine Netzlastausgleichsfunktion (NLB) der Version 1.0 die Kommunikation vom Internet an eine App in einem Mehrzonencluster leitet.

Verwendung eines NLB 1.0 zum Lastausgleich von Anwendungen in einem
eines NLB 1.0 zum Lastausgleich von Anwendungen in einem

  1. Eine Anforderung an Ihre App verwendet die DNS-Unterdomäne für Ihre NLBs. Sie können auch in jeder Zone auf die NLB zugreifen, indem Sie die zugehörige öffentliche IP-Adresse und den zugehörigen Port auf dem Workerknoten verwenden. Hinweis: Standardmäßig werden NLBs der Version 1.0 nur in einer Zone konfiguriert. Um eine hohe Verfügbarkeit zu erreichen, müssen Sie eine NLB der Version 1.0 in jeder Zone bereitstellen, in der sich App-Instanzen befinden.

  2. Ein DNS-Systemservice löst die Unterdomäne in die portierbare öffentliche IP-Adresse einer der NLBs und den zugeordneten Port auf dem Workerknoten auf. Anforderungen werden von den NLBs in verschiedenen Zonen in einem Umlaufzyklus bearbeitet.

  3. Die NLB empfängt die Anforderung und leitet sie über das private Netz an die private IP-Adresse des App-Pods weiter. Die Quellen-IP-Adresse des Anforderungspakets wird in die öffentliche IP-Adresse des Workerknotens geändert, auf dem der NLB-Pod ausgeführt wird. Jede NLB leitet Anforderungen an die App-Instanzen in ihrer eigenen Zone und an App-Instanzen in anderen Zonen weiter. Wenn mehrere App-Instanzen in einer Zone bereitgestellt sind, leitet die NLB die Anforderungen zwischen den App-Pods in der Zone weiter.

  4. Wenn die App ein Antwortpaket zurückgibt, verwendet sie die IP-Adresse des Workerknotens, auf dem sich die NLB, die die Clientanforderung weitergeleitet hat, befindet. Die NLB sendet dann das Antwortpaket an den Client.

Komponenten und Architektur eines NLB der Version 2.0

Die NLB der Version 2.0 ist eine Layer 4-Lastausgleichsfunktion, die den IPVS (IP Virtual Server) des Linux-Kernels verwendet. Die NLB 2.0 unterstützt TCP und UDP, wird vor mehreren Workerknoten ausgeführt und verwendet IPIP-Tunneling (IP über IP), um Datenverkehr zu verteilen, der über eine einzelne NLB-IP-Adresse für alle diese Workerknoten eingeht.

Datenfluss in einem Einzelzonencluster

Das folgende Diagramm veranschaulicht, wie eine NLB der Version 2.0 die Kommunikation vom Internet an eine App in einem Einzelzonencluster leitet.

Expose eine Anwendung in Red Hat OpenShift on IBM Cloud durch Verwendung einer Version 2.0
eine Anwendung in Red Hat OpenShift on IBM Cloud durch Verwendung einer Version 2.0

  1. Eine Clientanforderung an Ihre App verwendet die öffentliche IP-Adresse der NLB und den zugeordneten Port auf dem Workerknoten. In diesem Beispiel verfügt die NLB über die virtuelle IP-Adresse 169.61.23.130 und wird auf dem Workerknoten mit der privaten IP-Adresse 10.73.13.25 ausgeführt. Hinweis: Wenn Sie eine DNS-Unterdomäne für Ihre NLB erstellen, können die Benutzer über die Unterdomäne der NLB auf Ihre App zugreifen. Ein DNS-Systemservice löst die Unterdomäne in die portierbare öffentliche IP-Adresse der NLB auf.

  2. Die NLB kapselt das Clientanforderungspaket (im Bild als "CR" gekennzeichnet) in ein IPIP-Paket (gekennzeichnet als "IPIP") ein. Das Clientanforderungspaket behält die Client-IP als Quellen-IP-Adresse bei. Das einschließende IPIP-Paket verwendet die IP des Workers 10.73.14.25 als Quellen-IP-Adresse.

  3. Die NLB leitet das IPIP-Paket an einen Worker mit aktivem App-Pod und der privaten IP-Adresse 10.73.13.26 weiter. Wenn mehrere App-Instanzen im Cluster bereitgestellt werden, leitet die NLB die Anforderungen zwischen den Workern weiter, auf denen App-Pods bereitgestellt sind.

  4. Worker 10.73.14.26 entpackt das einschließende IPIP-Paket und dann das Clientanforderungspaket. Das Clientanforderungspaket wird an den App-Pod auf diesem Workerknoten weitergeleitet.

  5. Worker 10.73.14.26 verwendet dann die Quellen-IP-Adresse aus dem ursprünglichen Anforderungspaket, die Client-IP, um das Antwortpaket des App-Pods direkt an den Client zurückzugeben.

Datenfluss in einem Mehrzonencluster

Das folgende Diagramm veranschaulicht, wie NLBs der Version 2.0 in den einzelnen Zonen Datenverkehr vom Internet an eine App in einem Mehrzonencluster weiterleiten.

Expose an app in Red Hat OpenShift on IBM Cloud by using an NLB 2.0
Expose an app in Red Hat OpenShift on IBM Cloud by using an NLB 2.0

  1. Eine Anforderung an Ihre App verwendet die DNS-Unterdomäne für Ihre NLBs. Sie können auch in jeder Zone auf die NLB zugreifen, indem Sie die zugehörige öffentliche IP-Adresse und den zugehörigen Port auf dem Workerknoten verwenden. Hinweis: Standardmäßig werden NLBs der Version 2.0 nur in einer Zone konfiguriert. Um eine hohe Verfügbarkeit zu erreichen, müssen Sie eine NLB der Version 2.0 in jeder Zone bereitstellen, in der sich App-Instanzen befinden.

  2. Ein DNS-Systemservice löst die Unterdomäne in die portierbare öffentliche IP-Adresse einer der NLBs und den zugeordneten Port auf dem Workerknoten auf. In diesem Beispiel verfügt die NLB über die virtuelle IP-Adresse 169.61.23.130 und wird auf dem Workerknoten mit der privaten IP-Adresse 10.73.13.25 ausgeführt. Anforderungen werden von den NLBs in verschiedenen Zonen in einem Umlaufzyklus bearbeitet.

  3. Die NLB kapselt das Clientanforderungspaket (im Bild als "CR" gekennzeichnet) in ein IPIP-Paket (gekennzeichnet als "IPIP") ein. Das Clientanforderungspaket behält die Client-IP als Quellen-IP-Adresse bei. Das einschließende IPIP-Paket verwendet die IP des Workers 10.73.14.25 als Quellen-IP-Adresse.

  4. Die NLB leitet das IPIP-Paket an einen Worker mit aktivem App-Pod und der privaten IP-Adresse 10.73.13.26 weiter. Hinweis: Jede NLB leitet Anforderungen an die App-Instanzen in ihrer eigenen Zone und an App-Instanzen in anderen Zonen weiter. Wenn mehrere App-Instanzen in einer Zone bereitgestellt sind, leitet die NLB die Anforderungen zwischen den App-Pods in der Zone weiter.

  5. Worker 10.73.14.26 entpackt das einschließende IPIP-Paket und dann das Clientanforderungspaket. Das Clientanforderungspaket wird an den App-Pod auf diesem Workerknoten weitergeleitet.

  6. Worker 10.73.14.26 verwendet dann die Quellen-IP-Adresse aus dem ursprünglichen Anforderungspaket, die Client-IP, um das Antwortpaket des App-Pods direkt an den Client zurückzugeben.