Istio ServiceEntry zu GCPBackend für Compute Engine-VMs 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. Endpunkterkennung: VM-Endpunkte im Backend-Dienst werden automatisch aktualisiert, wenn VM-Instanzen hinzugefügt oder entfernt werden.
  2. Zentrale Systemdiagnose: VM-Endpunkte werden auf Fehlerfreiheit geprü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.24/docs/service-routing/advanced-load-balancing-overview und https://cloud.google.com/service-mesh/v1.24/docs/service-routing/advanced-load-balancing-overview.
  4. Nahtlose Migration: Mit Traffic-Aufteilung und ‑Spiegelung können Sie Traffic sicher migrieren, ohne die Anwendung zu unterbrechen.
  5. 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 die Compute Engine-VM 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 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.