Diese Seite wurde von der Cloud Translation API übersetzt.

Gateways bereitstellen

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie Gateway-Ressourcen von Kubernetes für das Load-Balancing von eingehendem Traffic zu einem einzelnen Google Kubernetes Engine-Cluster (GKE) bereitstellen.

Informationen zum Bereitstellen von Gateways für das Load-Balancing von eingehendem Traffic über mehrere Cluster (oder Flotten) hinweg finden Sie unter Multi-Cluster-Gateways bereitstellen.

Weitere Informationen zu spezifischen Gateway-Konfigurationen wie namespaceübergreifendem Routing und Aufteilen von HTTP-Traffic finden Sie in den Gateway API-Nutzerhandbüchern.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Aktivieren Sie die Google Kubernetes Engine API.

Google Kubernetes Engine API aktivieren

Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

Prüfen Sie, ob Sie einen vorhandenen Autopilot- oder Standardcluster haben. Informationen zum Erstellen eines neuen Clusters finden Sie unter Autopilot-Cluster erstellen.

Anforderungen für GKE Gateway Controller

Die Gateway API wird nur in VPC-nativen Clustern unterstützt.
Wenn Sie die internen GatewayClasses verwenden, müssen Sie ein Nur-Proxy-Subnetz aktivieren.
Für den Cluster muss das Add-on HttpLoadBalancing aktiviert sein.
Wenn Sie Istio verwenden, müssen Sie Istio auf eine der folgenden Versionen aktualisieren:
- 1.15.2 oder höher
- 1.14.5 oder höher
- 1.13.9 oder höher
Wenn Sie eine freigegebene VPC verwenden, müssen Sie dem GKE-Dienstkonto für das Dienstprojekt im Hostprojekt die Rolle Compute Network User zuweisen.

Limits und Einschränkungen

Beachten Sie bei der Verwendung von GKE Gateway die folgenden Einschränkungen:

GKE-GatewayClasses unterstützen je nach dem verwendeten Load-Balancer unterschiedliche Funktionen. Weitere Informationen zu den verschiedenen Features, die mit jeder GatewayClass unterstützt werden, finden Sie unter GatewayClass-Funktionen.

Best Practice:
Begrenzen Sie die Anzahl der Gateways auf maximal 100, um eine optimale Leistung zu erzielen. Das Überschreiten dieses Limits kann sich auf die Leistung auswirken oder zu einer erhöhten Latenz führen.
Sie können keine FrontendConfig oder BackendConfig verwenden, um ein Gateway zu konfigurieren. Sie müssen eine Richtlinie verwenden.
Das GKE-Gateway verhält sich anders als Ingress, da das Gateway keine Systemdiagnoseparameter ableitet. Wenn Ihr Service für Anfragen an GET / nicht 200 zurückgibt oder Sie andere abgestimmte Pod-Bereitschaftsprüfungen haben, müssen Sie für Ihren Dienst eine HealthCheckPolicy konfigurieren.
Sie können für das Traffic-Routing keine Portnummer direkt im Hostnamen angeben (z. B. web.beispiel.de:80).
Sie können sich die von GKE für Gateways erstellten Load-Balancer-Ressourcen in der Google Cloud Console ansehen. Diese Ressourcen verweisen jedoch nicht auf das Gateway oder den GKE-Cluster, mit dem sie verknüpft sind.
Sie können nicht automatisch ein von Google verwaltetes SSL-Zertifikat mit Gateways generieren. Sie können aber manuell ein von Google verwaltetes SSL-Zertifikat erstellen und referenzieren. Weitere Informationen finden Sie unter Gateway sichern.
HTTPRoute ist der einzige unterstützte Routentyp. TCPRoutes, UDPRoutes und TLSRoutes werden nicht unterstützt. Eine Liste der vom GKE Gateway Controller unterstützten Felder finden Sie unter GatewayClass-Funktionen.
Benutzerdefinierte Anfrage- und Antwortheader mit Gateway- oder Pfadweiterleitungen und URL-Neuschreibungen mit Gateway sind nur in GKE-Version 1.27 oder höher verfügbar.
Die GatewayClass gke-l7-gxlb wird für benutzerdefinierte Anfrage- und Antwortheader mit Gateway- und Pfadweiterleitungen sowie URL-Rewrites mit Gateway nicht unterstützt.
Beim Konfigurieren benutzerdefinierter Anfrage- und Antwortheader für HTTPRoute werden die folgenden Google Cloud -Variablen nicht unterstützt:
- cdn_cache_id (Cloud CDN wird mit GKE Gateway nicht unterstützt)
- cdn_cache_status (Cloud CDN wird mit GKE Gateway nicht unterstützt)
- origin_request_header (CORS-Richtlinien werden mit GKE Gateway nicht unterstützt)
GKE Gateway unterstützt die Load Balancing-Funktion von Cloud CDN nicht.
Benutzerdefinierte TLS-Header werden nicht unterstützt (mTLS mit GKE-Gateway wird nicht unterstützt)
Die Einschränkungen für den klassischen Application Load BalancerGoogle Cloud gelten für das GKE Gateway. Außerdem können Sie keinen benutzerdefinierten Host-Antwortheader im Backend-Dienst konfigurieren.
Pfadweiterleitungen und URL-Umschreibungen schließen sich gegenseitig aus. Sie können nicht beide Filter gleichzeitig in denselben Regeln verwenden.
Die Weiterleitung von Traffic an einen anderen Port wird mit Cloud Load Balancing nicht unterstützt. Die Liste der vom GKE Gateway Controller unterstützten Felder finden Sie unter GatewayClass-Funktionen.
GKE Gateway unterstützt keine Platzhalter, regulären Ausdrücke und dynamischen URLs.
Wenn Sie ein Gateway mit einer regionalen externen Gateway-Klasse angeben, stellt der Controller eine interne IP-Adresse anstelle der externen Adresse bereit. Informationen zum Verwenden einer benannten Adresse mit dem regionalen externen Application Load Balancer finden Sie unter Regionales externes Gateway bereitstellen.
Das Gateway verwendet eigenständige NEGs für die Bereitstellung von Netzwerk-Endpunktgruppen. Um sicherzustellen, dass der Gateway-Controller die Load-Balancer-Konfiguration ordnungsgemäß abgleicht, können Sie die Annotation cloud.google.com/neg für einen Service, der Teil des Gateways ist, nicht ändern.
GKE Gateway unterstützt nicht das Verweisen auf einen Service, auf den auch von GKE Ingress verwiesen wird.
Wenn ein Gateway zur Bereitstellung einer Adresse konfiguriert ist, wird das Ändern von Gateway.spec.gatewayClass nicht unterstützt. Löschen Sie das vorhandene Gateway und stellen Sie das Manifest mit dem aktualisierten Wert gatewayClass noch einmal bereit, damit der Gateway-Controller den Load Balancer ordnungsgemäß abgleicht.
Die Annotation networking.gke.io/app-protocols wird nicht unterstützt. Verwenden Sie stattdessen das Feld appProtocol, um denselben Effekt zu erzielen.
Wenn Sie GKE Gateway mit external-dns verwenden und der Dienststatus des Gateways nicht „Gesund“ ist, werden standardmäßig alle mit dem Gateway verknüpften DNS-Einträge aus Ihren DNS-Zonen gelöscht.

Best Practice:
Legen Sie beim Ausführen von external-dns das Flag policy=upsert-only fest. Diese Konfiguration trägt dazu bei, dass vorhandene DNS-Einträge nicht gelöscht werden.
Wenn ein Port aus einem Service entfernt wird, auf das GKE Gateway über eine Route verweist, müssen Sie auch die Standalone NEG-Annotation für den Dienst aktualisieren, um diesen Port zu entfernen. Andernfalls synchronisiert der NEG-Controller die Pod-Endpunkte für diesen Dienst nicht mehr. Weitere Informationen finden Sie unter NEG-Controller beendet die Verwaltung von Endpunkten, wenn der Port aus dem Dienst entfernt wird.
Bereitstellungen mit Multi-Cluster-Gateways (MCG), die zonale Cluster verwenden, sind bei Cluster-Upgrades anfällig für Dienstunterbrechungen. Dieses Problem tritt auf, weil ein alter Erkennungsmechanismus für Netzwerk-Endpunktgruppen (NEGs) möglicherweise fälschlicherweise null Back-Ends meldet, wenn die Steuerungsebene des zonalen Clusters vorübergehend nicht verfügbar ist. Es wird an einer langfristigen Lösung gearbeitet. Um diesen Single Point of Failure zu vermeiden, verwenden Sie regionale GKE-Cluster mit MCG.

Gateway API im Cluster aktivieren

Bevor Sie Gateway-Ressourcen in GKE verwenden können, muss in Ihrem Cluster die Gateway API aktiviert sein.

Bevor Sie einen vorhandenen GKE-Cluster aktualisieren, um die Gateway API zu aktivieren, müssen die Mindestanforderungen erfüllt sein, bevor die Aktualisierung fortgesetzt wird.

Mit dem folgenden Befehl aktivieren Sie die Gateway API in einem vorhandenen GKE-Cluster (Autopilot oder Standard). Es kann bis zu 45 Minuten dauern, bis der Cluster die CRDs abgleicht und installiert.

gcloud container clusters update CLUSTER_NAME \
    --location=CLUSTER_LOCATION\
    --gateway-api=standard

Ersetzen Sie Folgendes:

CLUSTER_NAME den Namen des vorhandenen Clusters.
CLUSTER_LOCATION ist die Compute Engine-Region oder -Zone des Clusters.

Das Flag --gateway-api=standard weist GKE an, mit dem Cluster die v1beta1-CRDs zu installieren.

Cluster prüfen

Nach dem Erstellen oder Upgraden Ihres Clusters installiert GKE-Gateway Controller automatisch GatewayClasses. Es kann einige Minuten dauern, bis der Controller die CRDs erkennt und die GatewayClasses installiert.

Prüfen Sie, ob die Gateway API in der GKE-Steuerungsebene aktiviert ist:

gcloud container clusters describe CLUSTER_NAME \
  --location=CLUSTER_LOCATION \
  --format json

Die entsprechende Ausgabe sieht etwa so aus: Wenn diese Ausgabe leer ist, führen Sie den Befehl zur Clusteraktualisierung noch einmal aus.

"networkConfig": {
  ...
  "gatewayApiConfig": {
    "channel": "CHANNEL_STANDARD"
  },
  ...
},

Prüfen Sie, ob die GatewayClasses in Ihrem Cluster installiert sind:

kubectl get gatewayclass

Die Ausgabe sieht in etwa so aus:

NAME                             CONTROLLER                  ACCEPTED   AGE
gke-l7-global-external-managed   networking.gke.io/gateway   True       16h
gke-l7-regional-external-managed networking.gke.io/gateway   True       16h
gke-l7-gxlb                      networking.gke.io/gateway   True       16h
gke-l7-rilb                      networking.gke.io/gateway   True       16h

Die Funktionen jeder GatewayClass finden Sie unter GatewayClass-Funktionen.

Nur Single-Cluster-GatewayClasses werden automatisch installiert. Informationen zum Installieren und Verwenden der Multi-Cluster-GatewayClasses für das interne und externe Multi-Cluster-Load-Balancing finden Sie unter Multi-Cluster-Gateways aktivieren.

Internes Gateway bereitstellen

Ein internes Gateway stellt Anwendungen bereit, die nur innerhalb der VPC oder mit den mit der VPC verbundenen Netzwerken erreichbar sind.

Regionales internes Gateway bereitstellen

Im folgenden Beispiel wird gezeigt, wie Sie ein regionales internes Gateway bereitstellen, das eine effiziente und sichere Kommunikation zwischen Diensten in einer bestimmten geografischen Region ermöglicht.

Nur-Proxy-Subnetz konfigurieren

Sie müssen ein Nur-Proxy-Subnetz konfigurieren, bevor Sie ein Gateway erstellen, das einen internen Anwendungs-Load-Balancer verwendet. Jede Region einer VPC, in der Sie interne Anwendungs--Load-Balancer verwenden, muss ein Nur-Proxy-Subnetz haben. Dieses Subnetz stellt interne IP-Adressen für die Load-Balancer-Proxys bereit.

Nur-Proxy-Subnetz erstellen:
```
gcloud compute networks subnets create SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=COMPUTE_REGION \
    --network=VPC_NETWORK_NAME \
    --range=CIDR_RANGE
```
Ersetzen Sie Folgendes:
- SUBNET_NAME: die Region des Nur-Proxy-Subnetzes.
- COMPUTE_REGION ist die Region des Nur-Proxy-Subnetzes.
- VPC_NETWORK_NAME: der Name des VPC-Netzwerks, in dem Sie dieses Nur-Proxy-Subnetz erstellen. Achten Sie darauf, dass es sich um dasselbe VPC-Netzwerk handelt, in dem sich Ihr GKE-Cluster befindet und in dem Sie das Gateway bereitstellen. Dies ist wichtig für eine reibungslose Kommunikation zwischen dem Load Balancer und Ihren Back-End-Diensten.
- CIDR_RANGE: der primäre IP-Adressbereich des Subnetzes. Die Subnetzmaske darf maximal /26 lang sein, damit mindestens 64 IP-Adressen für Proxys in der Region verfügbar sind. Als Subnetzmaske wird /23 empfohlen.

Überprüfen Sie Ihr Nur-Proxy-Subnetz:

gcloud compute networks subnets describe SUBNET_NAME \
    --region=COMPUTE_REGION

Die Ausgabe sieht in etwa so aus:

...
gatewayAddress: 10.1.1.1
ipCidrRange: 10.1.1.0/24
kind: compute#subnetwork
name: proxy-subnet
network: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/networks/default
privateIpGoogleAccess: false
privateIpv6GoogleAccess: DISABLE_GOOGLE_ACCESS
purpose: REGIONAL_MANAGED_PROXY
region: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION
role: ACTIVE
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION/subnetworks/proxy-subnet
state: READY

Gateway erstellen

Eine Gateway-Ressource stellt eine Datenebene dar, die Traffic in Kubernetes weiterleitet. Ein Gateway kann je nach der abgeleiteten GatewayClass viele verschiedene Arten von Load-Balancing und Routing darstellen. Weitere Informationen zur Gateway-Ressource finden Sie in der Beschreibung der Gateway-Ressource oder in der API-Spezifikation.

In diesem Fall möchte der Administrator des GKE-Clusters ein Gateway erstellen, mit dem verschiedene Teams ihre Anwendungen intern freigeben können. Der Administrator stellt das Gateway bereit und die Anwendungsteams stellen ihre Routen separat bereit und hängen sie an dieses Gateway.

Speichern Sie folgendes Gateway-Manifest in einer Datei mit dem Namen gateway.yaml.
```
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
   name: internal-http
spec:
  # Specify an existing GatewayClass.
  gatewayClassName: gke-l7-rilb
  listeners:
  # Listen for HTTP traffic on port 80.
  - name: http
    protocol: HTTP
    port: 80
```
Dieses Manifest enthält die folgenden Felder:
- gatewayClassName: gke-l7-rilb: gibt die GatewayClass an, von der dieses Gateway abgeleitet wurde. gke-l7-rilb entspricht dem internen Anwendungs-Load-Balancer.
- port: 80: gibt an, dass das Gateway nur Port 80 für das Monitoring von HTTP-Traffic freigibt.
Dieses Gateway ist so konfiguriert, dass es nur HTTP-Traffic an Port 80 verarbeitet. HTTPS (Port 443) wird standardmäßig nicht unterstützt. Wenn Sie versuchen, eine Verbindung über HTTPS herzustellen, schlägt die Anfrage möglicherweise fehl.
Stellen Sie das Gateway in Ihrem Cluster bereit:
```
kubectl apply -f gateway.yaml
```

Prüfen Sie, ob das Gateway ordnungsgemäß bereitgestellt wurde. Es kann einige Minuten dauern, bis alle Ressourcen bereitgestellt wurden.

kubectl describe gateways.gateway.networking.k8s.io internal-http

Die Ausgabe sieht etwa so aus:

Name:         internal-http
Namespace:    default
Spec:
  Gateway Class Name:  gke-l7-rilb
  Listeners:
    Allowed Routes:
      Kinds:
        Group:  gateway.networking.k8s.io
        Kind:   HTTPRoute
      Namespaces:
        From:  Same
    Name:      http
    Port:      80
    Protocol:  HTTP
 Status:
   Addresses:
     Type:   IPAddress
     Value:  192.168.1.14
   Conditions:
     Last Transition Time:  2025-03-19T19:53:46Z
     Message:               The OSS Gateway API has deprecated this condition, do not depend on it.
     Observed Generation:   1
     Reason:                Scheduled
     Status:                True
     Type:                  Scheduled
     Last Transition Time:  2025-03-19T19:53:46Z
     Message:
     Observed Generation:   1
     Reason:                Accepted
     Status:                True
     Type:                  Accepted
     Last Transition Time:  2025-03-19T19:53:46Z
     Message:
     Observed Generation:   1
     Reason:                Programmed
     Status:                True # Indicates that the Gateway is ready.
     Type:                  Programmed
     Last Transition Time:  2025-03-19T19:53:46Z
     Message:               The OSS Gateway API has altered the "Ready" condition semantics and reserved it for future use.  GKE Gateway will stop emitting it in a future update, use "Programmed" instead.
     Observed Generation:   1
     Reason:                Ready
     Status:                True
     Type:                  Ready
     Last Transition Time:  2025-03-19T19:53:46Z
     Message:
     Observed Generation:   1
     Reason:                Healthy
     Status:                True
     Type:                  networking.gke.io/GatewayHealthy
Events:
  Type    Reason  Age                From                       Message
  ----    ------  ----               ----                       -------
  Normal  ADD     92s                networking.gke.io/gateway  test/internal-http
  Normal  UPDATE  45s (x3 over 91s)  networking.gke.io/gateway  test/internal-http
  Normal  SYNC    45s                networking.gke.io/gateway  SYNC on test/internal-http was a success

In dieser Ausgabe gibt der Status True für die Bedingung Programmed an, dass das Gateway bereit ist.

Jetzt befindet sich in Ihrem Cluster ein Gateway, das einen Load-Balancer und eine IP-Adresse bereitgestellt hat. Das Gateway hat jedoch keine Routen und weiß daher nicht, wie es den Traffic an die Back-Ends senden soll. Ohne Routen wird der gesamte Traffic an ein Standard-Backend weitergeleitet, das einen HTTP 404-Fehler zurückgibt. Als Nächstes stellen Sie eine Anwendung und Routen bereit, die dem Gateway mitteilen, wie sie zu Anwendungs-Back-Ends gelangen.

Demoanwendungen bereitstellen

Anwendungsteams können ihre Anwendungen und Routen unabhängig von der Bereitstellung von Gateways bereitstellen. In manchen Fällen möchte das Anwendungsteam das Gateway auch besitzen und es selbst als Ressource für seine Anwendungen einsetzen. Weitere Informationen zu verschiedenen Inhabermodellen von Gateways und Routen finden Sie unter Routenbindung. In diesem Beispiel stellt das Speicherteam seine Anwendung und eine zugehörige HTTPRoute bereit, um die Anwendung über das im vorherigen Abschnitt erstellte Gateway internal-http freizugeben.

Die HTTPRoute-Ressource verfügt über viele konfigurierbare Felder für den Traffic-Abgleich. Eine Erläuterung der Felder von HTTPRoute finden Sie in der API-Spezifikation.

Stellen Sie die Store-Anwendung (Bereitstellung von store-v1, store-v2 und store-german) auf dem Cluster bereit:
```
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/store.yaml
```
Dadurch werden drei Bereitstellungen und drei Dienste mit den Namen „store-v1“, „store-v2“ und „store-german“ erstellt.

Prüfen Sie, ob die Anwendung erfolgreich bereitgestellt wurde:

kubectl get pod

Die Ausgabe sieht nach der Ausführung der Anwendung in etwa so aus:

NAME                        READY   STATUS    RESTARTS   AGE
store-german-66dcb75977-5gr2n   1/1     Running   0          38s
store-v1-65b47557df-jkjbm       1/1     Running   0          14m
store-v2-6856f59f7f-sq889       1/1     Running   0          14m

Prüfen Sie, ob die Services bereitgestellt wurden:

kubectl get service

Die Ausgabe zeigt einen Service für jede´s Store-Deployment an:

NAME           TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
store-german   ClusterIP   10.48.3.183   <none>        8080/TCP   4s
store-v1       ClusterIP   10.48.2.224   <none>        8080/TCP   5s
store-v2       ClusterIP   10.48.4.48    <none>        8080/TCP   5s

HTTPRoute bereitstellen

Routenressourcen definieren protokollspezifische Regeln für die Zuordnung von Traffic von einem Gateway zu den Back-Ends von Kubernetes. Die HTTPRoute-Ressource ermöglicht HTTP- und HTTPS-Trafficabgleich und Filter und wird von allen gke-l7-GatewayClasses unterstützt.

In diesem Abschnitt stellen Sie eine HTTPRoute bereit, die das Gateway mit den Routingregeln programmiert, die zum Erreichen der Speicheranwendung erforderlich sind.

Speichern Sie folgendes HTTPRoute-Manifest in einer Datei mit dem Namen store-route.yaml.

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store
spec:
  # Attach the HTTPRoute to a Gateway.
  parentRefs:
  - kind: Gateway
    name: internal-http
  # Route requests that have `store.example.com` in the Host header.
  hostnames:
  - "store.example.com"
  rules:
  # Send requests with the `env: canary` header to the `store-v2` Service.
  - matches:
    - headers:
      - name: env
        value: canary
    backendRefs:
    - name: store-v2
      port: 8080
  # Send requests with `/de` in the path to the `store-german` Service.
  - matches:
    - path:
        value: /de
    backendRefs:
    - name: store-german
      port: 8080
  # Send unmatched requests to the store-v1 Service.
  - backendRefs:
    - name: store-v1
      port: 8080

Stellen Sie die HTTPRoute in Ihrem Cluster bereit:
```
kubectl apply -f store-route.yaml
```
Die HTTPRoute store ist mithilfe des Attributs parentRefs an das Gateway internal-http gebunden. Diese Routingregeln werden wie im folgenden Diagramm für den zugrunde liegenden Load-Balancer konfiguriert:

Diese Routingregeln verarbeiten HTTP-Traffic auf folgende Weise:
- Traffic an store.example.com/de wird an den Service store-german weitergeleitet.
- Traffic an store.example.com mit dem HTTP-Header "env: canary" wird an den Service store-v2 weitergeleitet.
- Der verbleibende Traffic an store.example.com wird an den Service store-v1 weitergeleitet.

Prüfen Sie, ob die HTTPRoute bereitgestellt wurde:

kubectl describe httproute store

Die Ausgabe sieht in etwa so aus:

Name:         store
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  gateway.networking.k8s.io/v1
Kind:         HTTPRoute
# Multiple lines are omitted here.
Spec:
  Hostnames:
    store.example.com
  Parent Refs:
    Group:  gateway.networking.k8s.io
    Kind:   Gateway
    Name:   internal-http
  Rules:
    Backend Refs:
      Group:
      Kind:    Service
      Name:    store-v1
      Port:    8080
      Weight:  1
    Matches:
      Path:
        Type:   PathPrefix
        Value:  /
    Backend Refs:
      Group:
      Kind:    Service
      Name:    store-v2
      Port:    8080
      Weight:  1
    Matches:
      Headers:
        Name:   env
        Type:   Exact
        Value:  canary
      Path:
        Type:   PathPrefix
        Value:  /
    Backend Refs:
      Group:
      Kind:    Service
      Name:    store-german
      Port:    8080
      Weight:  1
    Matches:
      Path:
        Type:   PathPrefix
        Value:  /de
Status:
  Parents:
    Conditions:
      Last Transition Time:  2022-11-01T04:18:52Z
      Message:
      Reason:                Accepted
      Status:                True
      Type:                  Accepted
      Last Transition Time:  2022-11-01T04:18:52Z
      Message:
      Reason:                ReconciliationSucceeded
      Status:                True
      Type:                  Reconciled
    Controller Name:         networking.gke.io/gateway
    Parent Ref:
      Group:  gateway.networking.k8s.io
      Kind:   Gateway
      Name:   internal-http
Events:
  Type    Reason  Age                From                   Message
  ----    ------  ----               ----                   -------
  Normal  ADD     24m                sc-gateway-controller  default/store
  Normal  SYNC    16m (x4 over 23m)  sc-gateway-controller  Bind of HTTPRoute "default/store" to ParentRef {Group:       gateway.networking.k8s.io",
  # Multiple lines are omitted here.

Prüfen Sie, ob die HTTPRoute an das Gateway gebunden ist:

kubectl describe gateway

Die Ausgabe sieht in etwa so aus:

Name:         internal-http
Namespace:    default
Labels:       <none>
<...>
Status:
  Addresses:
    Type:   IPAddress
    Value:  10.128.15.203
  Conditions:
    Last Transition Time:  2022-11-01T03:47:01Z
    Message:
    Reason:                Scheduled
    Status:                True
    Type:                  Scheduled
    Last Transition Time:  2022-11-01T03:47:01Z
    Message:
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Listeners:
    Attached Routes:  1
    Conditions:
      Last Transition Time:  2022-11-01T03:47:01Z
      Message:
      Reason:                Ready
      Status:                True
      Type:                  Ready
    Name:                    http
    Supported Kinds:
      Group:  gateway.networking.k8s.io
      Kind:   HTTPRoute
      <...>

Traffic an die Anwendung senden

Nachdem das Gateway, die Route und die Anwendung in Ihrem Cluster bereitgestellt wurden, können Sie den Traffic an Ihre Anwendung weiterleiten. Das Gateway ist so konfiguriert, dass HTTP-Traffic nur über Port 80 bereitgestellt wird. Anfragen, die mit HTTPS gestellt werden, schlagen möglicherweise fehl, wenn TLS nicht separat konfiguriert wurde.

Rufen Sie die IP-Adresse aus dem Gateway ab, damit Sie Traffic an die Anwendung senden können:
```
kubectl get gateways.gateway.networking.k8s.io internal-http -o=jsonpath="{.status.addresses[0].value}"
```
Die Ausgabe ist eine IP-Adresse.
Senden Sie Traffic von der Shell auf einer VM-Instanz mit Konnektivität zum Cluster an diese IP-Adresse. Zu diesem Zweck können Sie eine VM erstellen. Dies ist erforderlich, da das Gateway eine interne IP-Adresse hat und nur von innerhalb Ihres VPC-Netzwerks zugänglich ist. Da internal-http ein regionaler Load-Balancer ist, muss sich die Client-Shell in derselben Region wie der GKE-Cluster befinden.

Stellen Sie eine Anfrage an „store.example.com“:
```
curl http://store.example.com --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v
```
Ersetzen Sie GATEWAY_IP_ADDRESS durch die IP-Adresse aus dem vorherigen Schritt.

Die Ausgabe der Demo-App enthält Informationen zum Standort, an dem die Anwendung ausgeführt wird:
```
{
  "cluster_name": "gke1",
  "host_header": "store.example.com",
  "metadata": "store-v1",
  "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
  "pod_name": "store-v1-84b47c7f58-pmgmk",
  "pod_name_emoji": "💇🏼‍♀️",
  "project_id": "gateway-demo-243723",
  "timestamp": "2022-10-25T13:31:17",
  "zone": "ZONE_NAME"
}
```

Testen Sie die Pfadübereinstimmung. Rufen Sie dazu die deutsche Version des Speicherdienstes unter store.example.com/de auf:

curl http://store.example.com/de --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v

Die Ausgabe bestätigt, dass die Anfrage von einem store-german-Pod bereitgestellt wurde:

{
  "cluster_name": "gke1",
  "host_header": "store.example.com",
  "metadata": "Gutentag!", 
  "node_name": "gke-gke1-pool-2-bd121936-n3xn.c.gateway-demo-243723.internal",
  "pod_name": "store-german-5cb6474c55-lq5pl", 
  "pod_name_emoji": "🧞‍♀",
  "project_id": "gateway-demo-243723",
  "timestamp": "2022-10-25T13:35:37",
  "zone": "ZONE_NAME"
}

Abschließend senden Sie den Traffic mit dem HTTP-Header env: canary an die Canary-Version des Store-Dienstes:

curl -H "env: canary" http://store.example.com --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v

Die Ausgabe bestätigt, dass die Anfrage von einem store-v2-Pod bereitgestellt wurde:

{
  "cluster_name": "gke1",
  "host_header": "store.example.com",
  "metadata": "store-v2", 
  "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
  "pod_name": "store-v2-5788476cbd-s9thb", 
  "pod_name_emoji": "🦰",
  "project_id": "gateway-demo-243723",
  "timestamp": "2022-10-25T13:38:26",
  "zone": "ZONE_NAME"
}

Externes Gateway bereitstellen

Ein externes Gateway macht Anwendungen verfügbar, die über das Internet oder Netzwerke außerhalb Ihres VPC-Netzwerk erreichbar sind. Die Bereitstellung ähnelt einer internen Gateway-Bereitstellung, mit der Ausnahme, dass Sie Ihre Anwendungen sichern müssen, da das Gateway über das öffentliche Internet zugänglich ist.

Sie haben zwei Möglichkeiten, ein externes Gateway zu erstellen: ein globales externes Gateway oder ein regionales externes Gateway.

Globales externes Gateway:Dieses Gateway verwendet eine globale IP-Adresse (oder Anycast-IP-Adresse) als Frontend des Gateways. Diese IP-Adresse wird in allen Google Cloud Compute-Regionen beworben. Clients, die Traffic an diese Anycast-IP-Adresse senden, werden an den nächstgelegenen Google-Standort weitergeleitet, an dem die IP-Adresse beworben wird. Das globale externe Gateway ist nur in der Premium-Netzwerkdienststufe verfügbar.
Regionales externes Gateway:Dieses Gateway verwendet eine regionale IP-Adresse als Frontend des Gateways. Das Verhalten dieses Gateways hängt von der ausgewählten Netzwerkdienststufe ab:
- Wenn Sie die Standard-Netzwerkdienststufe (Standard) auswählen, wird die regionale IP-Adresse nur in der lokalen Google Cloud Compute-Region beworben, in der das regionale externe Gateway bereitgestellt ist. Clients, die Traffic an diese IP-Adresse senden, werden von ihrem lokalen Internetanbieter und über das öffentliche Internet weitergeleitet, bevor sie die Google-Region erreichen, in der die IP-Adresse beworben wird.
- Wenn Sie die Premium-Netzwerkdienststufe auswählen, wird die regionale IP-Adresse im gesamten globalen Netzwerk von Google beworben. Das bedeutet, dass der Client-Traffic an einem Google Edge Peering Point, der dem Client so nah wie möglich ist, in den hochwertigen globalen Backbone von Google eintritt, auch wenn das Ziel eine regionale IP-Adresse ist. Dieser Standort verringert die Latenz und verbessert die Leistung erheblich, da die Entfernung, die der Datenverkehr über das öffentliche Internet zurücklegt, minimiert wird.

Globales externes Gateway bereitstellen

Das folgende Beispiel zeigt, wie Sie eine Speicheranwendung mit mehreren Zertifikaten, die an das globale externe Gateway angehängt und in einer Zertifikatszuordnung gruppiert sind, mit dem Zertifikatmanager und einer HTTPRoute bereitstellen können.

Zertifikatzuordnung erstellen

Google empfiehlt die Verwendung des Zertifikatsmanagers zur Verwaltung von Zertifikaten, wenn Sie mindestens 15 Zertifikate pro Gateway benötigen oder Platzhalterzertifikate verwenden müssen.

Sie können Ihr externes Gateway auch mit Kubernetes-Secrets oder von Google verwalteten SSL-Zertifikaten schützen. Weitere Informationen finden Sie unter Gateway-Sicherheit.

In diesem Abschnitt erstellen Sie mit dem Zertifikatsmanager Zertifikate, um die im Cluster ausgeführten Anwendungen zu schützen.

Aktivieren Sie die Certificate Manager API:

gcloud services enable certificatemanager.googleapis.com

Erstellen Sie eine Zertifikatzuordnung:

gcloud beta certificate-manager maps create store-example-com-map

Laden Sie Ihr von Google verwaltetes Zertifikat und Ihre Schlüssel in ein Zertifikat:
```
gcloud beta certificate-manager certificates create store-example-com-cert \
    --certificate-file="CERTIFICATE_FILE" \
    --private-key-file="PRIVATE_KEY_FILE"
```
Ersetzen Sie Folgendes:
- CERTIFICATE_FILE: der Name der Zertifikatsdatei. Die Datei muss die Erweiterung .pem haben. Beispiel: cert.pem.
- PRIVATE_KEY_FILE ist der Name Ihrer privaten Schlüsseldatei.
Weitere Informationen finden Sie unter Privaten Schlüssel und Zertifikat erstellen.

Erstellen Sie einen CertificateMapEntry, der das Zertifikat der Zertifikatszuordnung zuweist:

gcloud beta certificate-manager maps entries create store-example-com-map-entry \
    --map=store-example-com-map \
    --hostname=store.example.com \
    --certificates=store-example-com-cert

Informationen zum Sichern eines Gateways mithilfe anderer Quellen für Zertifikate wie Kubernetes-Secrets oder SSL-Zertifikate finden Sie unter Gateway sichern.

Gateway erstellen

Eine Gateway-Ressource stellt eine Datenebene dar, die Traffic in Kubernetes weiterleitet. Ein Gateway kann je nach verwendeter GatewayClass viele verschiedene Arten von Load-Balancing und Routing repräsentieren.

Weitere Informationen zur Gateway-Ressource finden Sie in der Beschreibung der Gateway-Ressource oder in der API-Spezifikation.

In diesem Abschnitt erstellen Sie ein Gateway. Anwendungsteams können das Gateway verwenden, um ihre Anwendungen für das Internet freizugeben. Dabei werden Routen unabhängig bereitgestellt und sicher an das Gateway angehängt.

Speichern Sie folgendes Manifest in einer Datei mit dem Namen gateway.yaml:
```
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http
  annotations:
    networking.gke.io/certmap: store-example-com-map
spec:
  # This GatewayClass uses a global external Application Load Balancer.
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
```
Dieses Manifest beschreibt ein Gateway mit folgenden Feldern:
- gatewayClassName: gke-l7-global-external-managed: gibt die GatewayClass für dieses Gateway an. Diese Gateway-Klasse verwendet einen globalen externen Anwendungs-Load-Balancer.
- protocol: HTTPS und port: 443: gibt an, dass das Gateway Port 443 für HTTPS-Traffic verfügbar macht. Mit diesen Feldern wird TLS aktiviert.
- networking.gke.io/certmap: store-example-com-map: gibt den Namen der Zertifikatszuordnung im Zertifikatmanager an.
Es gibt keinen TLS-Abschnitt, da TLS mit dem Zertifikatmanager konfiguriert wird und dazu die Annotation networking.gke.io/certmap verwendet.
Wenden Sie das Manifest auf Ihren Cluster an:
```
kubectl apply -f gateway.yaml
```
Es kann einige Minuten dauern, bis GKE die Ressourcen bereitgestellt hat.
Prüfen Sie, ob das Gateway erfolgreich bereitgestellt wurde:
```
kubectl describe gateway
```
Die Ausgabe sieht in etwa so aus:
```
Name:         external-http
Namespace:    default
Labels:       <none>
...
Spec:
  Gateway Class Name:  gke-l7-global-external-managed
  Listeners:
    Allowed Routes:
      Namespaces:
        From:  Same
    Name:      https
    Port:      443
    Protocol:  HTTPS
    Tls:
      Certificate Refs:
        Group:
        Kind:   Secret
        Name:   store-example-com
      Mode:     Terminate
 ...
```
Diese Ausgabe zeigt, dass das in Ihrem Cluster bereitgestellte Gateway einen Load-Balancer und eine öffentliche IP-Adresse hat. Das Gateway hat keine Routen, was bedeutet, dass es keinen Traffic an Back-Ends senden kann. Ohne Routen wird der gesamte Traffic an ein Standard-Backend weitergeleitet, das einen HTTP 404-Fehler zurückgibt. Im nächsten Abschnitt stellen Sie Routen bereit, die das Gateway anweisen, Traffic an Back-Ends zu senden.

Demoanwendungen bereitstellen

Anwendungsteams können ihre Anwendungen und Routen unabhängig von der Bereitstellung von Gateways bereitstellen. In manchen Fällen möchte das Anwendungsteam auch Inhaber des Gateways sein und es selbst als Ressource für seine Anwendungen bereitstellen. Weitere Informationen zu verschiedenen Inhabermodellen von Gateways und Routen finden Sie unter Routenbindung. In diesem Beispiel stellt das Store-Team seine Anwendung und eine zugehörige HTTPRoute bereit, um die Anwendung über das im vorherigen Abschnitt erstellte Gateway external-http freizugeben.

Weitere Informationen zu HTTPRoute-Feldern finden Sie in der API-Spezifikation.

Stellen Sie die Beispielanwendung in Ihrem Cluster bereit:
```
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/store.yaml
```
Diese Beispielanwendung erstellt drei Deployments und drei Services mit den Namen store-v1, store-v2 und store-german.

Prüfen Sie, ob die Anwendung erfolgreich bereitgestellt wurde:

kubectl get pod

Die Ausgabe sieht in etwa so aus:

NAME                            READY   STATUS    RESTARTS   AGE
store-german-66dcb75977-5gr2n   1/1     Running   0          38s
store-v1-65b47557df-jkjbm       1/1     Running   0          14m
store-v2-6856f59f7f-sq889       1/1     Running   0          14m

Prüfen Sie, ob die Services erfolgreich bereitgestellt wurden:

kubectl get service

Die Ausgabe sieht in etwa so aus:

NAME           TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
store-german   ClusterIP   10.48.3.183   <none>        8080/TCP   4s
store-v1       ClusterIP   10.48.2.224   <none>        8080/TCP   5s
store-v2       ClusterIP   10.48.4.48    <none>        8080/TCP   5s

HTTPRoute erstellen

Routenressourcen definieren protokollspezifische Regeln für die Zuordnung von Traffic von einem Gateway zu den Back-Ends von Kubernetes. Die HTTPRoute-Ressource ermöglicht HTTP- und HTTPS-Traffic-Abgleich und Filterung und wird von allen gke-l7-*-GatewayClasses unterstützt.

In diesem Abschnitt stellen Sie eine HTTPRoute bereit, die das Gateway mit Routingregeln konfiguriert, die zum Erreichen der Beispielanwendung erforderlich sind.

Speichern Sie folgendes Manifest in einer Datei mit dem Namen store-route-external.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-external
spec:
  parentRefs:
  # Bind the route to the 'external-http' Gateway.
  - kind: Gateway
    name: external-http
  hostnames:
  - "store.example.com"
  rules:
  # Default rule for store.example.com that sends traffic to the store-v1 service.
  - backendRefs:
    - name: store-v1
      port: 8080
  # Match requests with the "env: canary" header and send them to the store-v2 service.
  - matches:
    - headers:
      - name: env
        value: canary
    backendRefs:
    - name: store-v2
      port: 8080
  # Match requests with the path "/de" and sends them to the store-german service.
  - matches:
    - path:
        value: /de
    backendRefs:
    - name: store-german
      port: 8080

Dieses Manifest beschreibt eine HTTPRoute, die auf das external-http-Gateway verweist.

Wenden Sie das Manifest auf Ihren Cluster an:
```
kubectl apply -f store-route-external.yaml
```
Die HTTPRoute store ist mithilfe des Attributs parentRefs an das Gateway external-http gebunden. Das folgende Diagramm zeigt die Routingregeln, die für den zugrunde liegenden Load-Balancer konfiguriert sind:

Die Routingregeln verarbeiten HTTP-Traffic so:
- Traffic an store.example.com/de wird an den Service store-german weitergeleitet.
- Traffic an store.example.com mit dem HTTP-Header "env: canary" wird an den Service store-v2 weitergeleitet.
- Der verbleibende Traffic an store.example.com wird an den Service store-v1 weitergeleitet.

Prüfen Sie, ob die HTTPRoute bereitgestellt wurde:

kubectl describe httproute store-external

Die Ausgabe sieht in etwa so aus:

Name:         store-external
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  gateway.networking.k8s.io/v1
Kind:         HTTPRoute
# Multiple lines are omitted here.
Spec:
  Hostnames:
    store.example.com
  Parent Refs:
    Group:  gateway.networking.k8s.io
    Kind:   Gateway
    Name:   external-http
  Rules:
    Backend Refs:
      Group:
      Kind:    Service
      Name:    store-v1
      Port:    8080
      Weight:  1
    Matches:
      Path:
        Type:   PathPrefix
        Value:  /
    Backend Refs:
      Group:
      Kind:    Service
      Name:    store-v2
      Port:    8080
      Weight:  1
    Matches:
      Headers:
        Name:   env
        Type:   Exact
        Value:  canary
      Path:
        Type:   PathPrefix
        Value:  /
    Backend Refs:
      Group:
      Kind:    Service
      Name:    store-german
      Port:    8080
      Weight:  1
    Matches:
      Path:
        Type:   PathPrefix
        Value:  /de
Status:
  Parents:
    # This section shows the status of this route in relation to each Gateway attached.
    Conditions:
      Last Transition Time:  2022-11-01T05:42:31Z
      Message:
      Reason:                Accepted
      Status:                True # Means that the Gateway has validated and accepted this route's configuration.
      Type:                  Accepted
      Last Transition Time:  2022-11-01T05:43:18Z
      Message:
      Reason:                ReconciliationSucceeded
      Status:                True
      Type:                  Reconciled
    Controller Name:         networking.gke.io/gateway
    Parent Ref:
      Group:  gateway.networking.k8s.io
      Kind:   Gateway
      Name:   external-http
Events:
  Type     Reason  Age    From                   Message
  ----     ------  ----   ----                   -------
  Normal   ADD     2m48s  sc-gateway-controller  default/store-external
  Normal  SYNC  61s (x3 over 2m27s)  sc-gateway-controller  Bind of HTTPRoute "default/store-external" to ParentRef Group:       "gateway.networking.k8s.io",
  ...

Prüfen Sie, ob die HTTPRoute an das Gateway gebunden ist:

kubectl describe gateway external-http

Die Ausgabe sieht in etwa so aus:

Name:         external-http
Namespace:    default
Labels:       <none>
# Multiple lines are omitted here.
Status:
  Addresses:
    Type:   IPAddress
    Value:  34.149.207.45
  Conditions:
    Last Transition Time:  2022-11-01T05:37:21Z
    Message:
    Reason:                Scheduled
    Status:                True
    Type:                  Scheduled
    Last Transition Time:  2022-11-01T05:43:18Z
    Message:
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Listeners:
    Attached Routes:  1
    Conditions:
      Last Transition Time:  2022-11-01T05:43:18Z
      Message:
      Reason:                Ready
      Status:                True
      Type:                  Ready
    Name:                    https
    Supported Kinds:
      Group:  gateway.networking.k8s.io
      Kind:   HTTPRoute
      # Multiple lines are omitted here.

Traffic an die Anwendung senden

Nachdem das Gateway, die Route und die Anwendung in Ihrem Cluster bereitgestellt wurden, können Sie den Traffic an Ihre Anwendung weiterleiten.

Rufen Sie die IP-Adresse des Gateways ab:

kubectl get gateways.gateway.networking.k8s.io external-http -o=jsonpath="{.status.addresses[0].value}"

Die Ausgabe ist eine IP-Adresse.

VM erstellen:
```
gcloud cloud-shell ssh
```
Senden Sie Traffic von der VM an die Gateway-IP-Adresse. Sie müssen den Host-Header manuell festlegen, da Sie nicht Inhaber des Hostnamens example.com sind.
```
curl https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
```
Ersetzen Sie GATEWAY_IP_ADDRESS durch die IP-Adresse des Gateways aus dem vorherigen Schritt.

cacert.pem: die von Ihnen generierte Zertifikatsdatei. Speichern Sie diese Datei auf dem Computer, mit dem Sie eine Verbindung zum Gateway herstellen.

Die Ausgabe zeigt Informationen aus der Demo-App über den Standort, an dem die App ausgeführt wird:
```
{
  "cluster_name": "gke1",
  "host_header": "store.example.com",
  "metadata": "store-v1",
  "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
  "pod_name": "store-v1-84b47c7f58-pmgmk",
  "pod_name_emoji": "💇🏼‍♀️",
  "project_id": "gateway-demo-243723",
  "timestamp": "2022-09-25T13:31:17",
  "zone": "us-central1-a"
}
```

Testen Sie die Pfadübereinstimmung. Rufen Sie dazu die deutsche Version des store-Dienstes unter store.example.com/de auf:

curl https://store.example.com/de --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v

Die Ausgabe bestätigt, dass die Anfrage von einem store-german-Pod bereitgestellt wurde:

{
  "cluster_name": "gke1",
  "host_header": "store.example.com",
  "metadata": "Gutentag!",
  "node_name": "gke-gke1-pool-2-bd121936-n3xn.c.gateway-demo-243723.internal",
  "pod_name": "store-german-5cb6474c55-lq5pl",
  "pod_name_emoji": "🧞‍♀",
  "project_id": "gateway-demo-243723",
  "timestamp": "2022-09-25T13:35:37",
  "zone": "us-central1-a"
}

Senden Sie Traffic mit dem HTTP-Header env: canary an die Canary-Version des Service store:

curl -H "env: canary" https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v

Die Ausgabe bestätigt, dass die Anfrage von einem store-v2-Pod bereitgestellt wurde:

{
  "cluster_name": "gke1",
  "host_header": "store.example.com",
  "metadata": "store-v2",
  "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
  "pod_name": "store-v2-5788476cbd-s9thb",
  "pod_name_emoji": "👩🏿",
  "project_id": "gateway-demo-243723",
  "timestamp": "2022-09-25T13:38:26",
  "zone": "us-central1-a"
}

Regionales externes Gateway bereitstellen

Das folgende Beispiel zeigt, wie Sie eine Speicheranwendung mit mehreren Zertifikaten, die an das regionale externe Gateway angehängt sind, mit selbstverwalteten Zertifikaten und einer HTTPRoute bereitstellen können.

Proxy-Subnetz für Ihr regionales Gateway erstellen

Sie müssen ein Nur-Proxy-Subnetz konfigurieren, bevor Sie ein Gateway erstellen, das einen regionalen externen Application Load Balancer verwendet. Jede Region einer VPC, in der Sie den regionalen externen Application Load Balancer verwenden, muss ein Subnetz external_managed_proxy haben. Dieses Subnetz stellt interne IP-Adressen für die Load Balancer-Proxys bereit.

Zertifikat erstellen, um den Client-Traffic zu sichern

Sie können ein von Ihrer Zertifizierungsstelle ausgestelltes und validiertes Zertifikat verwenden oder ein selbst signiertes Zertifikat erstellen. Weitere Informationen zum Erstellen eines Zertifikats finden Sie unter Zertifikat in einem Kubernetes-Secret speichern.

Sie haben folgende Möglichkeiten, den Traffic zwischen Ihren Clients und Ihrem regionalen Gateway zu sichern:

Von Google verwaltete oder selbstverwaltete Certificate Manager-Zertifikate
Selbstverwaltete regionale SSL-Zertifikate
Kubernetes-Secrets

CertificateMap oder von Google verwaltete SSL-Zertifikate werden nicht von regionalen Gateways unterstützt.

Weitere Informationen finden Sie unter Zertifikate und Google Cloud Load Balancer.

Regionales externes HTTP(S)-Gateway erstellen

Erstellen Sie eine regionale statische IP-Adresse für den externen Load Balancer.
```
gcloud compute addresses create IP_ADDRESS_NAME \
  --region=COMPUTE_REGION \
  --network-tier=STANDARD
```
Ersetzen Sie Folgendes:
- IP_ADDRESS_NAME: der Name der neuen statischen IP-Adresse.
- COMPUTE_REGION: die Compute Engine-Region, in der Ihr Cluster ausgeführt wird.

Erstellen Sie ein Gateway für einen regionalen externen Application Load Balancer mit einem selbstverwalteten Zertifikat und speichern Sie das Manifest als regional-gateway.yaml:

  kind: Gateway
  apiVersion: gateway.networking.k8s.io/v1
  metadata:
    name: external-regional-http
  spec:
    # Name of an existing GatewayClass.
    gatewayClassName: gke-l7-regional-external-managed
    # Listen for HTTPS traffic on port 443
    listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        # Terminate the TLS session with the client at the Gateway.
        mode: Terminate
        # Certificates for the Gateway to use to create a new TLS session.
        certificateRefs:
        - name: store-example-com
    # The name of the static IP address of the external load balancer.
    # You can also use the `IPAddress` type to specify the actual IP address.
    addresses:
    - type: NamedAddress
      value: IP_ADDRESS_NAME

Wenden Sie das regional-gateway-Manifest an:

  kubectl apply -f regional-gateway.yaml

Prüfen Sie die Konfiguration.

  kubectl get gateway

Die Ausgabe sieht in etwa so aus:

NAME            CLASS                              ADDRESS         READY   AGE
external-http   gke-l7-regional-external-managed   35.118.32.224   True    49s

Verwenden Sie einen „describe“-Befehl, um weitere Details zu erhalten:

kubectl describe gateway

Die Ausgabe sieht in etwa so aus:

Name:         external-regional-http
Namespace:    default
Labels:       <none>
...
Spec:
  Gateway Class Name:  gke-l7-regional-external-managed
  Listeners:
    Allowed Routes:
      Namespaces:
        From:  Same
    Name:      https
    Port:      443
    Protocol:  HTTPS
    Tls:
      Certificate Refs:
        Group:
        Kind:   Secret
        Name:   store-example-com
      Mode:     Terminate
  ...

Demoanwendung bereitstellen

Sie können Ihre Anwendungen und Routen unabhängig von der Bereitstellung von Gateways bereitstellen.

Weitere Informationen zum Bereitstellen der Demoanwendungen finden Sie unter Demoanwendungen bereitstellen.

HTTPRoute erstellen

Sie müssen eine HTTPRoute erstellen, um HTTP- und HTTPS-Traffic abzugleichen und zu filtern.

Traffic an die Anwendung senden

Nachdem Sie Ihre Anwendung bereitgestellt und HTTPRoutes erstellt haben, können Sie Traffic an Ihre Anwendung weiterleiten.

Weitere Informationen zum Senden von Traffic an Ihre Anwendung finden Sie unter Traffic an Ihre Anwendung senden.

Gemeinsam genutzte Gateways verwenden

Die Gateway API verwendet separate Ressourcen, Gateways und Routenressourcen, um Load-Balancer und Routingregeln bereitzustellen. Dies unterscheidet sich von Ingress, das alles in einer Ressource enthält. Durch die Aufteilung der Zuständigkeit auf Ressourcen können der Load-Balancer und seine Routingregeln separat und von verschiedenen Nutzern oder Teams bereitgestellt werden. Dadurch können Gateways zu gemeinsamen Gateways werden, die an viele verschiedene Routen angehängt sind. Diese können vollständig unabhängige Teams haben und auch über verschiedene Namespaces hinweg verwaltet werden.

Routen für ein gemeinsam genutztes Gateway bereitstellen

Dieses Beispiel baut auf dem internal-http-Gateway auf, das in Internes Gateway bereitstellen bereitgestellt wurde.

In diesem Beispiel stellt das Site-Team seine Anwendung, Dienste und eine HTTPRoute bereit, um den Traffic vom Gateway diesen Diensten zuzuordnen.

Stellen Sie die Beispielanwendung bereit:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/site.yaml

Speichern Sie folgendes Manifest in einer Datei mit dem Namen site-route-internal.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: site-internal
spec:
  # Attach the HTTPRoute to the `internal-http` Gateway.
  parentRefs:
  - kind: Gateway
    name: internal-http
  # Route requests that have `site.example.com` in the Host header.
  hostnames:
  - "site.example.com"
  # Send all requests to the `site-v1` Service.
  rules:
  - backendRefs:
    - name: site-v1
      port: 8080

Dieses Manifest beschreibt eine HTTPRoute, die mit dem gesamten Traffic für site.example.com übereinstimmt und ihn an den site-v1-Dienst weiterleitet.

Wenden Sie das Manifest auf Ihren Cluster an:

kubectl apply -f site-route-internal.yaml

Prüfen Sie, ob die HTTPRoute mit dem Gateway verbunden ist:

kubectl describe httproute.gateway.networking.k8s.io site-internal

Die Ausgabe sieht in etwa so aus:

Status:
  Parents:
    Conditions:
      Last Transition Time:  2023-01-09T15:05:43Z
      Message:
      Reason:                Accepted
      Status:                True
      Type:                  Accepted
      Last Transition Time:  2023-01-09T15:05:43Z
      Message:
      Reason:                ReconciliationSucceeded
      Status:                True
      Type:                  Reconciled
    Controller Name:         networking.gke.io/gateway
    Parent Ref:
      Group:  gateway.networking.k8s.io
      Kind:   Gateway
      Name:   internal-http
      ...

Wenn die Bedingung Accepted für das Gateway True ist, wurde die HTTPRoute erfolgreich an das Gateway gebunden. Weitere Informationen zum Feld „Status“ finden Sie unter Routenstatus.

Prüfen Sie, ob der Traffic zum Gateway korrekt weitergeleitet wird:

curl -H "host: site.example.com" GATEWAY_IP_ADDRESS
curl -H "host: store.example.com" GATEWAY_IP_ADDRESS

Ersetzen Sie GATEWAY_IP_ADDRESS durch die IP-Adresse des internen Gateways.

Sie müssen eine VM im selben VPC-Netzwerk wie das Gateway verwenden.

Die Ausgabe sieht etwa so aus:

{
  "cluster_name": "CLUSTER_NAME",
  "host_header": "site.example.com",
  "metadata": "site-v1",
  "pod_name": "site-v1-5d64fc4d7d-fz6f6",
  "pod_name_emoji": "👩🏼‍🍳",
  "project_id": "PROJECT_ID",
  "timestamp": "2022-11-02T19:07:01",
  "zone": "ZONE_NAME"
}
...
{
  "cluster_name": "CLUSTER_NAME",
  "host_header": "store.example.com",
  "metadata": "store-v1",
  "pod_name": "store-v1-6d8d58d78-vz8pn",
  "pod_name_emoji": "🧝🏻‍♂️",
  "project_id": "PROJECT_ID",
  "timestamp": "2022-11-02T19:07:01",
  "zone": "ZONE_NAME"
}

Diese Ausgabe gibt an, dass Anfragen mit dem Host-Header site.example.com den Dienst site-v1 erreichen, während Anfragen mit dem Host-Header store.example.com den Dienst store-v1 erreichen.

Netzwerkstufe konfigurieren

Sie können die Netzwerkstufe für die Listener-Adresse eines regionalen externen Application Load Balancers mit dem Feld type im Array addresses[] in der Gateway-Definition angeben. Wenn Sie keine Netzwerkstufe angeben, verwendet das Gateway standardmäßig eine sitzungsspezifische IP-Adresse der Standardstufe.

Verwenden Sie die folgenden Werte für das Feld type:

networking.gke.io/premium-ephemeral-ipv4-address: weist eine IP-Adresse der Premium-Stufe zu.
networking.gke.io/standard-ephemeral-ipv4-address: weist eine IP-Adresse des Standard-Tarifs zu.

Wenn Sie IP-Adressen aus beiden Netzwerkstufen zuweisen möchten, geben Sie beide Typen im Feld addresses an.

Das folgende Beispiel zeigt, wie Sie einem Gateway eine IP-Adresse der Premium-Stufe zuweisen. Google Cloud Verwenden Sie networking.gke.io/standard-ephemeral-ipv4-address, um eine IP-Adresse der Standardstufe bereitzustellen.

Speichern Sie das folgende Beispielmanifest als external-regional-http.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-regional-http
spec:
  # Name of an existing GatewayClass.
  gatewayClassName: gke-l7-regional-external-managed
  # Listen for HTTPS traffic on port 443.
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      # Terminate the TLS session with the client at the Gateway.
      mode: Terminate
      # Certificates for the Gateway to use to create a new TLS session.
      certificateRefs:
      - name: store-example-com
    addresses:
    # Request a Premium Tier ephemeral IPv4 address for the Gateway.
    - type: networking.gke.io/premium-ephemeral-ipv4-address

Wenden Sie das Beispielmanifest an:

kubectl apply -f external-regional-http.yaml

Gateway-Standard-Backend konfigurieren

Alle gke-l7-*-Gateway-Klassen geben HTTP 404 an nicht übereinstimmenden Traffic zurück. Sie können das Standard-Backend mithilfe einer expliziten Standardroute konfigurieren, die nicht übereinstimmenden Traffic an einen vom Nutzer bereitgestellten Dienst sendet.

Gateways sind so konfiguriert, dass sie Fehlercodes wie 404 (Nicht gefunden) und 500 (Serverfehler) auch ohne explizite Backend-Definitionen verarbeiten können. Das Standardverhalten kann je nach Gateway-Implementierung variieren. Wenn Sie mehr Kontrolle über die Fehlerbehandlung haben möchten, können Sie benutzerdefinierte Back-Ends konfigurieren.

Die folgende HTTPRoute ist ein Beispiel dafür, wie das Standard-Backend angepasst werden kann. Wenn Sie eine HTTPRoute ähnlich der folgenden anwenden, hat sie Vorrang vor dem impliziten Standard-Backend:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: custom-default-backend
spec:
  parentRefs:
  - kind: Gateway
    name: my-internal-gateway
  # Omit the `hostnames` field to route all unmatched traffic from the
  # attached Gateway.
  rules:
  - backendRefs:
    - name: my-custom-default-backend-service
      port: 8080

Diese HTTPRoute stimmt mit dem gesamten Traffic von einem bestimmten Gateway überein. Für jedes Gateway kann nur eine solche Regel gelten. Andernfalls stehen die Regeln in Konflikt und die Prioritätsreihenfolge gilt.

Sie können ein Standard-Backend verwenden, um zu verhindern, dass jemand ein Standardrouten-Backend erstellt, das den gesamten Gateway-Traffic weiterleitet. Eine explizite HTTPRoute hat immer Vorrang vor neuen HTTPRoutes mit in Konflikt stehenden Routingregeln.

Statische IP-Adresse für ein Gateway konfigurieren

Jedes Gateway hat eine IP-Adresse, die Traffic überwacht. Wenn Sie keine IP-Adresse für das Gateway angeben, stellt der Gateway-Controller automatisch eine IP-Adresse bereit. Sie können auch eine statische IP-Adresse erstellen, damit die IP-Adresse unabhängig vom Gateway-Lebenszyklus vorhanden ist.

Nachdem ein Gateway bereitgestellt wurde, wird seine IP-Adresse im Statusfeld angezeigt:

kind: Gateway
...
status:
  addresses:
    - value: 10.15.32.3

Abhängig von der GatewayClass wird die IP-Adresse aus den folgenden Subnetzen zugewiesen:

GatewayClasses	Standard-IP-Adresspool
gke-l7-rilb gke-l7-rilb-mc	Regionale private IP-Adressen aus dem primären IPv4-/IPv6-Adressbereich des Knotens
gke-l7-regional-external-managed gke-l7-regional-external-managed-mc	Regionale öffentliche IP-Adressen aus den regionalen externen IPv4-/IPv6-Bereichen von Google
gke-l7-global-external-managed gke-l7-global-external-managed-mc gke-l7-gxlb gke-l7-gxlb-mc	Globale öffentliche IP-Adressen aus den globalen externen IPv4-/IPv6-Bereichen von Google

Im Feld addresses.NamedAddress können Sie eine IP-Adresse unabhängig vom Gateway angeben. Sie können vor der Bereitstellung des Gateways eine statische IP-Adressressource erstellen, auf die von NamedAddress verwiesen wird. Sie können die statische IP-Adresse wiederverwenden, auch wenn das Gateway gelöscht wird.

Benannte IP-Adresse verwenden

Sie können eine IPv4- oder IPv6-Adresse konfigurieren, indem Sie eine NamedAddress angeben. Sie müssen eine statische IP-Adresse bereitstellen, bevor Sie ein Gateway erstellen.

Erstellen Sie eine statische IP-Adressressource:
```
gcloud compute addresses create IP_ADDRESS_NAME \
    --purpose=SHARED_LOADBALANCER_VIP \
    --region=COMPUTE_REGION \
    --subnet=SUBNET \
    --project=PROJECT_ID
```
Ersetzen Sie Folgendes:
- IP_ADDRESS_NAME: der Name der neuen statischen IP-Adresse.
- COMPUTE_REGION: Bei regionalen Gateways die Compute Engine-Region, in der Ihr Cluster ausgeführt wird. Dieses Flag ist für globale, externe Gateways nicht erforderlich.
- SUBNET: das Subnetz für die IP-Adresse. Dieses Flag ist für globale, externe Gateways nicht erforderlich.
- PROJECT_ID: das Projekt, in dem Ihr GKE-Cluster ausgeführt wird.

Speichern Sie folgendes Manifest in einer Datei mit dem Namen named-ip-gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: internal-http
spec:
  gatewayClassName: gke-l7-rilb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
  addresses:
  - type: NamedAddress
    value: IP_ADDRESS_NAME

Dieses Manifest beschreibt ein Gateway, das auf die benannte IP-Adresse verweist.

Wenden Sie das Manifest auf Ihren Cluster an:
```
kubectl apply -f named-ip-gateway.yaml
```

IP-Adresse des Gateways prüfen:

kubectl describe gateway internal-http

Die Ausgabe sieht in etwa so aus:

Name:         internal-http
Namespace:    default
Labels:       <none>
...
Spec:
  Addresses:
    Type:              NamedAddress
    Value:             IP_ADDRESS_NAME
  Gateway Class Name:  gke-l7-rilb
  Listeners:
    Allowed Routes:
      Namespaces:
        From:  Same
    Name:      http
    Port:      80
    Protocol:  HTTP
Status:
  Addresses:
    Type:   IPAddress
    Value:  10.15.32.103

HTTP-zu-HTTPS-Weiterleitungen konfigurieren

Cloud Load Balancing bietet HTTP-zu-HTTPS-Weiterleitungsfunktionen. Ein externer Anwendungs-Load-Balancer leitet unverschlüsselte HTTP-Anfragen an einen HTTPS-Load-Balancer weiter, der dieselbe IP-Adresse verwendet. Wenn Sie ein Gateway mit aktivierten HTTP-zu-HTTPS-Weiterleitungen erstellen, werden beide Load-Balancer automatisch erstellt. Anfragen an die externe IP-Adresse des Gateways an Port 80 werden automatisch an dieselbe externe IP-Adresse an Port 443 umgeleitet.

Standardmäßig sind HTTP-zu-HTTPS-Weiterleitungen nicht auf dem Gateway definiert.

Konfigurieren Sie ein Gateway für die Verarbeitung von HTTP- und HTTPS-Traffic, um HTTP-Traffic an HTTPS weiterzuleiten. Wenn Sie HTTP oder HTTPS deaktivieren, leitet das Gateway den Traffic nicht weiter.

Die folgenden Beispiele zeigen, wie Sie die HTTP-zu-HTTPS-Weiterleitung verwenden, damit der Traffic von Ihren Clients, die Ihre Webanwendungen aufrufen, immer an eine sichere Seite weitergeleitet wird.

HTTP-zu-HTTPS-Weiterleitungen werden bei den GatewayClasses gke-l7-gxlb und gke-l7-gxlb-mc nicht unterstützt. Weitere Informationen zu den verschiedenen Features, die mit jeder GatewayClass unterstützt werden, finden Sie unter GatewayClass-Funktionen.

HTTP-Traffic von einem Infrastruktur-Namespace weiterleiten

In einigen Fällen gibt es keinen klaren Unterschied zwischen dem Infrastruktur- oder Plattformadministratorteam und den Anwendungsteams. Die Verhinderung des Missbrauchs des Gateways kann zu einer Herausforderung werden.

Im folgenden Beispiel wird die Verwendung des HTTP-Listeners weiter eingeschränkt, um eine unbeabsichtigte Verwendung eines nicht sicheren Protokolls durch die Anwendungsteams zu verhindern. In diesem Beispiel wird das Gateway so konfiguriert, dass eine HTTPRoute den HTTP-Listener nur verwenden kann, wenn sich die Route in einem Namespace mit dem Label otherInfra: httpToHttps befindet. Das Gateway erlaubt jedoch, dass HTTPRoutes in einem beliebigen Namespace den HTTPS-Listener verwenden. Sie können den Namespace mit http-Weiterleitung mithilfe von Kubernetes RBAC einschränken, sodass Anwendungsteams in diesem Namespace nicht aus Versehen eine HTTPRoute erstellen können.

Erstellen Sie den Namespace eines Gateways. Speichern Sie das Manifest als gateway-namespace.yaml:
```
apiVersion: v1
kind: Namespace
metadata:
  name: gateway-infra
```

Wenden Sie das Manifest an:

kubectl apply -f gateway-namespace.yaml

Erstellen Sie den Namespace eines Gateways und speichern Sie das Manifest als redirect-namespace.yaml:
```
apiVersion: v1
kind: Namespace
metadata:
  name: http-redirect
  labels:
    otherInfra: httpToHttps
```
Dieser http-redirect-Namespace hat das Label otherInfra: httpToHttps.

Wenden Sie das Manifest an:

kubectl apply -f redirect-namespace.yaml

Erstellen Sie mit dem folgenden Manifest ein Gateway, um die HTTP-Listener-Nutzung einzuschränken. Speichern Sie das Manifest als external-gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http
  namespace: gateway-infra
spec:
  # Name of an existing GatewayClass.
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    #  Allow only HTTPRoutes from namespaces that have the
    # `otherInfra: httpToHttps` label to use this listener.
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
      namespaces:
        from: Selector
        selector:
          matchLabels:
            otherInfra: httpToHttps
  - name: https
    protocol: HTTPS
    port: 443
    # Allow HTTPRoutes from any namespace to use this listener.
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
      namespaces:
        from: All
    tls:
      mode: Terminate
      options:
        networking.gke.io/pre-shared-certs: store-example-com

Das Feld namespace gibt an, dass das Gateway im Namespace gateway-infra erstellt wird.
Das Feld namespaces unter allowedRoutes beschränkt den HTTP-Listener auf den Namespace, der mit dem Label otherInfra: httpToHttps übereinstimmt.

Wenden Sie das Manifest an:
```
kubectl apply -f external-gateway.yaml
```

Erstellen Sie mit dem folgenden Manifest eine Standard-HTTPRoute, um die HTTPS-Weiterleitung zu erzwingen. Speichern Sie das Manifest als http-redirect.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: redirect
  # Create the HTTPRoute in the `http-redirect` namespace.
  namespace: http-redirect
spec:
  # Attach the HTTPRoute to the `http` listener in the `external-http`
  # Gateway.
  parentRefs:
  - namespace: gateway-infra
    name: external-http
    sectionName: http
  rules:
  # Respond to the request with an HTTPS redirection.
  - filters:
    - type: RequestRedirect
      requestRedirect:
        scheme: https

Das Feld sectionName weist das Gateway an, nur auf dem HTTP-Listener abzugleichen. Der Filter RequestRedirect erzwingt die Weiterleitung zum HTTPS-Listener.

Wenden Sie das Manifest an:
```
kubectl apply -f http-redirect.yaml
```

Erstellen Sie mit dem folgenden Manifest einen Service für eine Anwendung. Speichern Sie das Manifest als service-deployment.yaml:

apiVersion: v1
kind: Service
metadata:
  name: store-v1
spec:
  selector:
    app: store
    version: v1
  ports:
  - port: 8080
    targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: store-v1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: store
      version: v1
  template:
    metadata:
      labels:
        app: store
        version: v1
    spec:
      containers:
      - name: whereami
        image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
        ports:
        - containerPort: 8080
        env:
        - name: METADATA
          value: "store-v1"

Wenden Sie das Manifest an:

kubectl apply -f service-deployment.yaml

Erstellen Sie eine HTTPRoute für eine Anwendung, die nur HTTPS mit dem folgenden Manifest zulässt. Speichern Sie das Manifest als http-route.yaml:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-external
  labels:
    gateway: external-http
spec:
  # Attach the HTTPRoute to the HTTPS listener in the `external-http`
  # Gateway.
  parentRefs:
  - name: external-http
    namespace: gateway-infra
    sectionName: https
  # Match requests that have the `store.example.com` Host header.
  hostnames:
  - "store.example.com"
  # Route requests to the `store-v1` Service.
  rules:
  - backendRefs:
    - name: store-v1
      port: 8080

Wenden Sie das Manifest an:
```
kubectl apply -f http-route.yaml
```

Pfadweiterleitungen und URL-Umschreibungen konfigurieren

Bei Pfadweiterleitungen wird eine eingehende Anfrage von einem URL-Pfad zu einem anderen weitergeleitet. Mit Pfadweiterleitungen können Sie die Struktur der URL ändern, wenn Sie veraltete oder eingestellte URLs verarbeiten müssen.

Mit URL-Rewrites können Sie die eingehende URL ändern, bevor sie auf dem Server verarbeitet wird. Sie können die Struktur oder das Format der URL ändern, ohne tatsächlich die zugrunde liegenden Inhalte oder die Dateistruktur zu ändern. URL-Umschreibung ist nützlich, um nutzerfreundliche und SEO-freundliche URLs zu erstellen, die leicht zu merken und zu verstehen sind. Standardmäßig sind keine Pfadweiterleitungen und URL-Umschreibungen konfiguriert. Sie müssen diese Weiterleitungen oder Umschreibungen explizit mithilfe eines Filters in Ihrer HTTPRoute konfigurieren.

GKE Gateway unterstützt Pfadweiterleitungen und das Umschreiben von URLs. Weitere Informationen finden Sie unter HTTP-Pfadweiterleitungen und -Umschreibungen.

Pfadweiterleitungen konfigurieren

Sie können Pfadweiterleitungen so konfigurieren, dass entweder der gesamte Pfad oder nur ein Präfix in der URL ersetzt wird.

Gesamten Pfad ersetzen

Um einen gesamten Pfad zu ersetzen, konfigurieren Sie einen Filter in einer HTTPRoute, der jede URL ersetzt, die das Präfix /any-path im URL-Pfad enthält, durch den strikten Wert /new-path.

Erstellen Sie ein HTTPRoute-Manifest und nennen Sie es store.yaml:

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
    - kind: Gateway
      name: external-http
    hostnames:
    - store.example.com
    rules:
    - matches:
      - path:
          # Match requests by a prefix, like `/any-path` and `/any-path/home`.
          type: PathPrefix
          value: /any-path
      filters:
      - type: RequestRedirect
        requestRedirect:
          path:
            # Replace the full path with `/new-path`. For example, both
            # `/any-path/home` and `/any-path` become `/new-path`.
            type: ReplaceFullPath
            replaceFullPath: /new-path
          statusCode: 302

Dieses Manifest legt beispielsweise eine Routingregel für eine HTTPRoute fest: Jede Route zur URL https://store.example.com/any-path/... muss zu einem neuen Speicherort weitergeleitet werden: https://store.example.com/new-path/ (strikt).

Wenden Sie das Manifest an:
```
kubectl apply -f store.yaml
```

Diese Routingregel folgt einer strengen Weiterleitungsregel. Das bedeutet, dass der Browser nicht versucht, die Weiterleitung zu cachen, sondern zur neuesten Version weiterleitet.

Nur ein Präfix ersetzen

Um nur ein Präfix zu ersetzen, konfigurieren Sie einen Filter in einer HTTPRoute, der jede URL ersetzt, die das Präfix /any-prefix im URL-Pfad enthält, durch den strikten Wert /new-prefix.

Erstellen Sie ein HTTPRoute-Manifest und nennen Sie es store.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: store
spec:
  parentRefs:
    - kind: Gateway
      name: external-http
  hostnames:
  - store.example.com
  rules:
  - matches:
      - path:
          # Match requests by prefix, like `/any-prefix` and
          # `/any-prefix/home`.
          type: PathPrefix
          value: /any-prefix
    filters:
    - type: RequestRedirect
      requestRedirect:
        path:
          # Replace the matched prefix with `/new-prefix`. For example,
          # `/any-prefix` becomes `/new-prefix` and `/any-prefix/home`
          # becomes `/new-prefix/home`.
          type: ReplacePrefixMatch
          replacePrefixMatch: /new-prefix
        statusCode: 302

Dieses Manifest legt beispielsweise eine Routingregel für eine HTTPRoute fest: Jede Route zur URL https://store.example.com/any-path/v1/... muss zu einem neuen Speicherort weitergeleitet werden: https://store.example.com/new-path/v1/... (nur).

Wenden Sie das Manifest an:
```
  kubectl apply -f store.yaml
```

Diese Weiterleitungsregel folgt der einzigen Weiterleitungsregel, die dafür sorgt, dass der Browser Sie immer zur selben gewünschten Seite weiterleitet.

URL-Umschreibungen konfigurieren

Mit URL-Rewrites können Sie ändern, wie eine URL für Nutzer angezeigt wird. Mit URL-Umschreibungen können Sie URLs nutzerfreundlicher machen, die SEO verbessern oder Nutzer auf eine neue Seite weiterleiten.

Gesamten Hostnamen umschreiben

So schreiben Sie den gesamten Hostnamen um:

Konfigurieren Sie einen Filter in einer HTTPRoute, der das Gateway anweist, die Host-Informationen im Anfrageheader von www.example.com durch store.example.com zu ersetzen, bevor die Anfrage an den Backend-Dienst weitergeleitet wird.

Erstellen Sie ein HTTPRoute-Manifest und nennen Sie es www.yaml:

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: www
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - www.example.com
    rules:
    - filters:
      - type: URLRewrite
        # Replace the hostname in the URL with `store.example.com`.
        urlRewrite:
          hostname: store.example.com
      backendRefs:
      - name: store-v1
        port: 8080

Zum Beispiel wird bei der obigen Konfiguration jede Anfrage an https://www.example.com an den Backend-Dienst mit dem Host: store.example.com-Header anstelle von Host: www.example.com weitergeleitet.

Wenden Sie das Manifest an:
```
  kubectl apply -f www.yaml
```

Mit Pfadmodifikatoren umschreiben

Sie können das Umschreiben mit Pfadmodifikatoren kombinieren, um erweiterte URL- und Pfadänderungen vorzunehmen, bevor die Anfrage an den Backend-Dienst weitergeleitet wird.

So schreiben Sie mit Pfadmodifikatoren um:

Konfigurieren Sie einen Filter in einer HTTPRoute, der das Gateway anweist, die „Host“-Informationen im Anfrageheader von www.example.comto store.example.com zu ersetzen und den Wert /store durch / zu ersetzen, bevor die Anfrage an den Backend-Dienst weitergeleitet wird.

Erstellen Sie ein HTTPRoute-Manifest und nennen Sie es www.yaml:

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: www
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - www.example.com
    rules:
    - matches:
      - path:
          type: PathPrefix
          value: /store
      filters:
      - type: URLRewrite
        # For URLs that have `/store` in the path, replace the hostname with
        # store.example.com and replace the `/store` prefix with `/de`.
        urlRewrite:
          hostname: store.example.com
          path:
            type: ReplacePrefixMatch
            replacePrefixMatch: /de
      backendRefs:
      - name: store-german
        port: 8080

Mit der obigen Konfiguration wird zum Beispiel jede Anfrage an https://www.example.com/store/... an den Backend-Dienst mit Host: store.example.com im Anfrageheader (anstelle von Host: www.example.com) weitergeleitet und /store wird in /de umgeschrieben.

Wenden Sie das Manifest an:
```
kubectl apply -f www.yaml
```

Konfiguration überprüfen

So prüfen Sie, ob der Filter angewendet wurde, nachdem Sie Ihre HTTPRoute mit Filtern für das Umschreiben von URLs oder Pfadweiterleitungen erstellt haben:

kubectl get httproute www -o yaml

Die Ausgabe sieht in etwa so aus:

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"gateway.networking.k8s.io/v1","kind":"HTTPRoute","metadata":{"annotations":{},"name":"www","namespace":"default"},"spec":{"hostnames":["www.example.com"],"parentRefs":[{"kind":"Gateway","name":"external-http"}],"rules":[{"backendRefs":[{"name":"store-german","port":8080}],"filters":[{"type":"URLRewrite","urlRewrite":{"hostname":"store.example.com","path":{"replacePrefixMatch":"/de","type":"ReplacePrefixMatch"}}}],"matches":[{"path":{"type":"PathPrefix","value":"/store"}}]}]}}
    creationTimestamp: "2023-06-22T01:00:42Z"
    generation: 3
    name: www
    namespace: default
    resourceVersion: "51268631"
    uid: e516493e-806d-44d6-ae0d-1c9ff25682cf
  spec:
    hostnames:
    - www.example.com
    parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: external-http
    rules:
    - backendRefs:
      - group: ""
        kind: Service
        name: store-german
        port: 8080
        weight: 1
      filters:
      - type: URLRewrite
        urlRewrite:
          hostname: store.example.com
          path:
            replacePrefixMatch: /de
            type: ReplacePrefixMatch
      matches:
      - path:
          type: PathPrefix
          value: /store
  status:
    parents:
    - conditions:
      - lastTransitionTime: "2023-06-22T01:11:26Z"
        message: ""
        observedGeneration: 2
        reason: Accepted
        status: "True"
        type: Accepted
      - lastTransitionTime: "2023-06-22T01:11:26Z"
        message: ""
        observedGeneration: 2
        reason: ReconciliationSucceeded
        status: "True"
        type: Reconciled
      controllerName: networking.gke.io/gateway
      parentRef:
        group: gateway.networking.k8s.io
        kind: Gateway
        name: external-http

Verwenden Sie den „describe“-Befehl, um weitere Details zu erhalten:

kubectl describe httproute

Benutzerdefinierte Anfrage- und Antwortheader konfigurieren

Mit benutzerdefinierten Anfrage- und Antwortheadern können Sie zusätzliche Header für HTTP(S)-Anfragen und -Antworten angeben. Abhängig von den vom Load Balancer erkannten Informationen können diese Header die folgenden Informationen enthalten:

Latenz zum Client
Geografischer Standort der IP-Adresse des Clients
Parameter der TLS-Verbindung

Standardmäßig werden der an/von Ihren Backend-Diensten gesendeten/empfangenen Anfrage keine benutzerdefinierten Header hinzugefügt. Sie müssen benutzerdefinierte Header mithilfe eines Filters in Ihrer HTTPRoute explizit konfigurieren.

Sie können benutzerdefinierte Header konfigurieren, indem Sie den Regeln Ihrer HTTPRoute einen Filterabschnitt hinzufügen:

Benutzerdefinierte Anfrageheader konfigurieren

Erstellen Sie ein HTTPRoute-Manifest mit einem RequestHeaderModifier-Filter und speichern Sie es als http-route-request.yaml:.

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    <...>
    rules:
        filters:
          - type: RequestHeaderModifier
            requestHeaderModifier:
              <...>

Wenden Sie das Manifest an:

  kubectl apply -f http-route-request.yaml

Benutzerdefinierte Antwortheader konfigurieren

Erstellen Sie ein HTTPRoute-Manifest mit einem ResponseHeaderModifier-Filter und speichern Sie es als http-route-response.yaml:.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: store
spec:
  <...>
  rules:
      filters:
        - type: ResponseHeaderModifier
          responseHeaderModifier:
            <...>

Wenden Sie das Manifest an:

  kubectl apply -f http-route-response.yaml

Sie können Header hinzufügen, festlegen und entfernen, wie in der Gateway API-Implementierung beschrieben. Sie können Ihre HTTPRoute mit einem benutzerdefinierten Header konfigurieren, indem Sie die von Google Cloud unterstützten Variablen verwenden.

Beispiel 1:

Um eine HTTPRoute zu konfigurieren, die der HTTP-Anfrage Clientstandortinformationen hinzufügt, bevor sie an den Backend-Dienst gesendet wird, erstellen Sie ein HTTPRoute-Manifest und nennen Sie es external-http-request.yaml:

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /fr
        filters:
          # Add custom headers to requests that have `/fr` in the path.
          - type: RequestHeaderModifier
            requestHeaderModifier:
              add:
                - name: X-Client-Geo-Location
                  value: "{client_region},{client_city}"
        backendRefs:
          - name: store-french
            port: 8080

Beispielsweise fügt das Gateway für Kunden in Strasbourg in Frankreich einen Header als X-Client-Geo-Location:FR,Strasbourg hinzu.

Beispiel 2:

Um eine HTTPRoute zu konfigurieren, die einen benutzerdefinierten Antwortheader hinzufügt, um HTTP Strict Transport Security zu unterstützen, erstellen Sie ein HTTPRoute-Manifest und nennen Sie es external-http-response.yaml:

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /de
        filters:
          # Add custom headers to responses to requests that have `/de` in the
          # path.
          - type: ResponseHeaderModifier
            responseHeaderModifier:
              add:
                - name: Strict-Transport-Security
                  value: max-age=63072000
        backendRefs:
          - name: store-german
            port: 8080

Konfiguration überprüfen

So prüfen Sie Ihre Konfiguration nach der Einrichtung einer benutzerdefinierten Anfrage und eines Antwortheaders:
```
  kubectl get httproute
```
Die Ausgabe sieht in etwa so aus:
```
  NAME    HOSTNAMES               AGE
  store   ["store.example.com"]   4d23h
```

Verwenden Sie den „describe“-Befehl, um weitere Details zu erhalten:

  kubectl describe httproute

Die Ausgabe sieht in etwa so aus:

  Name:         store
  Namespace:    default
  Labels:       <none>
  Annotations:  <none>
  API Version:  gateway.networking.k8s.io/v1
  Kind:         HTTPRoute
  Metadata:
    Creation Timestamp:  2023-05-27T00:51:01Z
    Generation:          5
    Resource Version:    25418887
    UID:                 2e07a1b8-420b-41b4-acd1-cecbfcd39f42
  Spec:
    Hostnames:
      store.example.com
    Parent Refs:
      Group:  gateway.networking.k8s.io
      Kind:   Gateway
      Name:   external-http
    Rules:
      Backend Refs:
        Group:
        Kind:    Service
        Name:    store-v1
        Port:    8080
        Weight:  1
      Matches:
        Path:
          Type:   PathPrefix
          Value:  /
      Backend Refs:
        Group:
        Kind:    Service
        Name:    store-v2
        Port:    8080
        Weight:  1
      Matches:
        Headers:
          Name:   env
          Type:   Exact
          Value:  canary
        Path:
          Type:   PathPrefix
          Value:  /
      Backend Refs:
        Group:
        Kind:    Service
        Name:    store-german
        Port:    8080
        Weight:  1
      Filters:
        Request Header Modifier:
          Add:
            Name:   X-Client-Geo-Location
            Value:  {client_region},{client_city}
        Type:       RequestHeaderModifier
      Matches:
        Path:
          Type:   PathPrefix
          Value:  /de
  Status:
    <...>

Routenstatus

HTTPRoute-Ressourcen geben Bedingungen und Ereignisse aus, damit Nutzer nachvollziehen können, ob eine HTTPRoute erfolgreich mit einem oder mehreren Gateways verbunden wurde oder ob sie abgelehnt wurde.

HTTPRoute-Bedingungen

HTTPRoute-Bedingungen geben den Status der Route und der Gateways an, an die sie gebunden ist. Da eine Route an mehrere Gateways gebunden werden kann, ist dies eine Liste von Gateways und der jeweiligen Bedingungen zwischen der Route und den einzelnen Gateways.

Accepted=True gibt an, dass die HTTPRoute erfolgreich an ein Gateway gebunden wurde.
Accepted=False gibt an, dass die Bindung der HTTPRoute an dieses Gateway abgelehnt wurde.

Wenn unter der Überschrift Gateway bindings keine Gateways aufgeführt sind, stimmen Ihre HTTPRoute-Labels und Gateway-Selektoren möglicherweise nicht überein. Das kann passieren, wenn Ihre Route von keinem Gateway ausgewählt wird.

HTTPRoute-Ereignisse

HTTPRoute-Ereignisse enthalten Details zum Status der HTTPRoute. Ereignisse werden nach folgenden Gründen gruppiert:

ADD-Ereignisse werden durch eine hinzugefügte Ressource ausgelöst.
UPDATE-Ereignisse werden durch eine aktualisierte Ressource ausgelöst.
SYNC-Ereignisse werden durch den regelmäßigen Abgleich ausgelöst.

Zusammenführung, Priorisierung und Validierung von Routen

Routenvorrang

In der Gateway API werden strenge Vorrangsregeln für den Abgleich von Traffic mit Routen definiert, deren Routingregeln sich überschneiden. Der Vorrang zwischen zwei überlappenden HTTPRoutes sieht so aus:

Zusammenführung von Hostnamen: Der längste bzw. spezifischste Hostname-Abgleich.
Pfadzusammenführung: Der längste bzw. spezifischste Pfadabgleich.
Header-Zusammenführung: Die größte Anzahl der übereinstimmenden HTTP-Header.
Konflikt: Wenn anhand der vorherigen drei Regeln keine Priorität festgelegt werden kann, hat die HTTPRoute-Ressource mit dem ältesten Zeitstempel Vorrang.

Routenzusammenführung

Bei gke-l7-GatewayClasses werden alle HTTP-Routen für ein Gateway in derselben URL-Zuordnungsressource zusammengeführt. Wie die HTTPRoutes zusammengeführt werden, hängt vom Typ der Überschneidung zwischen HTTPRoutes ab. Die HTTPRoute aus dem vorherigen Beispiel kann zur Veranschaulichung der Routenzusammenführung und des -vorrangs in drei separate HTTPRoutes aufgeteilt werden:

Routenzusammenführung: Alle drei HTTPRoutes werden an dasselbe internal-http-Gateway angehängt und somit zusammengeführt.
Hostnamenzusammenführung: Alle drei Routen stimmen mit store.example.com überein, sodass ihre Hostnamenregeln zusammengeführt werden.
Pfadzusammenführung: store-german-route hat einen spezifischeren Pfad /de, also wird sie nicht weiter zusammengeführt. store-v1-route und store-v2-route haben beide denselben /*-Pfad, daher werden sie im Pfad zusammengeführt.
Header-Zusammenführung: „store-v2-route“ beinhaltet einen spezifischeren Satz von HTTP-Header-Übereinstimmungen als „store-v1-route“, sodass sie nicht weiter zusammengeführt werden.
Konflikt: Da die Routen in Hostname, Pfad und Header zusammengeführt werden können, gibt es keine Konflikte. Alle Routingregeln werden auf den Traffic angewendet.

Die im vorherigen Beispiel verwendete einzelne HTTPRoute entspricht diesen drei separaten Routen:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-v1-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - kind: Service
      name: store-v1
      port: 8080
---
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-v2-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - headers:
      - type: Exact
        name: env
        value: canary
    backendRefs:
    - kind: Service
      name: store-v2
      port: 8080
---
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-german-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /de
    backendRefs:
    - kind: Service
      name: store-german
      port: 8080

Kubernetes-Gateways und Istio-Gateways

Die Kubernetes Gateway API und die Istio API haben beide eine Ressource mit dem Namen Gateway. Obwohl sie ähnliche Funktionen ausführen, sind sie nicht dieselbe Ressource. Wenn Sie Istio und die Gateway API im selben Kubernetes-Cluster verwenden, überschneiden sich diese Namen bei der Verwendung von kubectl in der Befehlszeile. kubectl get gateway könnte die Kubernetes-Gateway-Ressourcen und nicht die Istio-Gateway-Ressourcen zurückgeben und umgekehrt.

$ kubectl api-resources
NAME       SHORTNAMES   APIGROUP                       NAMESPACED   KIND
gateways   gw           networking.istio.io/v1beta1    true         Gateway
gateways   gtw          networking.k8s.io/v1beta1      true         Gateway

Wenn Sie Istio verwenden und ein Upgrade auf GKE 1.20 oder höher durchführen, wird empfohlen, mit dem Kurznamen der Gateway-Ressource zu beginnen oder die API-Gruppe anzugeben. Der Kurzname für ein Kubernetes-Gateway ist gtw und der Kurzname für ein Istio-Gateway gw. Die folgenden Befehle geben das Kubernetes-Gateway bzw. das Istio-Gateway zurück.

# Kubernetes Gateway
$ kubectl get gtw
NAME                        CLASS
multi-cluster-gateway       gke-l7-global-external-managed-mc

$ kubectl get gateway.networking.x-k8s.io
NAME                        CLASS
multi-cluster-gateway       gke-l7-global-external-managed-mc

# Istio Gateway
$ kubectl get gw
NAME               AGE
bookinfo-gateway   64m

$ kubectl get gateway.networking.istio.io
NAME               AGE
bookinfo-gateway   64m

Fehlerbehebung

Nur-Proxy-Subnetz in der Region fehlt

Symptom:

Das folgende Problem kann auftreten, wenn Sie ein regionales Gateway (intern oder extern) erstellen:

generic::invalid_argument: error ensuring load balancer: Insert: Invalid value for field 'resource.target': 'regions/[REGION_NAME]/targetHttpProxies/gkegw-x5vt-default-internal-http-[ID]'. A reserved managed proxy subnetwork with purpose REGIONAL_MANAGED_PROXY is required.

Grund:

Diese Fehlermeldung weist darauf hin, dass in der Region für Ihr Gateway kein Nur-Proxy-Subnetz vorhanden ist.

Workaround:

Stellen Sie ein Nur-Proxy-Subnetz bereit, um dieses Problem zu beheben.

Nur-Proxy-Subnetz ist in der Region mit dem falschen Zweck bereits vorhanden

Symptom:

Das folgende Problem kann auftreten, wenn Sie ein Nur-Proxy-Subnetz für Ihr regionales Gateway (intern oder extern) erstellen:

ERROR: (gcloud.compute.networks.subnets.create) Could not fetch resource:
 - The resource 'projects/[PROJECT_NAME]/regions/[REGION_NAME]/subnetworks/[PROXY_ONLY_SUBNET_NAME]' already exists

Grund:

Diese Fehlermeldung weist darauf hin, dass Sie versucht haben, ein regionales Nur-Proxy-Subnetz in einer Region zu erstellen, in der bereits ein Nur-Proxy-Subnetz vorhanden ist.

Workaround:

Mit den folgenden Schritten können Sie dieses Problem beheben:

Prüfen Sie, ob in der Region bereits ein Nur-Proxy-Subnetz vorhanden ist, und ob es den richtigen Zweck hat:
1. Listen Sie Ihre Subnetze auf, um herauszufinden, welches das Nur-Proxy-Subnetz in der Region ist:
```
gcloud compute networks subnets list --regions=COMPUTE_REGION
```
  Ersetzen Sie COMPUTE_REGION durch die Compute Engine-Region, in der Sie das regionale Gateway erstellen möchten.
2. Beschreiben Sie Ihr Nur-Proxy-Subnetz in der Region, um den Zweck zu ermitteln:
```
gcloud compute networks subnets describe PROXY_ONLY_SUBNET \
    --region COMPUTE_REGION | grep -E 'name|purpose'
```
  Ersetzen Sie PROXY_ONLY_SUBNET durch das Nur-Proxy-Subnetz.
GKE Gateway unterstützt nur REGIONAL_MANAGED_PROXY-Proxy-only-Subnetze für regionale Gateways (intern oder regional).
Wenn das vorhandene Nur-Proxy-Subnetz in der Region mit dem Zweck INTERNAL_HTTPS_LOAD_BALANCER erstellt wurde, migrieren Sie den Zweck zu REGIONAL_MANAGED_PROXY.

Kein gesunder Upstream

Symptom:

Das folgende Problem kann auftreten, wenn Sie ein Gateway erstellen, aber nicht auf die Backend-Dienste zugreifen können (Antwortcode 503):

no healthy upstream

Grund:

Diese Fehlermeldung gibt an, dass der Prüfer für die Systemdiagnose keine fehlerfreien Backend-Dienste finden kann. Möglicherweise sind Ihre Back-End-Dienste in Ordnung, aber Sie müssen die Systemdiagnosen möglicherweise anpassen.

Workaround:

Um dieses Problem zu beheben, passen Sie Ihre Systemdiagnose anhand der Anforderungen Ihrer Anwendung (z. B. /health) mithilfe einer HealthCheckPolicy an.

Nächste Schritte

Weitere Informationen zum Gateway Controller
Gateway-Ressourcen mithilfe von Richtlinien konfigurieren
Weitere Informationen zu anderen Gateway-Konfigurationen finden Sie in der Gateway API-Dokumentation.

Gateways bereitstellen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Hinweise

Anforderungen für GKE Gateway Controller

Limits und Einschränkungen

Gateway API im Cluster aktivieren

Cluster prüfen

Internes Gateway bereitstellen

Regionales internes Gateway bereitstellen

Nur-Proxy-Subnetz konfigurieren

Gateway erstellen

Demoanwendungen bereitstellen

HTTPRoute bereitstellen

Traffic an die Anwendung senden

Externes Gateway bereitstellen

Globales externes Gateway bereitstellen

Zertifikatzuordnung erstellen

Gateway erstellen

Demoanwendungen bereitstellen

HTTPRoute erstellen

Traffic an die Anwendung senden

Regionales externes Gateway bereitstellen

Proxy-Subnetz für Ihr regionales Gateway erstellen

Zertifikat erstellen, um den Client-Traffic zu sichern

Regionales externes HTTP(S)-Gateway erstellen

Demoanwendung bereitstellen

HTTPRoute erstellen

Traffic an die Anwendung senden

Gemeinsam genutzte Gateways verwenden

Routen für ein gemeinsam genutztes Gateway bereitstellen

Netzwerkstufe konfigurieren

Gateway-Standard-Backend konfigurieren

Statische IP-Adresse für ein Gateway konfigurieren

Benannte IP-Adresse verwenden

HTTP-zu-HTTPS-Weiterleitungen konfigurieren

HTTP-Traffic von einem Infrastruktur-Namespace weiterleiten

Pfadweiterleitungen und URL-Umschreibungen konfigurieren

Pfadweiterleitungen konfigurieren

Gesamten Pfad ersetzen

Nur ein Präfix ersetzen

URL-Umschreibungen konfigurieren

Gesamten Hostnamen umschreiben

Mit Pfadmodifikatoren umschreiben

Konfiguration überprüfen

Benutzerdefinierte Anfrage- und Antwortheader konfigurieren

Benutzerdefinierte Anfrageheader konfigurieren

Benutzerdefinierte Antwortheader konfigurieren

Konfiguration überprüfen

Routenstatus

HTTPRoute-Bedingungen

HTTPRoute-Ereignisse

Zusammenführung, Priorisierung und Validierung von Routen

Routenvorrang

Routenzusammenführung

Kubernetes-Gateways und Istio-Gateways

Fehlerbehebung

Nur-Proxy-Subnetz in der Region fehlt

Nur-Proxy-Subnetz ist in der Region mit dem falschen Zweck bereits vorhanden

Kein gesunder Upstream

Nächste Schritte

Gateways bereitstellen