Istio-ServiceEntry zu GCPBackend für Cloud Run migrieren

Auf dieser Seite erfahren Sie, wie Sie von ServiceEntry zu GCPBackend migrieren. Dabei wird gezeigt, wie die Traffic-Management-Funktionen von Istio einen reibungslosen und sicheren Übergang ermöglichen.

Die Migration zu GCPBackend bietet folgende Vorteile:

1. Vereinfachter Anwendungscode: Sie können die manuelle IAM-JWT-Einfügung in der Anwendung vermeiden, wodurch die Komplexität und potenzielle Fehler reduziert werden.
2. Verbesserte Sicherheit: Nutzen Sie die automatische IAM-JWT-Einfügung für eine sicherere Kommunikation zwischen GKE und Cloud Run.
3. Nahtlose Migration: Verwenden Sie Trafficaufteilung und -spiegelung, um Traffic sicher zu migrieren, ohne die Anwendung zu unterbrechen.
4. Verbesserte Verwaltbarkeit: Profitieren Sie von der optimierten Konfiguration und Verwaltung.

Hinweis

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

1. Einen GKE-Cluster mit aktiviertem Cloud Service Mesh.
2. Einen Cloud Run-Dienst als Istio-ServiceEntry.
3. Eine konfigurierte GCPBackend-Ressource.

Vorhandenen VirtualService so erstellen oder ändern, dass sowohl ServiceEntry als auch GCPBackend als Ziele enthalten sind

Sie können die Trafficaufteilung verwenden, um Traffic schrittweise von ServiceEntry zu GCPBackend zu verschieben. Beginnen Sie mit einem kleinen Prozentsatz des Traffics, der an das GCPBackend weitergeleitet wird, und erhöhen Sie ihn schrittweise, 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: 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 Namespace-Name.

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 Trafficspiegelung konfigurieren

Um einen noch reibungsloseren Übergang zu gewährleisten, können Sie die Trafficspiegelung konfigurieren, um eine Kopie des Traffics an das GCPBackend zu senden, während der Traffic weiterhin hauptsächlich an das 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 validieren

In Ihren Anwendungsprotokollen oder Cloud Service Mesh-Messwerten können Sie die Fehlerrate von Anfragen an $SERVICE_ENTRY_HOSTNAME prüfen. Es sollten keine Fehler vorhanden sein.

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, das explizit an die Anfrage angehängt wird, 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.