Diese Seite wurde von der Cloud Translation API übersetzt.

Ingress zur Gateway API migrieren

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie die Traffic-Verwaltung in Google Kubernetes Engine (GKE) von der Ingress API zur Gateway API migrieren. Die Gateway API bietet eine vollständig verwaltete Google Cloud Lösung für die Verarbeitung Ihres Anwendungs-Traffics.

Um Ausfallzeiten zu minimieren und Risiken zu verringern, ist es am effektivsten, sowohl die vorhandene Ingress API als auch die neue Gateway API-Konfiguration gleichzeitig auszuführen. Diese Methode ermöglicht gründliche Tests der neuen Gateway-Konfiguration in einer Live-Umgebung, ohne Ihre aktuellen Dienste zu beeinträchtigen. Nachdem Sie die neue Gateway-Konfiguration validiert haben, können Sie eine schnelle DNS-Umstellung durchführen, um den Traffic zur Gateway API umzuleiten. So sorgen Sie für einen reibungslosen und risikoarmen Übergang.

Auf übergeordneter Ebene umfasst die Migrationsstrategie die folgenden Phasen:

Konfigurieren Sie den neuen Load Balancer.
Regeln für die Verarbeitung von eingehendem Traffic definieren
Stellen Sie die neue Konfiguration bereit und testen Sie den Trafficfluss zur neuen Gateway-IP-Adresse.
Produktions-Traffic auf die Gateway API umstellen
Bereinigen Sie die verbleibenden Ingress-Ressourcen.

Neuen Load Balancer konfigurieren

In dieser Phase stellen Sie eine Kubernetes-Gateway-Ressource bereit, um den Traffic zu Ihrem GKE-Cluster auszugleichen. Wenn Sie eine Gateway-Ressource bereitstellen, konfiguriert GKE einen Layer-7-Application Load Balancer, um HTTP(S)-Traffic für Anwendungen bereitzustellen, die im Cluster ausgeführt werden. Sie stellen für jeden Cluster oder jeden Load Balancer, den Sie benötigen, eine Gateway-Ressource bereit.

Im folgenden Beispiel konfigurieren Sie einen globalen externen Application Load Balancer. Speichern Sie zum Erstellen eines Gateways das folgende Manifest als gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http-gateway
spec:
  gatewayClassName: gke-l7-global-external-managed # GKE's managed external Application Load Balancer
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same # Only allow HTTPRoutes from the same namespace

Das obige Manifest beschreibt ein Gateway mit den folgenden Feldern:

gatewayClassName: gke-l7-global-external-managed: gibt die GatewayClass für dieses Gateway an. Diese Gateway-Klasse verwendet einen globalen externen Application Load Balancer.
protocol: HTTP und port: 80: gibt an, dass das Gateway Port 80 für HTTP-Traffic verfügbar macht.

Traffic-Regeln für eingehenden Traffic definieren

Routenressourcen definieren protokollspezifische Regeln für die Zuordnung von Traffic von einem Gateway zu Back-End-Diensten.

In dieser Phase übersetzen Sie Ihr Ingress-Manifest in eine HTTPRoute-Ressource. Folgen Sie der Anleitung im Tool ingress2gateway, um das Ingress-Manifest zu konvertieren.

In diesem Beispiel wird davon ausgegangen, dass Sie die folgende Ingress-Ressource haben:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: Prefix
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

Nachdem Sie das Manifest mit dem Tool ingress2gateway konvertiert haben, ist die Ausgabe das übersetzte HTTPRoute-Manifest.

Speichern Sie das folgende Beispielmanifest als httproute.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: cafe-route
spec:
  # This route attaches to our new Gateway
  parentRefs:
  - name: external-http-gateway
  # The hostname is the same as before
  hostnames:
  - "cafe.example.com"
  # The routing rules are now more explicit
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /tea
    backendRefs:
    - name: tea-svc
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    backendRefs:
    - name: coffee-svc
      port: 80

Das Feld rules im HTTPRoute-Manifest entspricht direkt den Routingregeln, die im ursprünglichen Ingress-Manifest definiert sind.

Neue Konfiguration bereitstellen und testen

In dieser Phase wenden Sie die Gateway- und HTTPRoute-Manifeste an, die Sie in den beiden vorherigen Phasen erstellt haben, und testen, ob der Traffic zur neuen IP-Adresse des Gateways fließt.

Wenden Sie die Gateway- und HTTPRoute-Manifeste an:

kubectl apply -f gateway.yaml
kubectl apply -f httproute.yaml

Rufen Sie die IP-Adresse des Gateways ab. Die Zuweisung der IP-Adresse kann einige Minuten dauern:
```
kubectl get gateway external-http-gateway -o=jsonpath="{.status.addresses[0].value}" --watch
```
Die Ausgabe ist die externe IP-Adresse des Gateways, z. B. 203.0.113.90.
Testen Sie die neue Gateway-IP-Adresse. Verwenden Sie den folgenden curl-Befehl, um eine Anfrage an die IP-Adresse zu senden und den Hostnamen cafe.example.com anzugeben. Beispiel:
```
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/tea
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/coffee
```
Ersetzen Sie 203.0.113.90 durch die externe IP-Adresse, die Sie im vorherigen Schritt ermittelt haben. Die Ausgabe bestätigt, dass die neue Gateway-IP-Adresse den Traffic für cafe.example.com korrekt weiterleitet, ohne dass ein DNS-Lookup durchgeführt wird.

Traffic an die neue Gateway-IP-Adresse weiterleiten

In dieser Phase stellen Sie den Live-Traffic von Ihrem bisherigen Ingress auf das neue Gateway um. Dazu aktualisieren Sie Ihre DNS-Einträge so, dass sie auf die neue Gateway-IP-Adresse verweisen. Die genauen Schritte zum Aktualisieren von DNS-Einträgen hängen von Ihrem DNS-Anbieter ab.

Wenn Sie beispielsweise cafe.example.com in Ingress konfiguriert haben, suchen Sie bei Ihrem DNS-Anbieter nach dem A-Eintrag für cafe.example.com und ändern Sie den Wert der alten Ingress-IP-Adresse in 203.0.113.90, die neue Gateway-IP-Adresse.

Nachdem Sie den DNS-Eintrag aktualisiert haben, wird der Traffic vom Ingress zum Gateway verschoben. Die Umstellung erfolgt jedoch nicht sofort für alle Clients. DNS-Resolver, die den vorherigen Eintrag im Cache gespeichert haben, warten, bis der TTL-Wert (Time to Live) des Eintrags abläuft, bevor sie den Eintrag noch einmal abfragen und die aktualisierte IP-Adresse erhalten. Aus diesem Grund sollten Sie Ihr vorhandenes Ingress und das neue Gateway parallel betreiben, bis Sie sicher sind, dass kein Traffic mehr an das Ingress gesendet wird. Dies weist darauf hin, dass die DNS-Weiterleitung abgeschlossen ist und Clients nicht mehr an die alte IP-Adresse weitergeleitet werden. Sie können dies überprüfen, indem Sie den Traffic auf Ihrem Load Balancer oder Ingress-Controller beobachten. Weitere Informationen finden Sie unter DNS-Weitergabe prüfen.

Wenn Sie Cloud DNS verwenden, können Sie mit Zielgewichten den Traffic schrittweise von der alten zur neuen IP-Adresse verschieben. Weitere Informationen finden Sie unter DNS-Routingrichtlinien und Systemdiagnosen konfigurieren.

Verbleibende Ingress-Ressourcen bereinigen

Nachdem Sie bestätigt haben, dass Ihr neues Gateway erfolgreich ausgeführt wird, bereinigen Sie die alten Ingress-Ressourcen.

Ingress-Ressource löschen:
```
kubectl delete ingress cafe-ingress
```
Deinstallieren Sie den ingress-nginx-Controller. Wenn Sie den Controller beispielsweise mit Helm installiert haben, führen Sie den folgenden Befehl aus:
```
helm uninstall ingress-nginx -n ingress-nginx
```

Vergleich der Funktionen von Ingress NGINX und GKE Gateway

Die Gateway API bietet eine standardisierte Möglichkeit, Ingress zu konfigurieren, und bietet Parität für die meisten gängigen Funktionen wie Routing, Header und Trafficaufteilung.

In der folgenden Tabelle werden die Anmerkungen verglichen, die für gängige Funktionen im Ingress-Controller und in der Gateway API verwendet werden.

Funktion	Annotation in Ingress	Annotation in GKE Gateway	Parität
URL-Umschreibungen	`nginx.ingress.kubernetes.io/rewrite-target`	`HTTPRoute` mit einem `urlRewrite`-Filter.	Teilweise Parität. GKE Gateway unterstützt nur Präfixersetzungen.
Header-Manipulation	`nginx.ingress.kubernetes.io/proxy-set-headers` oder `add-headers`	`HTTPRoute` mit einem `requestHeaderModifier`-Modifikator oder einem `responseHeaderModifier`-Filter.	Vollständige Parität.
Pfadbasiertes Routing	`spec.rules.http.paths` im Ingress-Objekt.	`rules.matches.path` im HTTPRoute-Objekt.	Vollständige Parität.
Hostbasiertes Routing	`spec.rules.host` im Ingress-Objekt.	`hostnames` im HTTPRoute-Objekt.	Vollständige Parität.
Traffic-Aufteilung	`nginx.ingress.kubernetes.io/canary` Anmerkungen.	`HTTPRoute` mit gewichteten `backendRefs`.	Vollständige Parität. Außerdem können Sie den Traffic mit detaillierter Steuerung aufteilen.
Authentifizierung	`nginx.ingress.kubernetes.io/auth-url` für die externe Authentifizierung.	Identity-Aware Proxy (IAP): `BackendPolicy` CRD. Andere: Erfordert einen benutzerdefinierten Ansatz, möglicherweise mit Service Mesh oder benutzerdefinierten Filtern.	Teilweise Parität. Identity-Aware Proxy ist die empfohlene Methode zum Sichern Ihres Gateways und wird im Backend konfiguriert.