Von Edge zu Mesh: Service Mesh-Anwendungen über GKE Gateway verfügbar machen

Last reviewed 2023-10-24 UTC

In dieser Referenzarchitektur erfahren Sie, wie Sie Cloud Service Mesh mit Cloud Load Balancing kombinieren, um Anwendungen in einem Service Mesh mit Internetclients freizugeben.

Cloud Service Mesh ist ein auf Istio basierendes verwaltetes Service Mesh mit einer sicheren, beobachtbaren und standardisierten Kommunikationsebene für Anwendungen. Ein Service Mesh bietet eine ganzheitliche Kommunikationsplattform für Clients, die im Mesh-Netzwerk kommunizieren. Eine Herausforderung besteht jedoch weiterhin darin, Clients, die sich außerhalb des Mesh-Netzwerks befinden, mit Anwendungen zu verbinden, die innerhalb des Mesh-Netzwerks gehostet werden.

Sie können eine Anwendung je nach Standort des Clients für verschiedene Nutzer bereitstellen. Diese Referenzarchitektur richtet sich an fortgeschrittene Fachkräfte, die Cloud Service Mesh ausführen; sie ist aber auch für Istio in Google Kubernetes Engine (GKE) hilfreich.

Mesh-Ingress-Gateway

Istio 0.8 hat das Mesh-Ingress-Gateway eingeführt. Das Gateway bietet einen dedizierten Satz von Proxys, deren Ports für Traffic von außerhalb des Service Mesh freigegeben werden. Mit diesen Mesh-Ingress-Proxys können Sie das Bereitstellungsverhalten des Netzwerks getrennt vom Routing-Verhalten der Anwendung steuern.

Mit den Proxys können Sie außerdem Routing und Richtlinien auf externen Mesh-Traffic anwenden, bevor dieser am Anwendungs-Sidecar eingeht. Beim Mesh-Ingress wird die Handhabung des Traffics festgelegt, wenn er einen Knoten im Mesh-Netzwerk erreicht. Externe Komponenten müssen jedoch festlegen, wie der Traffic zuerst im Mesh-Netzwerk ankommt.

Zum Verwalten des externen Traffics benötigen Sie einen Load-Balancer außerhalb des Mesh-Netzwerks. In dieser Referenzarchitektur wird Google Cloud Load Balancing verwendet, das über GKE Gateway-Ressourcen bereitgestellt wird, um die Bereitstellung zu automatisieren.

Für Google Cloud ist das kanonische Beispiel dieser Einrichtung ein externer Load-Balancing-Dienst, der einen öffentlichen Network Load Balancer (L4) bereitstellt. Dieser Load-Balancer verweist auf die NodePorts eines GKE-Clusters. Sie stellen die Istio-Ingress-Gateway-Pods zur Verfügung, die den Traffic zu Downstream-Mesh-Sidecar-Proxys leiten.

Architektur

Das folgende Diagramm veranschaulicht diese Topologie. Das Load-Balancing für internen privaten Traffic ähnelt dieser Architektur, mit der Ausnahme, dass Sie stattdessen einen internen Passthrough-Network-Load-Balancer bereitstellen.

Ein externer Load-Balancer leitet externe Clients über Ingress-Gateway-Proxys an das Mesh weiter.

Das vorhergehende Diagramm zeigt, dass die Verwendung des transparenten L4-Load-Balancing mit einem Mesh-Ingress-Gateway folgende Vorteile bietet:

  • Die Einrichtung vereinfacht die Bereitstellung des Load-Balancers.
  • Dieser bietet eine stabile virtuelle IP-Adresse (VIP), Systemdiagnose und zuverlässige Trafficverteilung, wenn Clusteränderungen, Knotenausfälle oder Prozessausfälle auftreten.
  • Alle Routingregeln, die TLS-Beendigung und die Trafficrichtlinie werden an einem einzigen Standort am Mesh-Ingress-Gateway verwaltet.

GKE Gateway und Dienste

Sie können Zugriff auf Anwendungen für Clients außerhalb des Clusters auf verschiedene Arten bereitstellen. GKE Gateway ist eine Implementierung der Kubernetes Gateway API. GKE Gateway entwickelt die Ingress-Ressource und verbessert sie.

Wenn Sie GKE Gateway-Ressourcen in Ihrem GKE-Cluster bereitstellen, überwacht der Gateway-Controller die Gateway API-Ressourcen und vergleicht Cloud Load Balancing-Ressourcen, um das in den GKE Gateway-Ressourcen angegebene Netzwerkverhalten zu implementieren.

Wenn Sie GKE Gateway verwenden, hängt die Art des Load Balancers, den Sie zum Freigeben von Anwendungen für Clients verwenden, weitgehend von den folgenden Faktoren ab:

  • Der Status der Clients (extern oder intern).
  • Die erforderlichen Funktionen des Load Balancers, darunter die Einbindung in Sicherheitsrichtlinien von Google Cloud Armor.
  • Die Anforderungen an die Reichweite des Service Mesh. Service Meshes können mehrere GKE-Cluster umfassen oder in einem einzelnen Cluster enthalten sein.

In GKE Gateway wird dieses Verhalten durch Angabe der entsprechenden GatewayClass gesteuert.

Obwohl der Standard-Load Balancer für Cloud Service Mesh der Network Load Balancer ist, konzentriert sich diese Referenzarchitektur auf den externen Application Load Balancer (L7). Der externe Application Load Balancer ermöglicht die Integration mit Edge-Diensten wie Identity-Aware Proxy und Google Cloud Armor, URL-Weiterleitungen und Umschreibungen sowie einem global verteilten Netzwerk von Edge-Proxys. Im nächsten Abschnitt werden die Architektur und die Vorteile der Verwendung von zwei Ebenen des HTTP-Load-Balancing beschrieben.

Cloud-Ingress und Mesh-Ingress

Das Bereitstellen eines externen L7-Load-Balancing außerhalb des Mesh-Netzwerks mit einer Mesh-Ingress-Ebene bietet entscheidende Vorteile, insbesondere für Internet-Traffic. Obwohl Cloud Service Mesh und Istio-Ingress-Gateways eine erweiterte Routing- und Trafficverwaltung im Mesh ermöglichen, sind einige Funktionen am Netzwerkrand besser geeignet. Die Nutzung der Vorteile eines Internet-Edge-Netzwerks durch den externen Application Load Balancer von Google Cloud könnte erhebliche Vorteile in Bezug auf die Leistung, Zuverlässigkeit oder Sicherheit gegenüber dem mesh-netzwerk-basierten Ingress bieten. Zu diesen Vorteilen gehören:

Diese externe Ebene des L7-Load-Balancing wird als Cloud-Ingress bezeichnet, da sie auf von Cloud verwalteten Load-Balancern und nicht auf selbstverwalteten Proxys basiert, die von Mesh-Ingress verwendet werden. Die Kombination aus Cloud-Ingress und Mesh-Ingress nutzt ergänzende Funktionen der Google Cloud-Infrastruktur und des Mesh-Netzwerks. Das folgende Diagramm zeigt, wie Sie Cloud-Ingress (über GKE-Gateway) und Mesh-Ingress als zwei Load Balancing-Ebenen für den Internet-Traffic kombinieren können.

Cloud-Ingress fungiert als Gateway für externen Traffic zum Mesh über das VPC-Netzwerk.

In der Topologie des vorherigen Diagramms bezieht die Cloud-Ingress-Ebene Traffic von außerhalb des Service Mesh und leitet diesen Traffic an die Mesh-Ingress-Ebene weiter. Die Mesh-Ingress-Ebene leitet dann den Traffic an die mit dem Mesh-Netzwerk gehosteten Anwendungs-Back-Ends weiter.

Cloud- und Mesh-Ingress-Topologie

In diesem Abschnitt werden die zusätzlichen Rollen beschrieben, die jede Ingress-Ebene erfüllt, wenn Sie sie gemeinsam verwenden. Diese Rollen sind keine konkreten Regeln, sondern Richtlinien, die die Vorteile der einzelnen Ebenen nutzen. Je nach Anwendungsfall sind verschiedene Varianten dieses Musters wahrscheinlich.

  • Cloud-Ingress: In Kombination mit Mesh-Ingress wird die Cloud-Ingress-Ebene am besten für Edge-Sicherheit und globales Load-Balancing verwendet. Da die Cloud-Ingress-Ebene in den DDoS-Schutz integriert ist, sind Cloud-Firewalls, Authentifizierungs- und Verschlüsselungsprodukte am Netzwerkrand sehr gut geeignet, um diese Dienste außerhalb des Mesh-Netzwerks auszuführen. Die Routinglogik ist in der Regel in dieser Ebene sehr einfach. Die Logik kann jedoch für Multi-Cluster- und Multi-Region-Umgebungen komplexer sein. Aufgrund der entscheidenden Funktion von Load-Balancern im Internet wird die Cloud-Ingress-Ebene wahrscheinlich von einem Infrastrukturteam verwaltet, das die exklusive Kontrolle darüber hat, wie Anwendungen im Internet verfügbar gemacht und geschützt werden. Durch diese Steuerung wird diese Ebene außerdem weniger flexibel und dynamisch als eine entwicklergesteuerte Infrastruktur. Dies könnte sich darauf auswirken, wer und wie Sie Administratorzugriff auf diese Ebene gewähren.
  • Mesh-Ingress: In Kombination mit Cloud-Ingress bietet die Mesh-Ingress-Ebene flexibles Routing, das sich in der Nähe der Anwendung befindet. Aufgrund dieser Flexibilität ist das Mesh-Netzwerk besser als Cloud-Ingress für komplexe Routinglogik und Sichtbarkeit auf Anwendungsebene. Durch die Trennung zwischen Ingress-Ebenen wird es außerdem für die Anwendungsinhaber einfacher, diese Ebene direkt zu steuern, ohne Auswirkungen auf andere Teams. Wenn Sie Service Mesh-Anwendungen über einen L4-Load-Balancer statt über einen L7-Load-Balancer verfügbar machen, sollten Sie Client-TLS auf der Mesh-Ingress-Ebene im Mesh-Netzwerk beenden, um Anwendungen zu sichern.

Systemdiagnose

Die Verwendung von zwei Schichten des L7-Load-Balancings ist die Systemdiagnose. Sie müssen jeden Load-Balancer so konfigurieren, dass er den Status der nächsten Ebene prüft, um sicherzustellen, dass er Traffic empfangen kann. Die Topologie im folgenden Diagramm zeigt, wie Cloud-Ingress den Status der Mesh-Ingress-Proxys prüft, und das Mesh-Netzwerk prüft die Integrität der Anwendungs-Back-Ends.

Cloud-Ingress prüft die Integrität von Mesh-Ingress und Mesh-Ingress prüft die Integrität der Anwendungs-Back-Ends.

Bei der vorhergehenden Topologie gilt Folgendes:

  • Cloud-Ingress: In dieser Referenzarchitektur konfigurieren Sie den Google Cloud-Load Balancer über das Gateway, um den Status der Mesh-Ingress-Proxys auf den freigegebenen Systemdiagnose-Ports zu prüfen. Wenn ein Mesh-Proxy ausgefallen ist oder der Cluster, das Mesh-Netzwerk oder die Region nicht verfügbar ist, erkennt der Google Cloud-Load-Balancer diese Bedingung und sendet keinen Traffic an den Mesh-Proxy.
  • Mesh-Ingress: In der Mesh-Anwendung führen Sie Systemdiagnosen direkt auf den Back-Ends durch, damit Sie das Load-Balancing und die Trafficverwaltung lokal ausführen können.

Sicherheit

Die obige Topologie umfasst auch mehrere Sicherheitselemente. Einer der wichtigsten ist die Konfiguration beim Verschlüsseln und Bereitstellen von Zertifikaten. GKE Gateway kann in von Google verwaltete Zertifikate eingebunden werden. Verweisen Sie auf einen Certificate Manager CertificateMap in Ihrer Gateway-Definition. Internetclients authentifizieren sich mit den öffentlichen Zertifikaten und stellen eine Verbindung zum externen Load-Balancer als erster Hop in der Virtual Private Cloud (VPC) her.

Der nächste Hop, der sich zwischen dem Google Front End (GFE) und dem Mesh-Ingress-Proxy befindet, ist standardmäßig verschlüsselt. Die Verschlüsselung auf Netzwerkebene zwischen den GFEs und ihren Back-Ends wird automatisch angewendet. Wenn Ihre Sicherheitsanforderungen ergeben, dass der Plattforminhaber jedoch die Eigentumsrechte an den Verschlüsselungsschlüsseln besitzt, können Sie HTTP/2 mit TLS-Verschlüsselung zwischen dem Cluster-Gateway (dem GFE) und dem Mesh-Ingress (der Envoy-Proxy-Instanz) aktivieren. Wenn Sie HTTP/2 mit TLS-Verschlüsselung für diesen Pfad aktivieren, können Sie ein selbstsigniertes oder öffentliches Zertifikat verwenden, um den Traffic zu verschlüsseln, da das GFE sich nicht authentifiziert. Diese zusätzliche Verschlüsselungsebene wird im zugehörigen Bereitstellungsleitfaden veranschaulicht. Verwenden Sie das öffentliche Zertifikat nicht für andere öffentliche Load-Balancer, um einen unsachgemäßen Umgang mit Zertifikaten zu vermeiden. Stattdessen empfehlen wir die Verwendung separater Zertifikate im Service Mesh.

Wenn das Service Mesh TLS erfordert, wird der gesamte Traffic zwischen Sidecar-Proxys und dem Mesh-Ingress verschlüsselt. Das folgende Diagramm veranschaulicht die HTTPS-Verschlüsselung vom Client zum Google Cloud-Load Balancer, vom Load Balancer zum Mesh-Ingress-Proxy sowie vom Ingress-Proxy zum Sidecar-Proxy.

Die Sicherheit wird mit verwalteten Zertifikaten außerhalb des Mesh-Netzwerks und internen Zertifikaten innerhalb des Mesh-Netzwerks implementiert.

Kostenoptimierung

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

Bereitstellung

Informationen zum Bereitstellen dieser Architektur finden Sie unter Von Edge zu Mesh: Service Mesh-Anwendungen über GKE Gateway bereitstellen.

Nächste Schritte