Load Balancer verwalten

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

Das Load-Balancing für GDC sorgt für eine effiziente Verteilung des Traffics auf die Backend-Arbeitslasten und verbessert so die Verfügbarkeit und Leistung der Anwendung.

Diese Seite richtet sich an Netzwerkadministratoren in der Gruppe „Platform Administrator“ oder an Entwickler in der Gruppe „Application Operator“, die für die Verwaltung des Netzwerkverkehrs für ihre Organisation verantwortlich sind. Weitere Informationen finden Sie in der Dokumentation zu Zielgruppen für GDC-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.
  • Verwenden Sie die gcloud CLI. 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 an, welcher Traffic weitergeleitet wird und an welchen Backend-Dienst. 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 Back-End-Dienst verweist auf ein Back-End-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.

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

    • 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 und 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.

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 als Ziel festlegen, 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 verfügbar machen.
  • Externer Load Balancer (ELB): Weist eine virtuelle IP-Adresse aus einem Bereich zu, der von externen Arbeitslasten aus weitergeleitet werden kann, und macht Dienste außerhalb der GDC-Organisation verfügbar, z. B. 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 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:

  • 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 gcloud 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 gcloud CLI. Verwenden Sie das Flag --zone, wenn Sie mit den gdcloud CLI-Befehlen angeben, für welche Zonen Load Balancer erstellt werden sollen.
  • Verwenden Sie den Kubernetes-Dienst direkt über den 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.

Beschränkungen

  • Die BackendService-Ressource darf nicht mit einer HealthCheck-Ressource für Pod-Arbeitslasten konfiguriert werden. Beachten Sie, dass das HealthCheckName in der BackendService-Spezifikation optional ist und weggelassen werden muss, 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 (ForwardingRuleExternal, ForwardingRuleInternal, BackendService oder HealthCheck) darf nicht denselben Namen wie diese benutzerdefinierten zonalen Load-Balancer-Ressourcen haben.

    Nächste Schritte

  • Interne Load Balancer konfigurieren

  • Externe Load Balancer konfigurieren