Load Balancer verwalten

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

Das Load-Balancing für GDC sorgt für eine effiziente Trafficverteilung auf Backend-Arbeitslasten und verbessert so die Verfügbarkeit und Leistung von Anwendungen. Der Algorithmus, der zum Verteilen des Traffics verwendet wird, 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 Layer 4 (L4) aus. Das bedeutet, dass sie eine Reihe konfigurierter Frontend-TCP- oder -UDP-Ports 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.
  • Verwenden Sie die gdcloud CLI. Mit dieser API können Sie globale oder zonale Load Balancer erstellen.
  • Verwenden Sie den Kubernetes-Dienst direkt aus dem Kubernetes-Cluster. Mit dieser Methode werden nur zonale Load Balancer erstellt.

Komponenten des Lastenausgleichsmoduls

Wenn Sie die KRM API oder die gdcloud 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 an, welcher Traffic weitergeleitet wird und an welchen Backend-Dienst. Für Weiterleitungsregeln gelten die folgenden Spezifikationen:

    • Bestehen aus drei Tupeln: CIDR, Port und Protokoll für den Zugriff durch den Client.
    • Unterstützen TCP- und UDP-Protokolle.
    • Bieten interne und externe Weiterleitungsregeln. Clients können über die Virtual Private Cloud (VPC) auf interne Weiterleitungsregeln zugreifen. Clients können von außerhalb der GDC-Plattform oder von innerhalb auf externe Weiterleitungsregeln zugreifen, indem sie Arbeitslasten mit dem definierten Wert EgressNAT verwenden.
    • Weiterleitungsregeln stellen eine Verbindung zu einem Backend-Dienst her. Sie können mehrere Weiterleitungsregeln so einrichten, dass sie auf denselben Backend-Dienst verweisen.

  • Backend-Dienste: 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 hinsichtlich der Backends, auf die ein einzelner Backend-Dienst verweisen kann:

    • Eine zonale Backend-Ressource pro Zone.
    • Eine Cluster-Backend-Ressource pro Cluster. Diese 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. Backend-Ressourcen müssen auf eine Zone beschränkt sein. Wählen Sie Endpunkte mit Labels aus. Beschränken Sie die Auswahl 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-Backend ist ein Backend, 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 einzigen Backend-Dienst maximal ein Backend pro Zone und Cluster angeben.

  • Systemdiagnosen: geben die Tests an, mit denen ermittelt wird, ob ein bestimmter Arbeitslastendpunkt im Backend fehlerfrei ist. Der fehlerhafte Endpunkt wird aus dem Load Balancer entfernt, bis er wieder fehlerfrei ist. Systemdiagnosen sind nur für VM-Arbeitslasten anwendbar. Pod-Arbeitslasten können den integrierten Kubernetes-Testmechanismus verwenden, um zu ermitteln, ob ein bestimmter Endpunkt fehlerfrei ist. Weitere Informationen finden Sie unter Systemdiagnosen.

Wenn Sie den Kubernetes-Dienst direkt aus dem Kubernetes-Nutzercluster verwenden, verwenden Sie das Objekt Service anstelle der zuvor aufgeführten Komponenten. Sie können nur Arbeitslasten in dem Cluster als Ziel festlegen, in dem das Objekt Service erstellt wurde.

Externes und internes Load-Balancing

GDC-Anwendungen haben Zugriff auf die folgenden Netzwerkdiensttypen:

  • Interner Load Balancer (Internal Load Balancer, ILB): Mit dieser Option können Sie einen Dienst für andere Cluster innerhalb der Organisation bereitstellen.
  • Externer Load Balancer (External Load Balancer, ELB): weist eine virtuelle IP-Adresse (VIP) aus einem Bereich zu, der von externen Arbeitslasten aus erreichbar ist, 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. Jedes GDC-Universum kann aus mehreren GDC-Zonen bestehen, die in Regionen organisiert sind, die miteinander verbunden sind und eine Steuerungsebene gemeinsam nutzen. Ein Universum, das aus zwei Regionen mit jeweils drei Zonen besteht, 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 Bereich zonenspezifischer Load Balancer ist auf die Zonen beschränkt, die zum Zeitpunkt der Erstellung angegeben wurden. Jede Zone ist eine unabhängige Notfallwiederherstellungsdomain. Eine Zone verwaltet Infrastruktur, Dienste, APIs und Tools, 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:

  • Verwenden Sie die Networking Kubernetes Resource Model (KRM) API. Verwenden Sie die API-Version networking.global.gdc.goog, um globale Ressourcen zu erstellen.
  • Verwenden Sie die gdcloud CLI. Verwenden Sie das Flag --global, wenn Sie die gdcloud CLI-Befehle verwenden, um einen globalen Bereich anzugeben.

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.
  • Verwenden Sie die gdcloud CLI. Verwenden Sie das Flag --zone, wenn Sie die gdcloud CLI-Befehle verwenden, um anzugeben, für welche Zonen Load Balancer erstellt werden sollen.
  • Verwenden Sie den Kubernetes-Service direkt aus dem Kubernetes-Cluster.

Virtuelle IP-Adressen des Dienstes

ILBs weisen VIP-Adressen zu, die nur intern für die Organisation gelten. Diese VIP-Adressen sind von außerhalb der Organisation nicht erreichbar. Daher können Sie sie nur verwenden, um Dienste für andere Anwendungen innerhalb einer Organisation bereitzustellen. Diese IP-Adressen können sich zwischen Organisationen in derselben Instanz überschneiden.

ELBs weisen dagegen VIP-Adressen zu, die von außerhalb der Organisation 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 Backend-Ziele zu verteilen. Dieser Algorithmus ist auf hohe Leistung und Ausfallsicherheit ausgelegt und sorgt dafür, dass der Traffic gleichmäßig und vorhersehbar verteilt wird, während gleichzeitig die Datenlokalität in den Backends maximiert wird.

Funktionsweise von Maglev: der Hash-Mechanismus

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

  • Hash-Eingabe (5-Tupel): Der Algorithmus verwendet ein Standard-5-Tupel aus dem Header des Pakets, um einen Hash zu generieren. Dieses Tupel besteht aus:
    1. Quell-IP-Adresse
    2. Quellport
    3. Ziel-IP-Adresse
    4. Zielport
    5. Protokoll (z.B. TCP, UDP)
  • Weiterleitungsentscheidung: Das Ergebnis dieses Hash ordnet die Verbindung deterministisch einem der fehlerfreien Backends im Load-Balancing-Pool zu. Während der Lebensdauer dieser Verbindung werden alle Pakete an dasselbe Backend weitergeleitet.
  • Entropie für das Load-Balancing: 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 Backends verteilt werden.

Umgang mit Backend-Zustand und -Fehlern

Maglev ist so konzipiert, dass es ausfallsicher ist und Unterbrechungen minimiert, wenn sich die Anzahl der verfügbaren Backends ä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 Backends verteilt. Wichtig ist, dass Verbindungen zu anderen fehlerfreien Backends nicht beeinträchtigt oder umgeleitet werden.
  • Backend-Wiederherstellung: Wenn das fehlerhafte Backend wieder fehlerfrei ist und dem Pool wieder hinzugefügt wird, sorgt die Konsistenz des Hash dafür, dass dieses Backend mit minimalen Unterbrechungen dem Pool hinzugefügt wird. Der Load Balancer verteilt die Last neu und berücksichtigt dabei dieses neu fehlerfreie Backend. Dieser Ansatz mit minimalen Unterbrechungen verhindert eine massive Neuverteilung aller vorhandenen Verbindungen, die andernfalls Anwendungs-Caches oder -Zustände überlasten könnte.

Verhalten bei Bereitstellungen in mehreren Zonen

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

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

Beschränkungen

  • Die Ressource BackendService darf nicht mit einer HealthCheck-Ressource für Pod-Arbeitslasten konfiguriert werden. Der 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 sind gemischte Backends mit Pods und VMs in einer BackendService-Ressource nicht zulässig.

  • Eine benutzerdefinierte globale 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

Die folgenden Einschränkungen gelten für das Load-Balancing für Standardcluster:

Einzelner Clusterbereich

  • Einzelner Clusterbereich: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 sich ausschließlich in diesem einzelnen Standardcluster befinden. Eine einzelne Load Balancer-Definition, mit der versucht wird, Traffic auf 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 gdcloud 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.

  • Load Balancer mit Projektbereich ignorieren Standardcluster. Wenn eine Load Balancer-Konfiguration mit Projektbereich mit dem gdcloud 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 Load Balancer von Standardclustern nicht unterstützt.

  • Zonenübergreifende ILB-Verbindungen werden nicht unterstützt. Verbindungen von einem Standardcluster-Pod zu einem globalen ILB oder einem zonalen ILB in einer anderen Zone werden nicht unterstützt.

Nächste Schritte