Gateways bereitstellen


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.

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:

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.

  1. 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"
      },
      ...
    },
    
  2. 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.

  1. 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.
  2. Ü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.

  1. 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.
  2. Stellen Sie das Gateway in Ihrem Cluster bereit:

    kubectl apply -f gateway.yaml
    
  3. 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.

  1. 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.

  2. 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
    
  3. 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.

  1. 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
    
  2. 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:

    Routingregeln, die vom Speicher HTTPRoute konfiguriert wurden

    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.
  3. 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",
      <...>
    
  4. 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.

  1. 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.

  2. 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"
    }
    
  3. 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"
    }
    
  4. 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.

  1. Aktivieren Sie die Certificate Manager API:

    gcloud services enable certificatemanager.googleapis.com
    
  2. Erstellen Sie eine Zertifikatzuordnung:

    gcloud beta certificate-manager maps create store-example-com-map
    
  3. 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.

  4. 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.

  1. 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.

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f gateway.yaml
    

    Es kann einige Minuten dauern, bis GKE die Ressourcen bereitgestellt hat.

  3. 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.

  1. 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.

  2. 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
    
  3. 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.

  1. 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.

  2. 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:

    Routingregeln, die vom Speicher HTTPRoute konfiguriert wurden

    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.
  3. 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",
      ...
    
  4. 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.

  1. 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.

  2. VM erstellen:

    gcloud cloud-shell ssh
    
  3. 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"
    }
    
  4. 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"
    }
    
  5. 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

  1. 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.
  2. 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
    
  3. Wenden Sie das regional-gateway-Manifest an:

      kubectl apply -f regional-gateway.yaml
    
  4. 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.

  1. Stellen Sie die Beispielanwendung bereit:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/site.yaml
    
  2. 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.

  3. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f site-route-internal.yaml
    
  4. 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.

  5. 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.

    1. 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.
    2. 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.

    3. Wenden Sie das Manifest auf Ihren Cluster an:

      kubectl apply -f named-ip-gateway.yaml
      
    4. 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.

    1. Erstellen Sie den Namespace gateway-infra des Gateways. Speichern Sie das Manifest als gateway-namespace.yaml:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: gateway-infra
      
    2. Wenden Sie das Manifest an:

      kubectl apply -f gateway-namespace.yaml
      
    3. 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.

    4. Wenden Sie das Manifest an:

      kubectl apply -f external-gateway.yaml
      
    5. 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.

    6. Wenden Sie das Manifest an:

      kubectl apply -f redirect-httproute.yaml
      
    7. 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"
      
    8. Wenden Sie das Manifest an:

      kubectl apply -f service-deployment.yaml
      
    9. 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
      
    10. 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.

    1. Erstellen Sie den Namespace eines Gateways. Speichern Sie das Manifest als gateway-namespace.yaml:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: gateway-infra
      
    2. Wenden Sie das Manifest an:

      kubectl apply -f gateway-namespace.yaml
      
    3. 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.
    4. Wenden Sie das Manifest an:

      kubectl apply -f redirect-namespace.yaml
      
    5. 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.

    6. Wenden Sie das Manifest an:

      kubectl apply -f external-gateway.yaml
      
    7. 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.
    8. Wenden Sie das Manifest an:

      kubectl apply -f http-redirect.yaml
      
    9. 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"
      
    10. Wenden Sie das Manifest an:

      kubectl apply -f service-deployment.yaml
      
    11. 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
      
    12. 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

    1. 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.

    2. 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).

    3. 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

    1. 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.

    2. 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).

    3. 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:

    1. 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.

    2. 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.

    3. 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:

    1. 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.

    2. 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.

    3. 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

    1. 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
      
    2. 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:

    1. Zusammenführung von Hostnamen: Der längste bzw. spezifischste Hostname-Abgleich.
    2. Pfadzusammenführung: Der längste bzw. spezifischste Pfadabgleich.
    3. Header-Zusammenführung: Die größte Anzahl der übereinstimmenden HTTP-Header.
    4. 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:

    1. Routenzusammenführung: Alle drei HTTPRoutes werden an dasselbe internal-http-Gateway angehängt und somit zusammengeführt.
    2. Hostnamenzusammenführung: Alle drei Routen stimmen mit store.example.com überein, sodass ihre Hostnamenregeln zusammengeführt werden.
    3. 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.
    4. 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.
    5. 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:

    1. 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).

    2. 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.

    Nächste Schritte