Gateway

Auf dieser Seite wird die GKE-Implementierung (Google Kubernetes Engine) der Kubernetes Gateway API mit dem GKE-Gateway-Controller beschrieben. Informationen zum Bereitstellen von Gateways in GKE finden Sie unter Gateways bereitstellen oder Multi-Cluster-Gateways bereitstellen.

Die Gateway API ist ein Open Source-Standard für Dienstnetzwerke. Die Gateway API entwickelt die Ingress-Ressource weiter und verbessert sich so:

  • Rollenorientiert: Das Gateway besteht aus API-Ressourcen, die den Organisationsrollen des Clusteroperators, Entwicklers und Infrastrukturanbieters entsprechen. Auf diese Weise können Clusteroperatoren definieren, wie eine gemeinsame Infrastruktur von vielen verschiedenen und nicht koordinierenden Entwicklerteams verwendet werden kann.

  • Portabel: Die Gateway API ist ein Open-Source-Standard mit vielen Implementierungen. Sie wurde nach dem Konzept der flexiblen Konformität entwickelt, die eine äußerst portable Core API (wie Ingress) unterstützt, aber gleichzeitig flexibel und erweiterbar genug ist, um native Funktionen für die Umgebung und Implementierung zu unterstützen. Dadurch können die Konzepte und Kernressourcen in allen Implementierungen und Umgebungen vereinheitlicht werden, wodurch die Komplexität verringert und die Wiedererkennung durch Nutzer erhöht werden.

  • Ausdrücklich: Die Gateway API-Ressourcen bieten integrierte Funktionen für den headerbasierten Abgleich, Trafficgewichtung und andere Funktionen, die nur in Ingress über benutzerdefinierte Annotationen möglich sind.

Gateway API-Ressourcen

Die Gateway API ist ein rollenbasiertes Ressourcenmodell, das für die Personen entwickelt wurde, die mit dem Kubernetes-Netzwerk interagieren. Wie im folgenden Diagramm dargestellt, ermöglicht dieses Modell den verschiedenen nicht koordinierenden Dienstinhabern, dieselbe zugrunde liegende Netzwerkinfrastruktur sicher so zu teilen, dass die Richtlinien und Kontrolle für den Plattformadministrator zentralisiert werden.

GKE bietet Gateway-Klassen. Clusteroperatoren erstellen Gateway-Ressourcen basierend auf diesen Klassen. Anwendungsentwickler erstellen HTTPRoute-Ressourcen, die an Gateway-Ressourcen gebunden werden.

Die Gateway API enthält die folgenden Ressourcentypen:

  • GatewayClass: Definiert eine clusterbezogene Ressource, die eine Vorlage zum Erstellen von Load-Balancern in einem Cluster ist. GKE bietet GatewayClasses, die in GKE-Clustern verwendet werden können.
  • Gateway: Definiert, wo und wie die Load-Balancer den Traffic überwachen. Clusteroperatoren erstellen Gateways in ihren Clustern anhand einer GatewayClass. GKE erstellt Load-Balancer, die die in der Gateway-Ressource definierte Konfiguration implementieren.
  • HTTPRoute: Definiert protokollspezifische Regeln für die Weiterleitung von Anfragen von einem Gateway an Kubernetes-Dienste. GKE unterstützt HTTPRoutes für HTTP(S)-basiertes Traffic-Routing. Anwendungsentwickler erstellen HTTPRoutes, um ihre HTTP-Anwendungen mithilfe von Gateways verfügbar zu machen.

GatewayClass

Eine GatewayClass ist eine Ressource, die eine Vorlage für TCP/UDP-Load-Balancer (Ebene 4) und HTTP(S)-Load-Balancer (Ebene 7) in einem Kubernetes-Cluster definiert. GKE stellt GatewayClasses als clusterbezogene Ressourcen bereit. Clusteroperatoren geben beim Erstellen von Gateways in ihren Clustern eine GatewayClass an.

Die verschiedenen GatewayClasses entsprechen verschiedenen Google Cloud-Load-Balancern. Wenn Sie ein Gateway auf Basis einer GatewayClass erstellen, wird ein entsprechender Load-Balancer erstellt, um die angegebene Konfiguration zu implementieren. Einige GatewayClasses unterstützen Multi-Cluster-Load-Balancing.

In der folgenden Tabelle sind die in GKE-Clustern verfügbaren GatewayClasses und der zugrunde liegende Load-Balancer-Typ aufgeführt. Ausführliche Informationen zu den GatewayClasses finden Sie in den GatewayClass-Funktionen und -Spezifikationen.

Klassenname Beschreibung
gke-l7-rilb Regionale interne HTTP(S)-Load-Balancer, die auf dem internen HTTP(S)-Load-Balancing basieren
gke-l7-gxlb Globale externe HTTP(S)-Load-Balancer, die auf dem globalen externen HTTP(S)-Load-Balancer (klassisch) basieren
gke-l7-rilb-mc Regionale Multi-Cluster-Load-Balancer, die auf dem internen HTTP(S)-Load-Balancing basieren
gke-l7-gxlb-mc Globale Multi-Cluster Load-Balancer, die auf dem globalem externen HTTP(S)-Load-Balancer (klassisch) basieren

Jede GatewayClass unterliegt den Einschränkungen des zugrunde liegenden Load-Balancers.

Gateway

Clusteroperatoren erstellen Gateways, um zu definieren, wo und wie die Load-Balancer den Traffic überwachen. Gateways übernehmen ihr Verhalten bei der Implementierung von der zugehörigen GatewayClass.

Die Gateway-Spezifikation enthält die GatewayClass für das Gateway, auf dem Ports und Protokolle überwacht werden sollen, und Angaben zu den Routen, die an das Gateway gebunden werden können. Ein Gateway wählt Routen anhand der Routenmetadaten wie Art, Namespace und Labels von Routenressourcen aus.

Ein Beispiel für die Bereitstellung eines Gateways finden Sie unter Gateways bereitstellen. Ein Beispiel für die Bereitstellung eines Multi-Cluster-Gateways finden Sie unter Multi-Cluster-Gateways bereitstellen.

HTTPRoute

Eine HTTPRoute definiert, wie HTTP- und HTTPS-Anfragen, die von einem Gateway empfangen werden, an Dienste weitergeleitet werden. Anwendungsentwickler erstellen HTTPRoutes, um ihre Anwendungen über Gateways freizugeben.

Eine HTTPRoute definiert, an welche Gateways der Traffic weitergeleitet werden soll, an welche Dienste weitergeleitet werden soll und welche Regeln definieren, welchem Traffic die HTTPRoute entspricht. Die Gateway- und Routenbindung ist bidirektional, das heißt, beide Ressourcen müssen sich gegenseitig zur Bindung auswählen. HTTPRoutes können Anfragen anhand von Details im Anfrageheader abgleichen.

Vergleich von Ingress und Gateway

Gateway und Ingress sind Open-Source-Standards für das Routing von Traffic. Das Gateway wurde von der Kubernetes-Community entwickelt und basiert auf Erkenntnissen aus der Ingress- und Service Mesh-Umgebung. Gateway ist eine Weiterentwicklung von Ingress, das dieselbe Funktion als Obermenge der Ingress-Funktionen bereitstellt. Beide können gleichzeitig verwendet werden, ohne dass es zu Konflikten kommt. Im Laufe der Zeit werden Gateway- und Route-Ressourcen jedoch mehr Funktionen bereitstellen, die in Ingress nicht verfügbar sind, sodass Nutzer gezwungen sind, Gateway zu verwenden, wo sie zuvor vielleicht Ingress verwendet haben.

In GKE können alle Ingress-Ressourcen direkt in Gateway- und HTTPRoute-Ressourcen umgewandelt werden. Ein einzelner Ingress entspricht sowohl einem Gateway (für die Front-End-Konfiguration) als auch einer HTTPRoute (für die Routingkonfiguration). Das folgende Beispiel zeigt, wie die entsprechende Gateway- und HTTPRoute-Konfiguration aussieht. Beachten Sie, dass die Gateway- und HTTPRoute-Ressourcen separat erstellt werden können, auch von verschiedenen Nutzern. Gateways können viele Routen haben und eine Route kann mit mehr als einem Gateway verbunden werden. Die Beziehungen zwischen Gateways und Routen werden unter Gateway-Nutzungsmuster erläutert.

Eingehender Traffic

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: "gce-internal"
spec:
  rules:
  - host: "example.com"
    http:
      paths:
      - pathType: Prefix
        path: /
        backend:
          service:
            name: site
            port:
              number: 80
      - pathType: Prefix
        path: /shop
        backend:
          service:
            name: store
            port:
              number: 80

Route

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        value: /shop
    backendRefs:
    - name: site
      port: 80

Gateway

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: gke-l7-rilb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute

Gateway-Inhaberschaft und Nutzungsmuster

Gateway- und Route-Ressourcen bieten Flexibilität bei der Inhaberschaft und Bereitstellung in einer Organisation. Dies bedeutet, dass ein einzelner Load-Balancer von einem Infrastrukturteam bereitgestellt und verwaltet werden kann, das Routing unter einer bestimmten Domain oder einem bestimmten Pfad aber auch an ein anderes Team in einem anderen Kubernetes-Namespace delegiert werden kann. Der GKE-Gateway-Controller unterstützt die mehrmandantenfähige Nutzung eines Load-Balancers, der über Namespaces, Cluster und Regionen hinweg gemeinsam genutzt wird. Gateways müssen nicht freigegeben werden, wenn eine verteilte Inhaberschaft erforderlich ist. Im Folgenden sind einige der gängigsten Nutzungsmuster für Gateways in GKE aufgeführt.

Selbstverwaltetes Gateway

Ein einzelner Inhaber kann ein Gateway und eine Route ausschließlich für seine Anwendungen bereitstellen und exklusiv verwenden. Gateways und Routen, die auf diese Weise bereitgestellt werden, ähneln Ingress. Das folgende Diagramm zeigt zwei verschiedene Dienstinhaber, die ihre eigenen Gateways bereitstellen und verwalten. Ähnlich wie Ingress entspricht jedes Gateway seiner eigenen eindeutigen IP-Adresse und seinem eigenen Load-Balancer. TLS, Routing und andere Richtlinien werden vollständig vom Dienstinhaber gesteuert.

Ein einzelner Inhaber kann die vollständige Kontrolle über das Gateway und die Route haben.

Dieses Nutzungsmuster ist für Ingress üblich, ist jedoch aufgrund fehlender gemeinsamer Ressourcen schwierig für viele Teams zu skalieren. Das Gateway API-Ressourcenmodell ermöglicht die folgenden Nutzungsmuster, die ein breites Spektrum an Optionen für verteilte Steuerung und Inhaberschaft bieten.

Von der Plattform verwaltetes Gateway pro Namespace

Durch die Trennung zwischen Gateway- und Route-Ressourcen können Plattformadministratoren Gateways im Namen von Dienstinhabern steuern. Plattformadministratoren können ein Gateway pro Namespace oder Team bereitstellen und diesem Namespace exklusiven Zugriff auf das Gateway gewähren. Dadurch erhält der Dienstinhaber die vollständige Kontrolle über die Routingregeln, ohne dass Konflikte durch andere Teams entstehen. Dadurch kann der Plattformadministrator Aspekte wie IP-Zuordnung, Portfreigabe, Protokolle, Domains und TLS steuern. Plattformadministratoren können auch entscheiden, welche Arten von Gateways für Teams verfügbar sind, z. B. interne oder externe/öffentliche Gateways. Dieses Nutzungsmuster sorgt für eine saubere Trennung der Verantwortlichkeiten zwischen verschiedenen Rollen.

Namespace-übergreifendes Routing bietet die Möglichkeit, Routen über Namespace-Grenzen hinweg an Gateways anzuhängen. Gateways können einschränken, von welchen Namespaces aus Routen angehängt werden können. Routen geben die Gateways an, an die sie angehängt sind, können jedoch nur an ein Gateway angehängt werden, das den Namespace der Route zulässt. Dieses bidirektionale Anhängen bietet jeder Seite flexible Steuermöglichkeiten, die diese Vielfalt von Nutzungsmustern ermöglichen.

Im folgenden Diagramm hat der Plattformadministrator ein Gateway für exklusiven Zugriff für jeden Namespace bereitgestellt. Das Gateway store ist beispielsweise so konfiguriert, dass nur Routen aus dem Namespace store daran angehängt werden können. Jedes Gateway stellt eine eindeutige IP-Adresse mit Load-Balancing dar. So kann jedes Team eine beliebige Anzahl von Routen für das Gateway für alle gewünschten Domains oder Routen bereitstellen.

Ein Gateway pro Namespace bietet dem Namespace exklusiven Zugriff auf das Gateway.

Gemeinsam genutztes Gateway pro Cluster

Die gemeinsame Nutzung von Gateways über Namespaces hinweg bietet eine noch zentralisierte Form der Inhaberschaft für Plattformadministratoren. Dadurch können verschiedene Dienstinhaber, die in verschiedenen Namespaces ausgeführt werden, dieselbe IP-Adresse oder DNS-Domain, dieselben Zertifikate oder Pfade verwenden, um ein differenziertes Routing zwischen Diensten zu ermöglichen. Mit Gateways können Plattformadministratoren steuern, über welche Namespaces eine bestimmte Domain weitergeleitet werden kann. Dies ist mit dem vorherigen Beispiel vergleichbar, außer dass Gateways das Anhängen von Routen aus mehr als einem Namespace zulassen.

Im folgenden Diagramm hat der Plattformadministrator zwei Gateways im Namespace infra bereitgestellt. Das Gateway external ermöglicht das Anhängen von Routen aus den Namespaces web und mobile an das Gateway. Routen aus dem Namespace accounts können das Gateway external nicht verwenden, da der Namespace accounts nur für interne Dienste vorgesehen ist. Mit dem Gateway internal können interne Clients innerhalb der VPC privat über private IP-Adressen kommunizieren.

Ein Gateway pro Cluster ermöglicht verschiedenen Namespaces in einem Cluster die gemeinsame Nutzung eines einzelnen Gateways.

Die Domain m.example.com wird an den Namespace mobile delegiert, mit dem mobile Dienstinhaber alle Routingregeln konfigurieren können, die sie unter der Domain m.example.com benötigen. Dadurch erhalten die Dienstinhaber mehr Kontrolle über die Einführung neuer API-Endpunkte und die Steuerung des Traffics, ohne dass eine Änderung durch Administratoren erforderlich ist.

Gemeinsam genutztes Gateway pro Flotte

Bei der Verwendung von Multi-Cluster-Gateways kann ein Gateway sowohl über Namespaces als auch über Cluster und Regionen hinweg gemeinsam genutzt werden. Große Organisationen mit geografisch verteilten Anwendungen können von Multi-Cluster-Gateways profitieren, da sie den globalen Traffic genau steuern und gleichzeitig die Routinginhaberschaft delegieren können. Ähnlich wie in den vorherigen Beispielen verwaltet ein Plattformadministrator das Gateway und delegiert das Routing. Der Hauptvorteil dieses Anwendungsfalls ist, dass Routen auf Multi-Cluster-Services verweisen, die clusterübergreifend bereitgestellt werden. Traffic kann explizit weitergeleitet werden (Traffic an store.example.com/us geht an gke-us-Pods) oder implizit (Traffic an example.com/* wird zu dem Cluster weitergeleitet, der dem Client am nächsten liegt. Dank dieser Flexibilität können Dienstinhaber die optimale Routingstrategie für ihre Anwendung definieren.

Ein Gateway pro Flotte bietet multiregionales Multi-Cluster-Load-Balancing.

GKE Gateway Controller

GKE Gateway Controller ist die Google-Implementierung der Gateway API für Cloud Load Balancing. Ähnlich wie GKE Ingress Controller überwacht der Gateway-Controller eine Kubernetes API auf Gateway API-Ressourcen und vergleicht Cloud Load Balancing-Ressourcen, um das von den Gateway-Ressourcen angegebene Netzwerkverhalten zu implementieren.

Es gibt zwei Versionen von GKE Gateway Controller:

  • Single-Cluster: verwaltet Single-Cluster-Gateways für einen einzelnen GKE-Cluster.
  • Multi-Cluster: verwaltet Multi-Cluster-Gateways für einen oder mehrere GKE-Cluster.

Beide Gateway-Controller werden von Google gehostet und beobachten die Kubernetes API für GKE-Cluster. Im Gegensatz zu GKE Ingress Controller werden die Gateway-Controller nicht auf GKE-Steuerungsebenen oder im Nutzerprojekt gehostet. Dadurch sind sie skalierbarer und robuster.

Die Gateway-Controller selbst sind keine Netzwerkdatenebene und verarbeiten keinen Traffic. Sie sitzen "out of band" vom Traffic und verwalten verschiedene Datenebenen, die Traffic verarbeiten. Das folgende Diagramm zeigt die Architektur eines Single-Cluster-Gateway-Controllers und eines Multi-Cluster-Gateway-Controllers für GKE. Welcher zugrunde liegende Controller verwendet wird, hängt von der GatewayClass des bereitgestellten Gateways ab.

Die Multi-Cluster- und Single-Cluster-Gateway-Controller stellen Load-Balancer für GKE bereit und verwalten sie, verarbeiten Netzwerktraffic jedoch nicht selbst.

Controller Single-Cluster-Gateway-Controller Multi-Cluster-Gateway-Controller
Verwaltet von Google Google
Clusterbereich Einzelne Cluster-Gateways Multi-Cluster-Gateways
Bereitstellungsort Regional in derselben Region wie der GKE-Cluster bereitgestellt Wird global in mehreren Google Cloud-Regionen bereitgestellt.
Aktivierungsmethode Standardmäßig in GKE aktiviert. Aktiviert über die Multi-Cluster Ingress API und Registrierung in einer Flotte. Siehe Multi-Cluster-Gateways aktivieren.
Unterstützte GatewayClasses
  • gke-l7-rilb
  • gke-l7-gxlb
  • gke-l7-rilb-mc
  • gke-l7-gxlb-mc

Sie können mehrere Gateway-Controller, einschließlich Controller, die nicht von Google bereitgestellt werden, gleichzeitig in einem GKE-Cluster verwenden. Jede GatewayClass wird von einem einzigen Gateway-Controller unterstützt, wodurch das Single- und Multi-Cluster-Load-Balancing gleichzeitig verwendet werden kann.

Von Ingress zu Gateway migrieren

Die Migration zwischen Ingress und Gateway ist möglich, indem Sie gleichzeitig sowohl Ingress- als auch Gateway-Ressourcen bereitstellen, die auf dieselben Services verweisen. Dadurch werden zwei Einstiegspunkte für dieselben Back-End-Anwendungen erstellt. Jedes Ingress und Gateway entspricht einer einzelnen Load-Balancer-IP-Adresse. Testen Sie den Gateway-Pfad. Nach der Validierung wechseln Sie über DNS mit dem Traffic vom Ingress zum Gateway.

Die direkte Umwandlung eines Ingress in ein Gateway wird nicht unterstützt. Wenn Sie derzeit Ingress verwenden, sollten Sie beides gleichzeitig ausführen, damit Sie sich sicher sein können, dass die Umstellung auf das Gateway ohne Unterbrechung des Traffics erfolgt.

Preise

Alle über den Gateway-Controller bereitgestellten Compute Engine-Ressourcen werden über das Projekt abgerechnet, in dem sich die GKE-Cluster befinden. Der Single-Cluster-Gateway-Controller wird kostenlos als Teil der GKE-Standard- und Autopilot-Preise angeboten. Sie können den Multi-Cluster-Gateway-Controller ohne zusätzliche Kosten während der Vorschau verwenden. Sobald die GA-Phase beginnt, werden Multi-Cluster-Gateways gemäß den Preisen für Multi-Cluster-Ingress- und -Gateway-Ressourcen abgerechnet.

Nächste Schritte