Ingress zur Gateway API migrieren

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 verringern, 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 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.

Im Großen und Ganzen umfasst die Migrationsstrategie die folgenden Phasen:

  1. Neuen Load-Balancer konfigurieren.
  2. Regeln für die Verarbeitung von eingehendem Traffic definieren.
  3. Neue Konfiguration bereitstellen und Trafficfluss zur neuen Gateway-IP-Adresse testen.
  4. Produktionstraffic zur Gateway API umstellen.
  5. Verbleibende Ingress-Ressourcen bereinigen.

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 freizugeben, die im Cluster ausgeführt werden. Sie stellen eine Gateway-Ressource für jeden Cluster oder für jeden Load-Balancer bereit, den Sie benötigen.

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 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: geben an, dass das Gateway Port 80 für HTTP-Traffic verfügbar macht.

Trafficregeln für eingehenden Traffic definieren

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

In dieser Phase übersetzen Sie Ihr Ingress-Manifest in eine HTTPRoute-Ressource. Folgen Sie der Anleitung im ingress2gateway Tool, 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

Beachten Sie, dass das Feld rules im HTTPRoute-Manifest direkt den Routingregeln entspricht, 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 vorherigen beiden Phasen erstellt haben, und testen, ob der Traffic zur neuen IP-Adresse des Gateways fließt.

  1. Wenden Sie die Gateway- und HTTPRoute-Manifeste an:

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

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

  3. 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 erhalten haben. Die Ausgabe bestätigt, dass die neue Gateway-IP-Adresse den Traffic für cafe.example.com korrekt weiterleitet, ohne eine DNS-Suche durchzuführen.

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, indem Sie Ihre DNS-Einträge so aktualisieren, dass sie auf die neue Gateway-IP-Adresse verweisen. Die genauen Schritte zum Aktualisieren von DNS-Einträgen variieren je nach DNS-Anbieter.

Wenn Sie beispielsweise cafe.example.com in Ingress konfiguriert haben, suchen Sie den A-Eintrag für cafe.example.com bei Ihrem DNS-Anbieter 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 zu 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 Ihren vorhandenen Ingress und das neue Gateway parallel ausführen, bis Sie feststellen, dass der Traffic zum Ingress eingestellt wurde. Das bedeutet, dass die DNS-Weitergabe abgeschlossen ist und Clients nicht mehr zur alten 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 Zielgewichtungen verwenden, um den 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 ordnungsgemäß ausgeführt wird, bereinigen Sie die alten Ingress-Ressourcen.

  1. Ingress-Ressource löschen:

    kubectl delete ingress cafe-ingress

  2. 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 Featureparität für die meisten gängigen Features wie Routing, Header und Trafficaufteilung.

In der folgenden Tabelle werden die Annotationen verglichen, die für gängige Features 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.
Headerbearbeitung 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.
Aufteilung des Traffics nginx.ingress.kubernetes.io/canary -Annotationen. 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.

Nächste Schritte