Istio ServiceEntry zu GCPBackend für Compute Engine-VMs 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. Endpunkterkennung: VM-Endpunkte im Backend-Dienst werden automatisch aktualisiert, wenn VM-Instanzen hinzugefügt oder entfernt werden.
  2. Zentrale Systemdiagnose: VM-Endpunkte werden geprüft und 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 für diese Regionen konfigurieren. Weitere Informationen finden Sie unter https://cloud.google.com/service-mesh/docs/service-routing/advanced-load-balancing-overview und https://cloud.google.com/service-mesh/docs/service-routing/advanced-load-balancing-overview.
  4. Nahtlose Migration: Mithilfe der Traffic-Aufteilung und -Spiegelung können Sie Traffic sicher migrieren, ohne die Anwendung zu beeinträchtigen.
  5. 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. Ein Istio-Diensteintrag.
  3. Konfigurierte GCPBackend-Ressource für Compute Engine-VM.

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: 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 Name des Namespace.

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 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, um die Fehlerrate von Anfragen an $SERVICE_ENTRY_HOSTNAME zu prüfen. 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 an die GCPBackend API weitergeleitet wird, ist kein explizit an die Anfrage angehängtes 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.