Load Balancer verwalten

Auf dieser Übersichtsseite wird beschrieben, wie Sie interne und externe Load-Balancer in Google Distributed Cloud (GDC) mit Air Gap für zonale und globale Netzwerkkonfigurationen konfigurieren können.

Load Balancing für GDC sorgt für eine effiziente Verteilung des Traffics auf Backend-Arbeitslasten und verbessert so die Verfügbarkeit und Leistung von Anwendungen. Der verwendete Algorithmus zur Verteilung des Traffics ist Maglev. Weitere Informationen finden Sie unter Load-Balancing-Algorithmus.

Diese Seite richtet sich an Netzwerkadministratoren in der Gruppe der Plattformadministratoren oder an Entwickler in der Gruppe der Anwendungsoperatoren, die für die Verwaltung des Netzwerkverkehrs für ihre Organisation verantwortlich sind. Weitere Informationen finden Sie unter Dokumentation zu Zielgruppen für GDC mit Air Gap.

Load-Balancing-Architektur

GDC bietet Load-Balancer, mit denen Anwendungen Dienste für andere Anwendungen bereitstellen können. Load Balancer weisen eine stabile virtuelle IP-Adresse (VIP) zu, die den Traffic auf eine Reihe von Backend-Arbeitslasten verteilt. Load-Balancer in GDC führen Load-Balancing auf Ebene 4 (L4) durch. Das bedeutet, dass sie eine Reihe von konfigurierten TCP- oder UDP-Frontend-Ports den entsprechenden Backend-Ports zuordnen. Load Balancer werden auf Projektebene konfiguriert.

Load-Balancer werden für die folgenden Arbeitslasttypen konfiguriert:

  • Arbeitslasten, die auf VMs ausgeführt werden.
  • Containerisierte Arbeitslasten im Kubernetes-Cluster.

Es gibt drei Möglichkeiten, Load Balancer in GDC zu konfigurieren:

  • Verwenden Sie die Networking Kubernetes Resource Model (KRM) API. Mit dieser API können Sie globale oder zonale Load Balancer erstellen.
  • gcloud CLI verwenden Mit dieser API können Sie globale oder zonale Load Balancer erstellen.
  • Verwenden Sie den Kubernetes-Dienst direkt über den Kubernetes-Cluster. Mit dieser Methode werden nur zonale Load-Balancer erstellt.

Komponenten des Lastenausgleichsmoduls

Wenn Sie die KRM API oder die gcloud CLI verwenden, um den Load-Balancer zu konfigurieren, verwenden Sie einen L4-Passthrough-Load-Balancer:

  • L4 bedeutet, dass das Protokoll entweder TCP oder UDP ist.
  • „Passthrough“ bedeutet, dass es keinen Proxy zwischen Arbeitslast und Client gibt.

Der Load-Balancer besteht aus den folgenden konfigurierbaren Komponenten:

  • Weiterleitungsregeln: Geben Sie an, welcher Traffic an welchen Backend-Dienst weitergeleitet wird. Für Weiterleitungsregeln gelten die folgenden Spezifikationen:

    • Besteht aus drei Tupeln: CIDR, Port und Protokoll für den Clientzugriff.
    • Unterstützt TCP- und UDP-Protokolle.
    • Bietet interne und externe Weiterleitungsregeln. Clients können innerhalb der Virtual Private Cloud (VPC) auf interne Weiterleitungsregeln zugreifen. Clients können von außerhalb der GDC-Plattform oder von Arbeitslasten mit dem definierten Wert EgressNAT auf externe Weiterleitungsregeln zugreifen.
    • Weiterleitungsregeln stellen eine Verbindung zu einem Backend-Dienst her. Sie können mehrere Weiterleitungsregeln auf denselben Back-End-Dienst verweisen lassen.

  • Backend-Dienste: Sie sind der Load-Balancing-Hub, der Weiterleitungsregeln, Systemdiagnosen und Backends miteinander verknüpft. Ein Backend-Dienst verweist auf ein Backend-Objekt, das die Arbeitslasten identifiziert, an die der Load Balancer den Traffic weiterleitet. Es gibt Einschränkungen, auf welche Back-Ends ein einzelner Back-End-Dienst verweisen kann:

    • Eine zonale Backend-Ressource pro Zone.
    • Eine Cluster-Backend-Ressource pro Cluster. Das kann nicht mit den Projekt-Backends kombiniert werden.

  • Backends: Ein zonales Objekt, das die Endpunkte angibt, die als Backends für die erstellten Backend-Dienste dienen. Back-End-Ressourcen müssen auf eine Zone beschränkt sein. Endpunkte mithilfe von Labels auswählen Beschränken Sie den Selektor auf ein Projekt oder einen Cluster:

    • Ein Projekt-Backend ist ein Backend, für das das Feld ClusterName nicht angegeben ist. In diesem Fall gelten die angegebenen Labels für alle Arbeitslasten im angegebenen Projekt, in der angegebenen VPC einer Zone. Die Labels werden auf VM- und Pod-Arbeitslasten in mehreren Clustern angewendet. Wenn ein Backend-Dienst ein Projekt-Backend verwendet, können Sie in diesem Backend-Dienst nicht auf ein anderes Backend für diese Zone verweisen.

    • Ein Cluster-Back-End ist ein Back-End, für das das Feld ClusterName angegeben ist. In diesem Fall gelten die angegebenen Labels für alle Arbeitslasten im benannten Cluster im angegebenen Projekt. Sie können in einem einzelnen Back-End-Dienst maximal ein Back-End pro Zone pro Cluster angeben.

  • Systemdiagnosen: Geben Sie die Prüfungen an, mit denen ermittelt wird, ob ein bestimmter Arbeitslastendpunkt im Back-End fehlerfrei ist. Der fehlerhafte Endpunkt wird aus dem Load-Balancer entfernt, bis er wieder fehlerfrei ist. Systemdiagnosen gelten nur für VM-Arbeitslasten. Pod-Arbeitslasten können den integrierten Kubernetes-Probe-Mechanismus verwenden, um festzustellen, ob ein bestimmter Endpunkt fehlerfrei ist. Weitere Informationen finden Sie unter Systemdiagnosen.

Wenn Sie den Kubernetes-Dienst direkt über den Kubernetes-Nutzercluster verwenden, nutzen Sie das Service-Objekt anstelle der zuvor aufgeführten Komponenten. Sie können nur Arbeitslasten in dem Cluster ausrichten, in dem das Service-Objekt erstellt wird.

Externes und internes Load-Balancing

GDC-Anwendungen haben Zugriff auf die folgenden Netzwerkdiensttypen:

  • Interner Load-Balancer (ILB): Damit können Sie einen Dienst für andere Cluster in der Organisation freigeben.
  • Externer Load Balancer (ELB): Weist eine virtuelle IP-Adresse (VIP) aus einem Bereich zu, der von externen Arbeitslasten aus weitergeleitet werden kann, und stellt Dienste außerhalb der GDC-Organisation bereit, z. B. für andere Organisationen innerhalb oder außerhalb der GDC-Instanz. Verwenden Sie die Sitzungsaffinität für ELBs, um sicherzustellen, dass Anfragen von einem Client immer an dasselbe Backend weitergeleitet werden.

Globale und zonale Load Balancer

Sie können globale oder zonale Load Balancer erstellen. Der Bereich globaler Load-Balancer erstreckt sich über ein GDC-Universum. Jede GDC-Umgebung kann aus mehreren GDC-Zonen bestehen, die in Regionen organisiert sind, die miteinander verbunden sind und eine Steuerungsebene gemeinsam nutzen. Ein Universum mit zwei Regionen mit jeweils drei Zonen könnte beispielsweise so aussehen: us-virginia1-a, us-virginia1-b, us-virginia1-c und eu-ams1-a, eu-ams1-b, eu-ams1-c.

Der Umfang von zonenbasierten Load-Balancern ist auf die Zonen beschränkt, die zum Zeitpunkt der Erstellung angegeben wurden. Jede Zone ist eine unabhängige Katastrophendomain. In einer Zone werden Infrastruktur, Dienste, APIs und Tools verwaltet, die eine lokale Steuerungsebene verwenden.

Weitere Informationen zu globalen und zonalen Ressourcen in einem GDC-Universum finden Sie unter Übersicht über mehrere Zonen.

Sie können globale Load Balancer mit den folgenden Methoden erstellen:

Sie können zonale Load Balancer mit den folgenden Methoden erstellen:

  • Verwenden Sie die Networking Kubernetes Resource Model (KRM) API. Verwenden Sie die API-Version networking.gdc.goog, um zonale Ressourcen zu erstellen.
  • gcloud CLI verwenden Verwenden Sie das Flag --zone, wenn Sie mit den gdcloud CLI-Befehlen angeben, für welche Zonen Load Balancer erstellt werden sollen.
  • Verwenden Sie Service direkt aus dem Kubernetes-Cluster.

Virtuelle IP-Adressen des Dienstes

Bei ILBs werden VIP-Adressen zugewiesen, die nur intern für die Organisation sind. Diese VIP-Adressen sind von außerhalb der Organisation nicht erreichbar. Sie können sie daher nur verwenden, um Dienste für andere Anwendungen innerhalb einer Organisation verfügbar zu machen. Diese IP-Adressen können sich zwischen Organisationen in derselben Instanz überschneiden.

ELBs weisen hingegen VIP-Adressen zu, die von außerhalb der Organisation extern erreichbar sind. Aus diesem Grund müssen ELB-VIP-Adressen für alle Organisationen eindeutig sein. In der Regel stehen der Organisation weniger ELB-VIP-Adressen zur Verfügung.

Load-Balancing-Algorithmus

Unser Load-Balancer verwendet Maglev, einen konsistenten Hash-Algorithmus, um eingehenden Traffic an Back-End-Ziele zu verteilen. Dieser Algorithmus ist auf hohe Leistung und Stabilität ausgelegt. Er sorgt dafür, dass der Traffic gleichmäßig und vorhersehbar verteilt wird, und maximiert gleichzeitig die Datenlokalität in den Back-Ends.

Funktionsweise von Maglev: Der Hashing-Mechanismus

Maglev trifft Weiterleitungsentscheidungen, indem die Eigenschaften jedes eingehenden Pakets gehasht werden. So wird sichergestellt, dass alle Pakete für eine bestimmte Verbindung konsistent an dasselbe Backend gesendet werden, um die Datenlokalität zu maximieren.

  • Hashing-Eingabe (5-Tupel): Der Algorithmus verwendet ein Standard-5-Tupel aus dem Paketheader, um einen Hash zu generieren. Dieses Tupel besteht aus:
    1. Quell-IP-Adresse
    2. Quellport
    3. IP-Adresse des Ziels
    4. Zielport
    5. Protokoll (z.B. TCP, UDP)
  • Weiterleitungsentscheidung: Das Ergebnis dieses Hashs ordnet die Verbindung deterministisch einem der fehlerfreien Back-Ends im Load-Balancing-Pool zu. Während der gesamten Lebensdauer dieser Verbindung werden alle Pakete an dasselbe Backend weitergeleitet.
  • Entropie für den Lastausgleich: Durch die Verwendung aller fünf Elemente des Tupels generiert Maglev genügend Entropie, um sicherzustellen, dass verschiedene Verbindungen gleichmäßig auf alle verfügbaren Back-Ends verteilt werden.

Back-End-Status und ‑Fehler behandeln

Maglev ist so konzipiert, dass es stabil ist und Unterbrechungen minimiert, wenn sich die Anzahl der verfügbaren Back-Ends ändert.

  • Backend-Fehler: Wenn ein Backend seine Systemdiagnosen nicht besteht, wird es aus der Liste der verfügbaren Ziele entfernt. Die Verbindungen, die zuvor an das fehlerhafte Backend weitergeleitet wurden, werden beendet. Neue Verbindungen werden automatisch anhand des Hash-Algorithmus auf die verbleibenden fehlerfreien Back-Ends verteilt. Wichtig: Verbindungen zu anderen fehlerfreien Back-Ends sind nicht betroffen und werden nicht umgeleitet.
  • Backend-Wiederherstellung: Wenn das fehlerhafte Backend wieder fehlerfrei wird und dem Pool wieder hinzugefügt wird, sorgt die konsistente Natur des Hash dafür, dass dieses Backend dem Pool mit minimalen Unterbrechungen hinzugefügt wird. Der Load-Balancer gleicht die Last dann unter Berücksichtigung dieses neu fehlerfreien Backends wieder aus. Dieser Ansatz mit „minimalen Unterbrechungen“ verhindert eine massive Umordnung aller bestehenden Verbindungen, die sonst Anwendungscaches oder den Status überlasten könnte.

Verhalten bei Bereitstellungen in mehreren Zonen

Es ist wichtig zu wissen, dass Maglev topologieunabhängig ist. Der Traffic wird nur auf Grundlage des mathematischen Ergebnisses des Hash verteilt, ohne den physischen Standort oder den Netzwerkpfad zu den Backends zu berücksichtigen.

  • Gleichmäßige Verteilung unabhängig vom Standort: Maglev behandelt alle Back-Ends im Pool als gleichwertige Ziele. Wenn Sie Back-Ends in verschiedenen Zonen haben, wird der Traffic gleichmäßig auf alle verteilt. Der Algorithmus bevorzugt keine Back-Ends in einer „lokalen“ Zone und berücksichtigt auch nicht die Netzwerklatenz zwischen Zonen.
  • MultiZone Interconnect-Kapazität sicherstellen:Da Back-Ends mehrere Zonen umfassen können, muss der Netzwerkadministrator dafür sorgen, dass die MultiZone Interconnect-Verbindung über genügend Netzwerkkapazität verfügt, um den zonenübergreifenden Traffic zwischen den Load-Balancer-Knoten und den Back-Ends zu verarbeiten.

Beschränkungen

  • Die BackendService-Ressource darf nicht mit einer HealthCheck-Ressource für Pod-Arbeitslasten konfiguriert werden. Die HealthCheckName in der BackendService-Spezifikation ist optional und muss weggelassen werden, wenn Sie einen Load-Balancer mit Pods konfigurieren.

  • Eine Load-Balancer-Konfiguration kann nicht auf gemischte Arbeitslasten mit Pods und VMs ausgerichtet sein. Daher ist die Verwendung von gemischten Back-Ends mit Pods und VMs in einer BackendService-Ressource nicht zulässig.

  • Eine globale benutzerdefinierte Load-Balancer-Ressource wie ForwardingRuleExternal, ForwardingRuleInternal, BackendService oder HealthCheck darf nicht denselben Namen wie diese benutzerdefinierten zonalen Load-Balancer-Ressourcen haben.

  • Eine Organisation kann maximal 500 Weiterleitungsregeln pro Zone definieren, in der sie sich befindet. Globale Weiterleitungsregeln werden für alle Zonen auf dieses Limit angerechnet.

Einschränkungen für Standardcluster

Für das Load Balancing für Standard-Cluster gelten die folgenden Einschränkungen:

Bereich für einzelne Cluster

  • Bereich für einen einzelnen Cluster:Jeder Load Balancer (ILB oder ELB), der für einen Standardcluster mit einer Service type=LoadBalancer-Ressource bereitgestellt wird, muss auf Backend-Endpunkte ausgerichtet sein, die ausschließlich in diesem einzelnen Standardcluster befindliche Pods sind. Eine einzelne Load-Balancer-Definition, mit der versucht wird, Traffic an Pods zu verteilen, die in mehreren verschiedenen Standardclustern oder in einer Mischung aus Standardclustern und freigegebenen Clustern ausgeführt werden, wird nicht unterstützt.

  • Die gcloud CLI und die Networking Kubernetes Resource Model API werden für Standardcluster nicht unterstützt. Verwenden Sie die Standard-Kubernetes-Ressource Service mit type=LoadBalancer und zugehörigen Annotationen, um das Load-Balancing für Standardcluster zu verwalten.

  • Bei Load Balancern mit Projektbereich werden Standardcluster ignoriert. Wenn eine Load Balancer-Konfiguration mit Projektbereich mit dem gcloud CLI-Befehl oder der Networking Kubernetes Resource Model API erstellt wird, werden alle Standardcluster im Projekt ignoriert.

  • Globales Load-Balancing wird nicht unterstützt. Die für Standardcluster bereitgestellten ILB- und ELB-Ressourcen sind zonale Ressourcen, die auf eine einzelne Zone beschränkt sind. Globales Load-Balancing wird für Standard-Cluster-Load-Balancer nicht unterstützt.

  • Zonenübergreifende ILB-Verbindungen werden nicht unterstützt. Die Verbindung von einem Standard-Cluster-Pod zu einem globalen ILB oder einem zonalen ILB in einer anderen Zone wird nicht unterstützt.

Nächste Schritte