Istio-ServiceEntry zu GCPBackend für Compute Engine-VMs 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. Endpunktermittlung: VM-Endpunkte im Backend-Dienst werden automatisch aktualisiert, wenn VM-Instanzen hinzugefügt oder entfernt werden.
  2. Zentrale Systemdiagnose: VM-Endpunkte werden auf Fehler überprüft und der Traffic wird automatisch von fehlerhaften zu fehlerfreien Back-Ends weitergeleitet.
  3. Globales Load-Balancing und erweiterte Load-Balancing-Algorithmen: VM-Endpunkte können in mehreren Regionen bereitgestellt werden. Mit unseren Load-Balancing-Algorithmen können Sie das Load-Balancing-Verhalten in diesen Regionen konfigurieren. Weitere Informationen finden Sie unter https://cloud.google.com/service-mesh/v1.25/docs/service-routing/advanced-load-balancing-overview und https://cloud.google.com/service-mesh/v1.25/docs/service-routing/advanced-load-balancing-overview.
  4. Nahtlose Migration: Nutzen Sie Trafficaufteilung und -spiegelung, um Traffic sicher zu migrieren, ohne die Anwendung zu unterbrechen.
  5. 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 Istio-ServiceEntry.
  3. Eine GCPBackend-Ressource für die Compute Engine-VM konfiguriert.

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 vom ServiceEntry zum 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: 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

Dabei gilt:

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