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 beliebter Open-Source-Controller wie HAProxy Kubernetes Ingress oder NGINX Gateway Fabric in einem GDC-Standardcluster können Kunden L7-Traffic nahtlos an Hybridumgebungen weiterleiten. Diese Architektur verwendet die TLS-Terminierung (Ingress / HTTPRoute), 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 erweiterte Trafficverwaltung wie headerbasiertes Matching und Trafficgewichtung.
  • Zentralisierte TLS-Verwaltung:Bietet zentralisierte TLS-Verwaltung und -Terminierung.
  • Unterstützung für Hybridumgebungen:Leitet L7-Traffic nahtlos sowohl an integrierte containerisierte Pods als auch an Anwendungen weiter, die auf externen virtuellen Maschinen gehostet werden.
  • Flexible Controller-Optionen: Bietet die Wahl zwischen der modernen NGINX Gateway Fabric (mit Gateway API) oder dem etablierten HAProxy Ingress Controller.
  • Air-Gap-Bereitschaft:In Harbor Registry integriert, um Proxy- und Anwendungs-Images in privaten, nicht verbundenen Umgebungen zu speichern und bereitzustellen.
  • Komplexe Trafficaufteilung:Ermöglicht erweiterte Strategien zur Verteilung des Traffics 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 (z. B. GatewayClass, Gateway, und HTTPRoute oder Ingress).
  • Übergang zu modernen Standards:Die Architektur priorisiert die Gateway API für moderne Routingfunktionen und unterstützt gleichzeitig 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 vom verwalteten L4-Balancer von GDC nicht nativ bereitgestellt werden.
  • Abstraktion des Arbeitslaststandorts:Die Architektur behandelt containerisierte und VM-basierte Arbeitslasten konsistent durch Kubernetes-Dienstabstraktionen (Standard oder Headless).

Konzeptuelle Architektur

Konzeptionelles Architekturdiagramm für das 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 Back-Ends weiterzuleiten:

  1. Ingress-/Gateway-Einstiegspunkt:Ein Client initiiert HTTPS-Anfragen, die zuerst den L4-Load-Balancer von GDC erreichen. Dieser integrierte Load-Balancer dient als Einstiegspunkt und verteilt den 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-Routing-Regeln und der TLS-Terminierung durchführen.
  4. Backend-Dienste:
    • Containerisierte Pods:Als Standardbereitstellungen verwaltet und mit regulären Kubernetes-Diensten bereitgestellt.
    • Externe VMs:Mit einem Headless-Kubernetes-Dienst und einem benutzerdefinierten Endpunkt (oder EndpointSlice) mit der direkten IP der VM in den Cluster integriert.
  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 sicherzustellen.

Wichtige Konzepte und Technologien

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

  • Client:Eine Entität, die HTTPS-Anfragen initiiert, um mit den Anwendungen zu interagieren.
  • GDC-Standardcluster:GDC bietet eine integrierte Möglichkeit zum Erstellen von Kubernetes-Vanilla-Clustern. In dieser Lösung hostet der Cluster den L7-Load-Balancer und seine Controller sowie die Arbeitslasten und den Headless-Dienst für externe VMs.
  • GDC-L4-Load-Balancer:Der integrierte L4-Load-Balancer dient als Einstiegspunkt und verteilt den 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. Für NGINX überwachen sie Gateway API-Ressourcen (z. B. Gateway und HTTPRoute) und aktualisieren dynamisch die zugrunde liegenden Proxys. Für HAProxy überwachen sie die Ingress-Ressourcen und aktualisieren dynamisch die zugrunde liegenden Proxys.
    • 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-Routing-Regeln mit TLS-Terminierung definieren.
  • Containerisierte Arbeitslast (Pods) : Eine Standard-Kubernetes-Bereitstellung, die intern mit einem regulären Kubernetes-Service bereitgestellt wird.
  • VM-basierte Arbeitslast (extern) : Eine Arbeitslast, die auf einer externen VM im Projektnetzwerk gehostet wird und mit einem Headless-Kubernetes-Service und einem benutzerdefinierten Endpunkt mit der direkten IP der VM für den Proxy bereitgestellt 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 API im Vergleich zur Gateway API

Die Kubernetes-Netzwerklandschaft wandelt sich von der Legacy Ingress API zur modernen Gateway API. Die Unterschiede zwischen diesen beiden APIs zu kennen ist entscheidend für die Auswahl der richtigen Architektur für Ihre Arbeitslasten.

  • Ingress API:Ingress war bisher der Standard für die Verwaltung des externen Zugriffs auf HTTP-Dienste. Sie bietet hostbasiertes und pfadbasiertes Routing, aber ihr Design ist relativ einfach und es fehlt die integrierte Unterstützung für erweiterte Trafficverwaltung (z. B. headerbasiertes Matching oder Trafficgewichtung), ohne auf anbieterspezifische Anmerkungen zurückzugreifen. Wichtig ist, dass die Ingress API von der Kubernetes-Community jetzt als feature-frozen betrachtet wird (Ingress Einschränkungen und Entwicklung von Kubernetes Netzwerken).

  • Gateway API:Die Gateway API wird oft als V2 von Ingress bezeichnet und ist eine Sammlung von benutzerdefinierten Ressourcendefinitionen (Custom Resource Definitions, CRDs), die ein robusteres und erweiterbares Modell für Dienstnetzwerke bieten. Sie ist rollenorientiert konzipiert und trennt die Verantwortlichkeiten zwischen Infrastruktur anbietern (GatewayClass), Clusteroperatoren (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-Air-Gap-Lösung haben wir bewusst verschiedene 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 (z. B. HTTPRoute) profitieren, die in die API integriert sind.
  • HAProxy (Ingress API) : Obwohl die Gateway API die strategische Richtung ist, haben wir in dieser Anleitung die Ingress API für HAProxy ausgewählt. Das liegt daran, dass die Gateway API-Integration von HAProxy noch nicht als ausgereift gilt. Durch die Verwendung des etablierten HAProxy Ingress Controller sorgen wir für eine stabile und zuverlässige L7-Lösung für Kunden, die HAProxy bevorzugen, und bieten gleichzeitig einen Weg zu modernen L7-Funktionen.

Annahmen und Einschränkungen

Annahmen

  • Bereitschaft der Infrastruktur:Für die Bereitstellung wird die Verfügbarkeit von GDC-Air-Gap-Standardclustern der Version 1.15.x vorausgesetzt.
  • 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 L4-Load-Balancer von GDC erreicht, der den Traffic dann an die L7-Proxys weiterleitet.

Einschränkungen

  • Vom Kunden verwaltete Lösung:In GDC gibt es keinen verwalteten L7-Dienst mit SLA. Diese Implementierung wird vollständig vom Kunden selbst verwaltet.
  • Nur Standardcluster:Freigegebene Nutzercluster sind aufgrund der hohen Berechtigungen, die für die Bereitstellung von Ingress- und Gateway-Controllern erforderlich sind, nicht im Umfang enthalten.
  • Reife der API:Während NGINX die moderne Gateway API verwendet, ist HAProxy auf die Ingress API beschränkt, da die Gateway API-Integration noch nicht als ausgereift gilt.
  • Air-Gap-Wartung:Alle Container-Images müssen manuell in der lokalen Harbor Registry hochgestuft und verwaltet werden.
  • Community-Versionen:Die Architektur ist für Open-Source-Community-Versionen von NGINX und HAProxy konzipiert. Enterprise-Versionen funktionieren möglicherweise, wurden aber nicht explizit getestet.
  • Betriebliche Verantwortung:Kunden müssen ihre eigene Skalierung, Hochverfügbarkeit und Patching für die Drittanbieter-Controller 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 des Anbieters.
  • Veraltete API:Die Ingress API (die für HAProxy verwendet wird) wird von der Kubernetes-Community als „feature-frozen“ betrachtet, was die zukünftigen Routingfunktionen einschränken kann.

Lizenzierung

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

Zusätzliche Materialien