Auf dieser Seite wird die GKE-Implementierung (Google Kubernetes Engine) der Kubernetes Gateway API mit dem GKE-Gateway-Controller beschrieben.
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.
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.
- Richtlinie: Definiert eine Reihe von implementierungsspezifischen Eigenschaften einer Gateway-Ressource. Sie können eine Richtlinie an ein Gateway, eine Route oder einen Kubernetes-Dienst anhängen.
GatewayClass
Eine GatewayClass ist eine Ressource, die eine Vorlage für 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.
| GatewayClass-Name | Beschreibung |
|---|---|
gke-l7-global-external-managed |
Globale externe Application Load Balancer, die auf dem globalen externen Application Load Balancer basieren |
gke-l7-regional-external-managed |
Regionale externe Application Load Balancer, die auf dem regionalen externen Application Load Balancer basieren |
gke-l7-rilb |
Interne Application Load Balancer, die auf dem internen Application Load Balancer basieren |
gke-l7-gxlb |
Globale externe Application Load Balancer, die auf dem klassischen Application Load Balancer basieren |
gke-l7-global-external-managed-mc |
Globale externe Application Load Balancer, die auf dem globalen externen Application Load Balancer basieren |
gke-l7-regional-external-managed-mc |
Regionale externe Multi-Cluster-Application Load Balancer, die auf dem globalen externen Application Load Balancer basieren |
gke-l7-rilb-mc |
Interne Multi-Cluster-Application Load Balancer, die auf dem internen Application Load Balancer basieren |
gke-l7-gxlb-mc |
Globale externe Multi-Cluster-Application Load Balancer, die auf dem klassischen Application Load Balancer basieren |
gke-td |
Multi-Cluster-Traffic Director-Service Mesh |
asm-l7-gxlb |
Globale externe Application Load Balancer, die auf Anthos Service Mesh 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.
Richtlinie
Eine Richtlinie definiert Eigenschaften einer Gateway-Ressource (normalerweise implementierungsspezifisch), die Clusteroperatoren an ein Gateway, eine Route oder einen Kubernetes-Dienst anhängen können. Eine Richtlinie definiert, wie die zugrunde liegende Google Cloud-Infrastruktur funktionieren soll.
Richtlinien sind in der Regel mit einem Namespace verknüpft und können auf eine Ressource im selben Namespace verweisen. Der Zugriff wird mithilfe von RBAC gewährt. Die hierarchische Beschaffenheit der Gateway API ermöglicht es Ihnen, eine Richtlinie an eine übergeordnete Ressource (Gateway) in einem Namespace anzuhängen und dass alle Ressourcen in verschiedenen Namespaces die Eigenschaften dieser Richtlinie erhalten.
Der GKE-Gateway-Controller unterstützt die folgenden Richtlinien:
HealthCheckPolicydefiniert die Parameter und das Verhalten der Systemdiagnose, mit der der Systemstatus der Backend-Pods geprüft wird.GCPGatewayPolicy: Definiert bestimmte Parameter des Front-Ends des Google Cloud-Load-Balancers. Dies ist mit einerFrontendConfigfür eine Ingress-Ressource vergleichbar.GCPBackendPolicydefiniert, wie die Backend-Dienste des Load-Balancers den Traffic auf die Endpunkte verteilen sollen. Dies ist mit einerBackendConfigfür eine Ingress-Ressource vergleichbar.
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.
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 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.
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.
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.
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. Beide Gateway-Controller sind allgemein verfügbar (Generally Available, GA).
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.
| Controller | Single-Cluster-Gateway-Controller | Multi-Cluster-Gateway-Controller |
|---|---|---|
| Verwaltet von | Google Cloud | Google Cloud |
| 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 |
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.
Ingress und Gateway
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. Nutzer sind dann gezwungen, 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 Frontend-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
Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: my-gateway
spec:
gatewayClassName: gke-l7-rilb
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
kinds:
- kind: HTTPRoute
Route
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: my-route
spec:
parentRefs:
- name: my-gateway
hostnames:
- "example.com"
rules:
- matches:
- path:
value: /
backendRefs:
- name: site
port: 80
- matches:
- path:
value: /shop
backendRefs:
- name: store
port: 80
Gateway API in Service Meshes einbinden
Sie können ein Traffic Director-Service Mesh-mit der Gateway API konfigurieren. Dies ermöglicht Dienst-zu-Dienst-Kommunikation, Traffic-Verwaltung, globales Load-Balancing und die Durchsetzung von Sicherheitsrichtlinien für Service-Mesh-Anwendungsfälle. Ausführliche Informationen zur Verwendung von Traffic Director mit der Gateway API, einschließlich Einrichtungsleitfäden für die Bereitstellung, finden Sie unter Übersicht über das Traffic Director-GKE-Service-Mesh.
Preise
Alle über die 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. Die Preise für Multi-Cluster-Gateways werden auf der Seite Preise für Multi-Cluster-Ingress und -Gateways beschrieben.
Nächste Schritte
- Ausführliche Informationen zur Verwendung von Traffic Director mit der Gateway API finden Sie unter Übersicht über das Traffic Director-GKE-Service-Mesh.