Istio ServiceEntry zu GCPBackend für Cloud Run migrieren

Auf dieser Seite wird beschrieben, wie Sie von ServiceEntry zu GCPBackend migrieren. Dabei wird gezeigt, wie die Traffic-Management-Funktionen von Istio für einen reibungslosen und sicheren Übergang sorgen können.

Die Migration zu GCPBackend bietet folgende Vorteile:

  1. Vereinfachter Anwendungscode: Sie müssen IAM-JWTs nicht mehr manuell in die Anwendung einfügen. Das reduziert die Komplexität und das Fehlerrisiko.
  2. Verbesserte Sicherheit: Nutzen Sie die automatische IAM-JWT-Einfügung für eine sicherere Kommunikation zwischen GKE und Cloud Run.
  3. Nahtlose Migration: Mit Traffic-Aufteilung und ‑Spiegelung können Sie Traffic sicher migrieren, ohne die Anwendung zu unterbrechen.
  4. Verbesserte Verwaltbarkeit: Profitieren Sie von der optimierten Konfiguration und Verwaltung.

Hinweise

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

  1. Ein GKE-Cluster mit aktiviertem Cloud Service Mesh.
  2. Ein Istio-Diensteintrag.
  3. Die GCPBackend-Ressource für den Cloud Run-Dienst wurde konfiguriert.

Erstellen oder ändern Sie den vorhandenen VirtualService, sodass sowohl der ServiceEntry als auch das GCPBackend als Ziele enthalten sind.

Sie können Traffic-Splitting verwenden, um den Traffic schrittweise vom ServiceEntry zum GCPBackend zu verlagern. Sie sollten mit einem kleinen Prozentsatz des Traffics beginnen, der an das GCPBackend weitergeleitet wird, und diesen Prozentsatz nach und nach erhöhen, während Sie auf Probleme achten.

Im folgenden Beispiel werden 10% der Anfragen zum GCPBackend migriert.

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

Wobei:

  • NAMESPACE ist der Namespace-Name.

In diesem Fall gilt Folgendes:

  • VIRTUAL_SERVICE ist gcpbackend-migration.
  • SERVICE_ENTRY_HOSTNAME ist service-entry.com.
  • GCP_BACKEND_HOSTNAME ist gcpbackend.com.

Optional: VirtualService für die Trafficspiegelung konfigurieren

Um einen reibungslosen Übergang zu gewährleisten, können Sie die Spiegelung von Traffic konfigurieren, um eine Kopie des Traffics an das GCPBackend zu senden, während der Traffic weiterhin hauptsächlich an den ServiceEntry weitergeleitet wird. So können Sie die GCPBackend-Konfiguration testen und validieren, ohne den primären Trafficfluss zu beeinträchtigen. Weitere Informationen finden Sie in der Istio Virtual Service API.

Funktionalität prüfen

Sehen Sie in Ihren Anwendungslogs oder Cloud Service Mesh-Messwerten nach, um die Fehlerrate von Anfragen an $SERVICE_ENTRY_HOSTNAME zu prüfen. Es sollten keine Fehler auftreten.

Wenn Sie außerhalb Ihrer Anwendung testen möchten, können Sie einen curl-Client bereitstellen. Wenn die Anfrage über die GCPBackend API an Cloud Run weitergeleitet wird, ist kein IAM-Token erforderlich, da Cloud Service Mesh es automatisch anhängt.

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.