Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Ingress zur Gateway API migrieren

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie die Trafficverwaltung 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 Anwendungstraffics.

Um Ausfallzeiten zu minimieren und Risiken zu reduzieren, ist es am effektivsten, sowohl die vorhandene Ingress API- als auch die neue Gateway API-Konfiguration gleichzeitig auszuführen. Mit dieser Methode können Sie die neue Gateway-Konfiguration in einer Live-Umgebung gründlich testen, ohne dass sich dies auf Ihre aktuellen Dienste auswirkt. Nachdem Sie die neue Gateway-Konfiguration validiert haben, können Sie eine schnelle DNS-Umstellung durchführen, um den Traffic an die Gateway API weiterzuleiten. So wird ein reibungsloser und risikoarmer Übergang ermöglicht.

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.
Stellen Sie den Produktionstraffic auf die Gateway API um.
Bereinigen Sie die verbleibenden Ingress-Ressourcen.

Neuen Load Balancer konfigurieren

In dieser Phase stellen Sie eine Kubernetes-Gateway-Ressource bereit, um das Load-Balancing für den Traffic zu Ihrem GKE-Cluster durchzuführen. Wenn Sie eine Gateway-Ressource bereitstellen, konfiguriert GKE einen Layer-7-Application Load Balancer, um HTTP(S)-Traffic für Anwendungen verfügbar zu machen, 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 vorherige Manifest beschreibt ein Gateway, das die folgenden Felder enthält:

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 den Backend-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 ingress2gateway-Tool 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 an die neue IP-Adresse des Gateways weitergeleitet wird.

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. Es kann einige Minuten dauern, bis die IP-Adresse zugewiesen ist:
```
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 dabei 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 vorherigen 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 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 von Ingress auf Gateway umgestellt. 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 abgelaufen ist, bevor sie den Eintrag noch einmal abfragen und die aktualisierte IP-Adresse erhalten. Aus diesem Grund sollten Sie den vorhandenen Ingress und das neue Gateway parallel ausführen, bis Sie sicher sind, dass der Traffic zum Ingress eingestellt wurde. Das bedeutet, dass die DNS-Weitergabe abgeschlossen ist und Clients nicht mehr an die alte IP-Adresse weitergeleitet werden. Sie können dies prüfen, indem Sie den Traffic auf Ihrem Load Balancer oder Ingress-Controller überwachen. Weitere Informationen finden Sie unter DNS-Weitergabe prüfen.

Wenn Sie Cloud DNS verwenden, können Sie Zielgewichtungen verwenden, um Traffic schrittweise von der alten IP-Adresse zur neuen IP-Adresse zu 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
```

Featurevergleich zwischen Ingress-NGINX und GKE Gateway

Die Gateway API bietet eine standardisiertere Möglichkeit, Ingress zu konfigurieren, und bietet Funktionsparität für die gängigsten Funktionen wie Routing, Header und Aufteilung des Traffics.

In der folgenden Tabelle wird die Konfiguration für gängige Features im Ingress-Controller und in der Gateway API verglichen.

Funktion	Annotation in Ingress	Konfiguration im GKE-Gateway	Parität
Hostbasiertes Routing	Das Feld `spec.rules.host` im Ingress-Objekt.	Das Feld `hostnames` im HTTPRoute-Objekt.	Vollständige Parität.
Pfadbasiertes Routing	Das Feld `spec.rules.http.paths` im Ingress-Objekt und die Annotation `nginx.ingress.kubernetes.io/use-regex` für den Pfadabgleich mit regulären Ausdrücken.	Das Feld `rules.matches.path` im HTTPRoute-Objekt.	Vollständige Parität. GKE Gateway unterstützt den genauen, Präfix- und Abgleich mit regulären Ausdrücken (`RegularExpression`) für Pfade. Außerdem können Sie HTTP-Header (`rules.matches.headers`) und Abfrageparameter (`rules.matches.queryParams`) mithilfe von genauen Werten oder regulären Ausdrücken abgleichen.
Aufteilung des Traffics	`nginx.ingress.kubernetes.io/canary` Anmerkungen.	HTTPRoute mit dem gewichteten Feld `backendRefs`.	Vollständige Parität. Außerdem können Sie den Traffic mit detaillierter Steuerung aufteilen.
Sitzungsaffinität	`nginx.ingress.kubernetes.io/affinity`- und `nginx.ingress.kubernetes.io/affinity-mode`-Annotationen.	GCPTrafficDistributionPolicy mit dem Feld `sessionAffinity`.	Vollständige Parität. GKE Gateway unterstützt mehrere Sitzungsaffinitätstypen, darunter Cookie-basierte Affinitätstypen (`HTTP_COOKIE`, `GENERATED_COOKIE` und zustandsorientierte `STRONG_COOKIE_AFFINITY`), Header-basierte Affinität (`HEADER_FIELD`) und Client-IP-basierte Affinität (`CLIENT_IP`).
CORS (Cross-Origin Resource Sharing)	`nginx.ingress.kubernetes.io/enable-cors`	HTTPRoute mit einem `CORS`-Filter.	Vollständige Parität. Hinweis: GKE Gateway legt Limits für die Anzahl der Platzhaltermuster fest, die Sie pro Listener oder Hostnamen definieren können.
URL-Umschreibungen	`nginx.ingress.kubernetes.io/rewrite-target`	HTTPRoute mit einem `urlRewrite`-Filter oder GCPHTTPFilter mit dem Feld `spec.urlRewrite.regexModifier`.	Vollständige Parität. GKE Gateway unterstützt vollständige Pfadersetzungen, Präfixersetzungen und Pfadumschreibungen mit regulären Ausdrücken.
Header-Manipulation	`nginx.ingress.kubernetes.io/proxy-set-headers` oder `add-headers`	HTTPRoute mit einem `requestHeaderModifier`-Modifikator oder `responseHeaderModifier`-Filter.	Vollständige Parität.
Authentifizierung	`nginx.ingress.kubernetes.io/auth-url` für die externe Authentifizierung.	Identity-Aware Proxy (IAP): Benutzerdefinierte Ressource „GCPBackendPolicy“. Sonstiges: Erfordert einen individuelleren 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.