Gateways bereitstellen

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie Kubernetes-Gateway-Ressourcen für Load-Balancing von eingehendem Traffic in einem einzelnen GKE-Cluster (Google Kubernetes Engine) 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.

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 diese Aufgabe 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 gcloud components update ab.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

Anforderungen für GKE Gateway Controller

Für Standard, GKE-Version 1.24 oder höher

Für Autopilot, GKE-Version 1.26 oder höher.
Google Cloud CLI-Version 407.0.0 oder höher.
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

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.
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 die Trafficweiterleitung keine Portnummer direkt im Hostnamen angeben (z. B. web.example.com: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-Umschreibungen mit Gateway sind nur in GKE-Version 1.27 oder höher verfügbar.

Für benutzerdefinierte Anfrage- und Antwortheader mit Gateway- und Pfadweiterleitungen und URL-Umschreibungen mit Gateway wird die GatewayClass gke-l7-gxlb nicht unterstützt.

Beim Konfigurieren von benutzerdefinierten HTTPRoute-Anfrage- und -Antwortheadern werden die folgenden Google Cloud-Variablen nicht unterstützt:
- cdn_cache_id (Cloud CDN wird nicht mit GKE Gateway unterstützt)
- cdn_cache_status (Cloud CDN wird nicht mit GKE Gateway 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)
Für den GKE-Gateway gelten die Einschränkungen des klassischen Google Cloud-Anwendungs-Load-Balancers mit einer zusätzlichen Einschränkung:
- Sie können 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 dasselbe Ergebnis zu erzielen.

Gateway API im Cluster aktivieren

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

Neuen Cluster mit aktivierter Gateway API erstellen

GKE unterstützt die Gateway API auf Autopilot-Clustern ab GKE-Version 1.26. Wenn Sie neue Autopilot-Cluster in GKE 1.26 und höher erstellen, ist die Gateway API standardmäßig aktiviert. Bei vorhandenen Clustern ab GKE-Version 1.25 ist die Gateway API standardmäßig deaktiviert.

Autopilot

Erstellen Sie einen neuen GKE Autopilot-Cluster mit aktivierter Gateway API:

  gcloud container clusters create-auto CLUSTER_NAME \
      --location=CLUSTER_LOCATION \
      --release-channel=RELEASE_CHANNEL \
      --cluster-version=VERSION

Ersetzen Sie Folgendes:

CLUSTER_NAME ist der Name des Clusters.
CLUSTER_LOCATION ist die Compute Engine-Region oder -Zone für den neuen Cluster.
RELEASE_CHANNEL ist der Name der Release-Version.
VERSION ist die GKE-Version; die 1.26 oder höher sein muss. Sie können auch das Flag --release-channel verwenden, um einen Release-Kanal auszuwählen. Die Release-Version muss die Standardversion 1.26 oder höher sein.

Standard

Bei GKE Standard wird die Gateway API vom Flag --gateway-api gesteuert. Sie können den Wertstandard verwenden, wenn Sie ihn aktivieren, und ihn bei Deaktivierung deaktivieren.

Erstellen Sie einen neuen VPC-nativen GKE-Cluster mit aktivierter Gateway API:

  gcloud container clusters create CLUSTER_NAME \
    --gateway-api=standard \
    --cluster-version=VERSION \
    --location=CLUSTER_LOCATION

Ersetzen Sie Folgendes:

RELEASE_CHANNEL ist der Name der Release-Version.
CLUSTER_NAME ist der Name des Clusters.
VERSION: die GKE-Version; 1.24 oder höher. Sie können auch das Flag --release-channel verwenden, um einen Release-Kanal auszuwählen. Die Release-Version muss die Standardversion 1.24 oder höher sein.
CLUSTER_LOCATION ist die Compute Engine-Region oder -Zone für den neuen Cluster.

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

Gateway API in einem vorhandenen Cluster aktivieren

Achten Sie darauf, dass die Autopilot-Cluster-Version 1.26 oder höher und die Standard-Cluster-Version 1.24 oder höher ist.

So aktivieren Sie die Gateway API in einem vorhandenen GKE-Cluster (Autopilot oder Standard):

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.

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

Das folgende Beispiel zeigt, wie Sie ein regionales internes Gateway bereitstellen, das eine effiziente und sichere Kommunikation zwischen Diensten innerhalb 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 ist der Name des VPC-Netzwerks, das das Subnetz enthält.
- 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/v1beta1
metadata:
  name: internal-http
spec:
  gatewayClassName: gke-l7-rilb
  listeners:
  - 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.
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 in 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:  1970-01-01T00:00:00Z
    Message:               Waiting for controller
    Reason:                NotReconciled
    Status:                False
    Type:                  Scheduled
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

Jetzt befindet sich in Ihrem Cluster ein Gateway, das einen Load-Balancer und eine IP-Adresse bereitgestellt hat. Das Gateway hat jedoch keine Routes 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/v1beta1
metadata:
  name: store
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - name: store-v1
      port: 8080
  - matches:
    - headers:
      - name: env
        value: canary
    backendRefs:
    - name: store-v2
      port: 8080
  - matches:
    - path:
        value: /de
    backendRefs:
    - name: store-german
      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/v1beta1
Kind:         HTTPRoute
<...>
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",
  <...>

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.

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.

Da Sie nicht Inhaber des Hostnamens example.com sind, legen Sie den Host-Header manuell fest, damit das Trafficrouting beobachtet werden kann. Senden Sie zuerst eine Anfrage an „store.example.com“:
```
curl -H "host: store.example.com" VIP
```
Ersetzen Sie VIP 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 -H "host: store.example.com" VIP/de

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 "host: store.example.com" -H "env: canary " VIP

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 Ihrer VPC 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.

Ein globales externes Gateway verwendet eine globale IP-Adresse (oder eine Anycast-IP-Adresse) als Frontend des Gateways, das in allen Google Cloud Compute-Regionen beworben wird. 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.

Ein regionales externes Gateway verwendet eine regionale IP-Adresse als Frontend des Gateways, das nur in der lokalen Google Cloud Compute-Region beworben wird, in der das regionale externe Gateway bereitgestellt ist. Clients, die Traffic an diese regionale IP-Adresse senden, werden von ihrem lokalen ISP und über das Internet weitergeleitet, bevor sie die Google-Region erreichen, in der die IP beworben wird. Das regionale externe Gateway ist nur in der Standard-Netzwerkdienststufe verfügbar.

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 neuen Datei, die Sie auswählen. Die Datei muss die Endung .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/v1beta1
metadata:
  name: external-http
  annotations:
    networking.gke.io/certmap: store-example-com-map
spec:
  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/v1beta1
metadata:
  name: store-external
spec:
  parentRefs:
  - kind: Gateway
    name: external-http
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - name: store-v1
      port: 8080
  - matches:
    - headers:
      - name: env
        value: canary
    backendRefs:
    - name: store-v2
      port: 8080
  - 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/v1beta1
Kind:         HTTPRoute
<...>
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:
    Conditions:
      Last Transition Time:  2022-11-01T05:42:31Z
      Message:
      Reason:                Accepted
      Status:                True
      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>
<...>
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
      <...>

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 -H "host: store.example.com" https://GATEWAY_IP_ADDRESS --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.

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 -H "host: store.example.com" https://GATEWAY_IP_ADDRESS/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 "host: store.example.com" -H "env: canary " https://GATEWAY_IP_ADDRESS/de --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 eine Speicheranwendung mit mehreren Zertifikaten, die an das regionale externe Gateway angehängt sind, mithilfe von selbstverwalteten Zertifikaten und einer HTTPRoute verfügbar gemacht werden.

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.

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/v1beta1
  metadata:
    name: external-regional-http
  spec:
    gatewayClassName: gke-l7-regional-external-managed
    listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
        - name: store-example-com
    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 abgleichen und filtern zu können.

Traffic an die Anwendung senden

Nachdem Sie Ihre Anwendung bereitgestellt und HTTPRoutes erstellt haben, können Sie den 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 APIs verwenden 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 Gateway internal-http auf, das unter Internes Gateway bereitstellen bereitgestellt wird.

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/v1beta1
metadata:
  name: site-internal
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "site.example.com"
  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 ordnungsgemäß 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 Nachbarn.

Sie müssen eine virtuelle Maschine (VM) in derselben VPC wie das Gateway verwenden.

Die Ausgabe sieht in 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"
}

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.

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/v1beta1
metadata:
  name: custom-default-backend
spec:
  parentRefs:
  - kind: Gateway
    name: my-internal-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 zur Überwachung von Traffic verwendet wird. Wenn Sie keine IP-Adresse auf dem Gateway angeben, stellt der Gateway-Controller automatisch eine IP-Adresse bereit. Sie können auch eine statische IP-Adresse erstellen, sodass 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 IPv4/IPv6-Adressbereich des primären 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 IP-Adresse durch Angabe einer NamedAddress konfigurieren. 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 wird für globale, externe Gateways nicht benötigt.
- SUBNET: das Subnetz für die IP-Adresse. Dieses Flag wird für globale, externe Gateways nicht benötigt.
- 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/v1beta1
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
```

Prüfen Sie die Gateway-IP-Adresse:

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-Traffic vom Gateway-Namespace weiterleiten

Im folgenden Beispiel ist das Gateway so konfiguriert, dass Same (Anhang aus demselben Namespace) für den HTTP-Listener zulässig ist, während der HTTPS-Listener für alle Namespaces geöffnet wird. Bei Verwendung dieser Konfiguration sollte nur die Weiterleitung HTTPRoute im selben Namespace wie das Gateway vorhanden sein.

Mit dieser Konfiguration wird sichergestellt, dass keine zusätzlichen HTTPRoutes an den HTTP-Listener des Gateways gebunden werden können. Dies erfordert, dass die HTTPRoutes des Anwendungsteams im Namespace gateway-infra nicht zulässig sind.

Erstellen Sie den Namespace gateway-infra des 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 ein Gateway mit dem folgenden Manifest und speichern Sie das Manifest als external-gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: external-http
  namespace: gateway-infra
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
      namespaces:
        from: Same
  - name: https
    protocol: HTTPS
    port: 443
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
      namespaces:
        from: All
    tls:
      mode: Terminate
      options:
        networking.gke.io/pre-shared-certs: store-example-com

Das Feld namespaces unter allowedRoutes beschränkt den HTTP-Listener auf den Namespace gateway-infra des Gateways.
Der HTTPS-Listener enthält keine Einschränkung für die zulässigen Namespaces, sodass alle Namespaces den HTTPS-Listener mit einer HTTPRoute verwenden.

Wenden Sie das Manifest an:
```
kubectl apply -f external-gateway.yaml
```
Um die HTTPS-Weiterleitung zu erzwingen, erstellen Sie mit dem folgenden Manifest eine Standard-HTTPRoute und speichern Sie das Manifest als redirect-httproute.yaml:
```
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: redirect
  namespace: gateway-infra
spec:
  parentRefs:
  - namespace: gateway-infra
    name: external-http
    sectionName: http
  rules:
  - 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.
Bei dieser Konfiguration wird der gesamte Traffic an Port 80 des Gateways an den Listener an Port 443 weitergeleitet. Dadurch wird eine sichere Kommunikation zwischen dem Client und dem Load-Balancer erzwungen.

Wenden Sie das Manifest an:

kubectl apply -f redirect-httproute.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.2.20
        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 zulässt. Speichern Sie das Manifest als httproute.yaml:
```
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-external
  labels:
    gateway: external-http
spec:
  parentRefs:
  - name: external-http
    namespace: gateway-infra
    sectionName: https
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - name: store-v1
      port: 8080
```
Hinweis: Wenn Sie HTTP-zu-HTTPS-Weiterleitungen auf dem Gateway konfigurieren, müssen Sie das Feld sectionName:https in der Routenkonfiguration angeben. Wenn für Ihr Gateway mehrere Listener konfiguriert sind (z. B. HTTP und HTTPS), müssen Sie in Ihrer HTTPRoute-Konfiguration explizit sectionName:https angeben. Dadurch wird die Weiterleitung nur auf den HTTPS-Listener angewendet. Wenn Ihr Gateway nur einen HTTPS-Listener hat, können Sie das Feld sectionName weglassen, da die Weiterleitung standardmäßig darauf angewendet wird.
Wenden Sie das Manifest an:
```
kubectl apply -f httproute.yaml
```

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 bestimmten Namespace (http-redirect) befindet, während der HTTPS-Listener für alle Namespaces geöffnet wird. 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
```
- Für diesen Namespace sind bestimmte Labels festgelegt.

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/v1beta1
metadata:
  name: external-http
  namespace: gateway-infra
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
      namespaces:
        from: selector
        selector:
          matchLabels:
            otherInfra: httpToHttps
  - name: https
    protocol: HTTPS
    port: 443
    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/v1beta1
metadata:
  name: redirect
  namespace: http-redirect
spec:
  parentRefs:
  - namespace: gateway-infra
    name: external-http
    sectionName: http
  rules:
  - 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.2.20
        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/v1beta1
metadata:
  name: store-external
  labels:
    gateway: external-http
spec:
  parentRefs:
  - name: external-http
    namespace: gateway-infra
    sectionName: https
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - name: store-v1
      port: 8080

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

Pfadweiterleitungen und URL-Umschreibungen konfigurieren

Pfadweiterleitungen umfassen die Weiterleitung einer eingehenden Anfrage von einem URL-Pfad zu einem anderen. Mit Pfadweiterleitungen können Sie die Struktur der URL ändern, wenn Sie veraltete oder verworfene URLs verarbeiten müssen.

URL-Umschreibungen helfen dabei, die eingehende URL zu ä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. Das Umschreiben von URLs ist vorteilhaft für die Erstellung nutzerfreundlicher und SEO-freundlicher URLs, die leicht zu merken und zu verstehen sind. Standardmäßig sind Pfadweiterleitungen und URL-Umschreibungen nicht konfiguriert. Sie müssen diese Weiterleitungen oder Umschreibungen explizit mithilfe eines Filters in Ihrer HTTPRoute konfigurieren.

GKE Gateway unterstützt Pfadweiterleitungen und URL-Umschreibungen. 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

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

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

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
    - matches:
      - path:
          type: PathPrefix
          value: /any-path
      filters:
      - type: RequestRedirect
        requestRedirect:
          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 im Cache zu speichern, sondern auf die neueste 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/v1beta1
kind: HTTPRoute
metadata:
  name: store
spec:
  parentRefs:
    - kind: Gateway
      name: external-http
  hostnames:
  - store.example.com
  rules:
  - matches:
      - path:
          type: PathPrefix
          value: /any-prefix
    filters:
    - type: RequestRedirect
      requestRedirect:
        path:
          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 Routingregel folgt der einzigen Weiterleitungsregel, die dafür sorgt, dass der Browser Sie immer zur gewünschten Seite weiterleitet.

URL-Umschreibungen konfigurieren

Legen Sie URL-Überschreibungen fest, um die Darstellung einer URL für Nutzer zu ändern. 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/v1beta1
  kind: HTTPRoute
  metadata:
    name: www
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - www.example.com
    rules:
    - filters:
      - type: URLRewrite
        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 Umschreibungen mit Pfadmodifikatoren kombinieren, um erweiterte URL- und Pfadänderungen bereitzustellen, bevor die Anfrage an den Back-End-Dienst weitergeleitet wird.

So schreiben Sie mit Pfadmodifikatoren neu:

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 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/v1beta1
  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
        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 nach dem Erstellen Ihrer HTTPRoute mit URL-Umschreibungs- oder Pfadweiterleitungsfiltern angewendet wurde:

kubectl get httproute www -o yaml

Die Ausgabe sieht in etwa so aus:

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"gateway.networking.k8s.io/v1beta1","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/v1beta1
  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/v1beta1
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/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /fr
        filters:
          - 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/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /de
        filters:
          - 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/v1beta1
  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. Dies kann auftreten, wenn Ihre Route von keinem Gateway ausgewählt wurde.

HTTPRoute-Ereignisse

HTTPRoute-Ereignisse liefern 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/v1beta1
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/v1beta1
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/v1beta1
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 gibt an, 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, die bereits ein Nur-Proxy-Subnetz hat.

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 zu ermitteln, welches 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 das Nur-Proxy-Subnetz in der Region, um seinen 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-Nur-Proxy-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 seinen Zweck zu REGIONAL_MANAGED_PROXY.

Gateways bereitstellen

Hinweise

Anforderungen für GKE Gateway Controller

Limits und Einschränkungen

Gateway API im Cluster aktivieren

Neuen Cluster mit aktivierter Gateway API erstellen

Gateway API in einem vorhandenen 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

Gateway-Standard-Backend konfigurieren

Statische IP-Adresse für ein Gateway konfigurieren

Benannte IP-Adresse verwenden

HTTP-zu-HTTPS-Weiterleitungen konfigurieren

HTTP-Traffic vom Gateway-Namespace weiterleiten

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

Nächste Schritte