Referenzarchitektur für Layer-7-Load-Balancing

Diese Referenzarchitektur bietet eine vom Kunden verwaltete Layer-7-Load-Balancing-Lösung in Google Distributed Cloud (GDC) mit Air Gap. Durch die Bereitstellung gängiger Open-Source-Controller wie HAProxy Kubernetes Ingress oder NGINX Gateway Fabric auf einem GDC-Standardcluster können Kunden L7-Traffic nahtlos an Hybridumgebungen weiterleiten. In dieser Architektur wird die TLS-Terminierung (Ingress/HTTPRoute) verwendet, um Traffic basierend auf der Server Name Indication (SNI) sowohl an integrierte containerisierte Pods als auch an Anwendungen weiterzuleiten, die auf externen virtuellen Maschinen gehostet werden.

Funktionen

  • Erweitertes Layer-7-Routing: Unterstützt hostbasiertes Routing, pfadbasiertes Routing und erweitertes Traffic-Management wie headerbasierten Abgleich und Trafficgewichtung.
  • Zentralisierte TLS-Verwaltung: Bietet zentralisierte TLS-Verwaltung und -Beendigung.
  • Unterstützung für Hybridumgebungen: L7-Traffic wird nahtlos sowohl an integrierte containerisierte Pods als auch an Anwendungen weitergeleitet, die auf externen virtuellen Maschinen gehostet werden.
  • Flexible Controller-Optionen: Sie können zwischen der modernen NGINX Gateway Fabric (mit Gateway API) und dem bewährten HAProxy Ingress Controller wählen.
  • Air-Gap-Bereitschaft: Integriert in Harbor Registry, um Proxy- und Anwendungs-Images in privaten, nicht verbundenen Umgebungen zu speichern und bereitzustellen.
  • Komplexe Traffic-Aufteilung: Ermöglicht erweiterte Strategien zur Traffic-Verteilung für die moderne Anwendungsbereitstellung.

Architekturprinzipien

  • Zweistufiges Load-Balancing-Muster: Diese Architektur kombiniert den integrierten L4-Load-Balancer von GDC (als Einstiegspunkt) mit einem vom Kunden verwalteten L7-Gateway, das in Kubernetes bereitgestellt wird.
  • Rollenorientierte Trennung: Das Design trennt die Verantwortlichkeiten zwischen Infrastrukturanbietern, Clusteroperatoren und Entwicklern durch bestimmte Ressourcen (wie GatewayClass, Gateway und HTTPRoute oder Ingress).
  • Übergang zu modernen Standards: Die Architektur priorisiert die Gateway API für moderne Routingfunktionen, unterstützt aber weiterhin die Legacy-Ingress API, wenn Stabilität für bestimmte Controller erforderlich ist.
  • Vom Kunden verwaltete Flexibilität: Durch die Bereitstellung selbstverwalteter Controller erhalten Kunden die Kontrolle über L7-Funktionen und -Konfigurationen, die nicht nativ vom verwalteten L4-Balancer von GDC bereitgestellt werden.
  • Abstraktion des Arbeitslaststandorts: Die Architektur behandelt containerisierte und VM-basierte Arbeitslasten konsistent über Kubernetes-Dienstabstraktionen (Standard oder Headless).

Konzeptionelle Architektur

Konzeptionelles Architekturdiagramm für Layer-7-Load-Balancing in GDC mit Air Gap.

Logische Architektur

Die logische Architektur besteht aus mehreren funktionalen Komponenten, die zusammenarbeiten, um externen Traffic an interne oder externe Backends weiterzuleiten:

  1. Ingress-/Gateway-Einstiegspunkt: Ein Client initiiert HTTPS-Anfragen, die zuerst den GDC-L4-Load-Balancer erreichen. Dieser integrierte Load Balancer dient als Einstiegspunkt und verteilt TCP/443-Traffic an den L7-Load-Balancer.
  2. Steuerungsebene: Ingress- oder Gateway-Controller (HAProxy- oder NGINX-Operatoren) überwachen Kubernetes-Ressourcen wie Ingress, Gateway und HTTPRoute.
  3. Datenebene: Basierend auf den beobachteten Ressourcen aktualisieren die Controller dynamisch die zugrunde liegenden Proxys, die das eigentliche Traffic-Routing basierend auf SNI-basierten Host-Routingregeln und TLS-Terminierung ausführen.
  4. Backend-Dienste:
    • Containerisierte Pods: Werden als Standard-Deployments verwaltet und mit regulären Kubernetes-Diensten bereitgestellt.
    • Externe VMs: Werden mit einem monitorlosen Kubernetes-Dienst und einem benutzerdefinierten Endpunkt (oder EndpointSlice) mit der direkten IP-Adresse der VM in den Cluster eingebunden.
  5. Artefaktverwaltung: Alle Images für die Proxys und Anwendungen werden von einer lokalen Harbor Registry bereitgestellt, um die Funktionalität in einer Air-Gap-Umgebung zu gewährleisten.

Wichtige Konzepte und Technologien

Die Architektur verwendet ein zweistufiges Load-Balancing-Muster, bei dem der integrierte L4-Load-Balancer von GDC mit einem vom Kunden verwalteten L7-Gateway kombiniert wird, das in Kubernetes bereitgestellt wird. Zu den wichtigsten Komponenten gehören:

  • Client: Eine Entität, die HTTPS-Anfragen zur Interaktion mit den Anwendungen initiiert.
  • GDC-Standardcluster: GDC bietet eine integrierte Möglichkeit, Kubernetes-Vanilla-Cluster zu erstellen. In dieser Lösung hostet der Cluster den L7-Load-Balancer und seine Controller sowie die Arbeitslasten und den monitorlosen Dienst für externe VMs.
  • GDC-L4-Load-Balancer: Der integrierte L4-Load-Balancer dient als Einstiegspunkt und verteilt TCP/443-Traffic direkt an die Kubernetes-Pods, auf denen die Ingress- oder Gateway-Controller ausgeführt werden.
  • Ingress- und Gateway-Controller: HAProxy- oder NGINX-Operatoren, die im Standardcluster ausgeführt werden. Bei Nginx werden Gateway API-Ressourcen (wie Gateway und HTTPRoute) überwacht und die zugrunde liegenden Proxys dynamisch aktualisiert. Bei HAProxy überwachen sie die Ingress-Ressourcen und aktualisieren die zugrunde liegenden Proxys dynamisch.
    • HAProxy Ingress Controller: Ein Ingress-Controller für Kubernetes, der HAProxy als Reverse-Proxy und Layer-7-Load-Balancer verwendet und auch die TLS-Terminierung übernimmt.
    • Nginx Gateway Fabric: Eine Implementierung der Gateway API mit NGINX als Datenebene.
  • Ingress und Gateway (mit HTTPRoute): Standardisierte Kubernetes-Ressourcen, die den physischen Listening-Port (443) und die SNI-basierten Host-Routingregeln mit TLS-Terminierung definieren.
  • Containerisierte Arbeitslast (Pods): Ein Standard-Kubernetes-Deployment, das intern über einen regulären Kubernetes-Service bereitgestellt wird.
  • VM-basierte Arbeitslast (extern): Eine Arbeitslast, die auf einer externen VM im Projektnetzwerk gehostet wird und über einen monitorlosen Kubernetes-Service und einen benutzerdefinierten Endpunkt mit der direkten IP-Adresse der VM für den Proxy freigegeben wird.
  • Harbor Registry: Eine private Container-Registry, die zum Speichern und Bereitstellen der Proxy- und Anwendungs-Images in der Air-Gap-Umgebung verwendet wird.

Ingress- und Gateway-APIs im Vergleich

Die Kubernetes-Netzwerklandschaft wird von der alten Ingress API auf die moderne Gateway API umgestellt. Die Unterschiede zwischen diesen beiden Optionen zu kennen, ist entscheidend, um die richtige Architektur für Ihre Arbeitslasten auszuwählen.

  • Ingress API: Ingress war bisher der Standard für die Verwaltung des externen Zugriffs auf HTTP-Dienste. Er bietet host- und pfadbasiertes Routing, ist aber relativ einfach aufgebaut und bietet keine integrierte Unterstützung für erweitertes Traffic-Management (z. B. headerbasiertes Abgleichen oder Traffic-Gewichtung), ohne auf anbieterspezifische Annotationen angewiesen zu sein. Wichtig ist, dass die Ingress API von der Kubernetes-Community jetzt als Feature-frozen betrachtet wird (Ingress-Einschränkungen und Entwicklung des Kubernetes-Netzwerks).

  • Gateway API: Die Gateway API wird oft als V2 von Ingress bezeichnet und ist eine Sammlung von benutzerdefinierten Ressourcendefinitionen (CRDs), die ein robusteres und erweiterbares Modell für Dienstnetzwerke bieten. Sie ist rollenorientiert und trennt die Verantwortlichkeiten zwischen Infrastrukturanbietern (GatewayClass), Clusterbetreibern (Gateway) und Entwicklern (HTTPRoute/TLSRoute) (Gateway API in GKE). Diese Trennung ermöglicht eine detailliertere Steuerung und eine bessere Unterstützung für mehrere Mandanten.

In dieser GDC mit Air Gap-Lösung haben wir bewusst unterschiedliche APIs für die beiden vorgestellten Controller ausgewählt:

  • NGINX (Gateway API): Für die NGINX-Implementierung verwenden wir NGINX Gateway Fabric, eine ausgereifte und integrierte Implementierung der Gateway API. Durch die Verwendung der Gateway API für NGINX können Kunden von den modernen Standards und erweiterten Routingfunktionen (wie HTTPRoute) profitieren, die in die API integriert sind.
  • HAProxy (Ingress API): Obwohl die Gateway API die strategische Richtung ist, haben wir in diesem Leitfaden die Ingress API für HAProxy ausgewählt. Das liegt daran, dass die Gateway API-Integration von HAProxy nicht als ausgereift gilt. Durch die Verwendung des bewährten HAProxy Ingress Controller stellen wir eine stabile und zuverlässige L7-Lösung für Kunden bereit, die HAProxy bevorzugen, und bieten gleichzeitig einen Weg zu modernen L7-Funktionen.

Annahmen und Einschränkungen

Annahmen

  • Infrastrukturbereitschaft: Für die Bereitstellung wird davon ausgegangen, dass GDC mit Air Gap 1.15.x-Standardcluster verfügbar sind.
  • Lokale Registry: Es wird davon ausgegangen, dass eine lokale Harbor-Registry korrekt konfiguriert ist, um Proxy- und Anwendungs-Images in der Air-Gap-Umgebung zu speichern und bereitzustellen.
  • Nativer Einstiegspunkt: Es wird davon ausgegangen, dass der Traffic zuerst den integrierten GDC-L4-Load-Balancer erreicht, der den Traffic dann an die L7-Proxys verteilt.

Einschränkungen

  • Vom Kunden verwaltete Lösung: In der GDC gibt es keinen verwalteten, SLA-gestützten L7-Dienst. Diese Implementierung wird vollständig vom Kunden selbst verwaltet.
  • Nur Standardcluster: Geteilte Nutzercluster sind aufgrund der hohen Berechtigungen, die für die Bereitstellung von Ingress- und Gateway-Controllern erforderlich sind, nicht im Umfang enthalten.
  • API-Reife: NGINX verwendet die moderne Gateway API, während HAProxy auf die Ingress API beschränkt ist, da die Gateway API-Integration noch nicht als ausgereift gilt.
  • Wartung mit Air Gap: Alle Container-Images müssen manuell in der lokalen Harbor-Registry hochgestuft und verwaltet werden.
  • Community-Editionen: Die Architektur ist für Open-Source-Community-Editionen von Nginx und HAProxy konzipiert. Enterprise-Versionen funktionieren möglicherweise, wurden aber nicht explizit getestet.
  • Betriebliche Verantwortung: Kunden müssen die Skalierung, Hochverfügbarkeit und das Patchen der Drittanbieter-Controller selbst verwalten.
  • Supportgrenze: Der Google-Support deckt nur die zugrunde liegende GDC-Infrastruktur ab. Probleme mit der HAProxy- oder NGINX-Software selbst liegen in der Verantwortung des Kunden oder Anbieters.
  • Veraltete API: Die Ingress API (für HAProxy verwendet) wird von der Kubernetes-Community nicht mehr weiterentwickelt, was zukünftige Routing-Funktionen einschränken kann.

Lizenzierung

  • Community-Editionen: Die Architektur ist für Open-Source-Community-Editionen (normalerweise Apache 2.0 oder ähnlich) konzipiert, die kostenlos verwendet werden können, aber vom Kunden verwaltet werden.
  • Beschaffung für Unternehmen: Die Beschaffung und Verwaltung kommerzieller Lizenzen wie NGINX Plus oder HAProxy Enterprise liegt in der alleinigen Verantwortung des Kunden.

Zusätzliche Materialien