Istio ServiceEntry zu GCPBackend für Cloud Run migrieren

Auf dieser Seite erfahren Sie, wie Sie von ServiceEntry zu GCPBackend migrieren. Außerdem wird gezeigt, wie die Funktionen zur Verkehrsverwaltung von Istio eine reibungslose und sichere Umstellung ermöglichen.

Die Migration zu GCPBackend bietet folgende Vorteile:

  1. Vereinfachter Anwendungscode: Sie müssen keine manuelle IAM-JWT-Injection in die Anwendung mehr vornehmen, wodurch Komplexität und potenzielle Fehler reduziert werden.
  2. Verbesserte Sicherheit: Mit der automatischen IAM-JWT-Injection können Sie die Kommunikation zwischen GKE und Cloud Run sicherer gestalten.
  3. Nahtlose Migration: Mithilfe der Traffic-Aufteilung und -Spiegelung können Sie Traffic sicher migrieren, ohne die Anwendung zu beeinträchtigen.
  4. Erweiterte Verwaltungsfunktionen: Sie profitieren von einer optimierten Konfiguration und Verwaltung.

Hinweise

In den folgenden Abschnitten wird davon ausgegangen, dass Sie Folgendes haben:

  1. GKE-Cluster mit aktiviertem Cloud Service Mesh
  2. Einen Cloud Run-Dienst als Istio-Diensteintrag
  3. Die GCPBackend-Ressource ist konfiguriert.

Erstellen oder ändern Sie den vorhandenen VirtualService, um sowohl ServiceEntry als auch GCPBackend als Ziele anzugeben.

Mithilfe der Traffic-Aufteilung können Sie den Traffic schrittweise vom ServiceEntry zum GCPBackend verlagern. Sie sollten mit einem kleinen Prozentsatz des Traffics beginnen, der an das GCP-Backend weitergeleitet wird, und ihn nach und nach erhöhen, während Sie auf Probleme achten.

Im folgenden Beispiel wird die Migration von 10% der Anfragen zum GCP-Backend beschrieben.

cat <<EOF > virtual-service.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: cr-gcpbackend-migration
  namespace: NAMESPACE
spec:
  hosts:
  - cr-service-entry.com
  http:
  - route:
    - destination:
        host: cr-gcpbackend.com
      weight: 10 # 10% traffic to gcp backend.
    - destination:
        host: cr-service-entry.com
      weight: 90 # 90% traffic to service entry
EOF
kubectl apply -f virtual-service.yaml

Wobei:

  • NAMESPACE ist der Name des Namespace.

In diesem Fall gilt Folgendes:

  • VIRTUAL_SERVICEE ist cr-gcpbackend-migration.
  • SERVICE_ENTRY_HOSTNAME ist cr-service-entry.com.
  • GCP_BACKEND_HOSTNAME ist =cr-gcpbackend.com.

(Optional) VirtualService für die Traffic-Spiegelung konfigurieren

Um einen reibungslosen Übergang zu ermöglichen, können Sie das Traffic-Mirroring so konfigurieren, dass eine Kopie des Traffics an das GCP-Backend gesendet wird, während der Traffic weiterhin hauptsächlich an die ServiceEntry-URL weitergeleitet wird. So können die GCPBackend-Konfiguration getestet und validiert werden, ohne den primären Trafficfluss zu beeinträchtigen. Weitere Informationen finden Sie in der Istio Virtual Service API.

Funktion prüfen

Sehen Sie in Ihren Anwendungsprotokollen oder Cloud Service Mesh-Messwerten nach, wie hoch die Fehlerrate bei Anfragen an $SERVICE_ENTRY_HOSTNAME ist. Es sollten keine Fehler auftreten.

Wenn Sie den Test außerhalb Ihrer Anwendung durchführen möchten, können Sie einen Curl-Client bereitstellen. Wenn die Anfrage über die GCPBackend API an Cloud Run weitergeleitet wird, muss ihr kein IAM-Token explizit hinzugefügt werden, da Cloud Service Mesh dies automatisch übernimmt.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: testcurl
  namespace: default
spec:
  containers:
  - name: curl
    image: curlimages/curl
    command: ["sleep", "3000"]
EOF

kubectl exec testcurl -c curl -- curl "$SERVICE_ENTRY_HOSTNAME"

Die Ausgabe sollte eine gültige HTTP 200-Antwort sein.