Anthos Service Mesh und Traffic Director heißen jetzt Cloud Service Mesh. Weitere Informationen finden Sie in der Cloud Service Mesh-Übersicht.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Clusterintern zu Istio auf einem neuen Cluster migrieren

In dieser Anleitung wird beschrieben, wie Sie eine Anwendung von einem vorhandenen GKE-Cluster (Google Kubernetes Engine) mit clusterinternem Cloud Service Mesh zu einem neuen GKE-Cluster mit Open-Source-Istio migrieren. Dabei nutzen Sie die Funktionen für Edge-zu-Multi-Cluster-Mesh für eine nahtlose Migration.

Hinweis zur Terminologie: In dieser Anleitung bezieht sich Cloud Service Mesh auf das clusterinterne Cloud Service Mesh von Google und Istio bezieht sich auf das Open-Source-Service-Mesh von Istio.

In dieser Anleitung wird Folgendes beschrieben:

Vorhandenen Cluster mit clusterinternem Cloud Service Mesh für die Migration vorbereiten.
Neuen GKE-Cluster mit Istio bereitstellen.
GKE Multi-Cluster Gateway API auf einem dedizierten Cluster und Multi-Cluster-Dienste konfigurieren, um das Routing zu Mesh-Ingress einzurichten.
Canary-Deployment ausführen, um den Live-HTTP-Traffic zwischen Cloud Service Mesh und Istio aufzuteilen.
Endgültige Umstellung auf Istio abschließen und Ressourcen für clusterinternes Cloud Service Mesh außer Betrieb nehmen.

Canary-Deployment

„Canary-Deployment“ ist eine Technik, die in der Softwareentwicklung verwendet wird, um eine neue Version einer Software oder Infrastruktur zu testen, bevor sie für alle Produktionsnutzer freigegeben wird. Dabei wird der Prozentsatz des Traffics, der an die neue Zielversion weitergeleitet wird, schrittweise erhöht.

In dieser Anleitung richten Sie einen neuen Cluster mit Istio ein und verschieben den Nutzertraffic schrittweise in diesen Cluster. Sie leiten zuerst 0% des Nutzertraffics an den neuen Cluster, dann 50 % und schließlich 100% an den GKE-Cluster mit Istio. In Produktionsumgebungen können Sie kleinere und genauere Schritte verwenden (z. B. 1%, 5%, 10%, 25%, 50%, 100%). Wenn Sie feststellen, dass der neue Cluster Fehler aufweist oder die Leistung nachlässt, können Sie ein sofortiges Rollback ausführen, indem Sie den Traffic-Prozentsatz für den Istio-Cluster wieder auf 0% setzen.

Canary-Steuerungsebene im Vergleich zu Canary-Cluster

Es gibt zwei primäre Strategien für die Migration zwischen Service-Mesh-Steuerungsebenen:

Canary-Clustermigration (empfohlen): Bei dieser Strategie erstellen Sie einen neuen Cluster im selben Google Cloud Projekt und in derselben Flotte wie Ihr vorhandener Cluster, installieren die Ziel-Service-Mesh-Steuerungsebene (Istio) und migrieren Arbeitslasten und eingehenden Traffic zum neuen Cluster.
Migration der Canary-Steuerungsebene (nicht unterstützt): Bei dieser Strategie installieren Sie die neue Steuerungsebene parallel auf demselben Cluster, auf dem die ursprüngliche Steuerungsebene installiert ist. Diese Migrationsmethode wird nicht unterstützt.

In dieser Anleitung folgen Sie der Migrationsstrategie für den Canary-Cluster. Beide Cluster müssen sich im selben Google Cloud Projekt befinden.

Kosten

In dieser Anleitung werden kostenpflichtige Komponenten von Google Cloudverwendet, darunter:

Nach Abschluss dieser Anleitung können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweis

Wählen Sie in der Google Cloud console auf der Seite der Projektauswahl das Google Cloud Projekt aus, in dem Ihr clusterinternes Cloud Service Mesh installiert ist.

Zur Projektauswahl

Melden Sie sich in Ihrem Google Cloud Konto an. Wenn Sie noch kein Konto bei Google Cloudhaben, erstellen Sie ein Konto, um die Leistung unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Verify that billing is enabled for your Google Cloud project.

Enable the required APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

Verify that billing is enabled for your Google Cloud project.

Enable the required APIs, if any are not already enabled.

Roles required to enable APIs

Enable the APIs

Cluster mit clusterinternem Cloud Service Mesh für die Migration vorbereiten

In diesem Abschnitt bereiten Sie Ihren vorhandenen GKE-Cluster mit clusterinternem Cloud Service Mesh für die Migration zu einem GKE-Cluster mit Istio vor.

Prüfen, ob der Cluster mit clusterinternem Cloud Service Mesh ausgeführt wird und für die Migration bereit ist

Prüfen Sie, ob Ihr Cluster mit clusterinternem Cloud Service Mesh GKE_CSM_CLUSTER mit der clusterinternen istiod Steuerungsebene gemäß der Installationsanleitung für clusterinternes Cloud Service Mesh ausgeführt wird.

Führen Sie den folgenden Befehl aus, um den Installationsstatus zu prüfen:
```
kubectl get deployment -A -l app=istiod -L istio.io/rev
```
Die erwartete Ausgabe sieht in etwa so aus:
```
NAMESPACE              NAME                 READY   UP-TO-DATE   AVAILABLE   AGE     REV
ISTIOD_NAMESPACE      istiod-asm-1295-12   2/2     2            2           4d16h   asm-1295-12
```
Prüfen Sie mit dem folgenden Befehl, ob in der istiod-Steuerungsebene Fehler auftreten:
```
kubectl logs -n ISTIOD_NAMESPACE -l app=istiod
```

Cluster für die Migration vorbereiten

Prüfen Sie, ob Workload Identity im Cluster und Knotenpool aktiviert ist.

Hinweis:Wenn Sie Cloud Service Mesh mit asmcli und dem Flag --enable-workload-identity oder --enable-all installiert haben, ist Workload Identity bereits automatisch im Cluster und Knotenpool aktiviert. Sie können diesen Schritt überspringen.

Führen Sie den folgenden Befehl aus, um Workload Identity im Cluster zu prüfen:
```
gcloud container clusters describe "GKE_CSM_CLUSTER" \
    --location="LOCATION" \
    --project="PROJECT_ID" \
    --format="value(workloadIdentityConfig.workloadPool)"
```
Ersetzen Sie GKE_CSM_CLUSTER durch den Namen Ihres vorhandenen Clusters, LOCATION durch den Standort Ihres Clusters und PROJECT_ID durch Ihre Projekt-ID.

Erwartete Ausgabe:
```
PROJECT_ID.svc.id.goog
```
Wenn Workload Identity fehlt, lesen Sie die Anleitung zu Workload Identity , um Ihren Cluster zu aktualisieren.

Prüfen Sie, ob Ihr Cluster in der Flotte registriert ist:

gcloud container clusters describe "GKE_CSM_CLUSTER" \
    --location="LOCATION" \
    --project="PROJECT_ID" \
    --format="yaml(fleet)"

Erwartete Ausgabe für einen registrierten Cluster:

fleet:
  membership: //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/memberships/MEMBERSHIP_NAME

Wenn die Flottendetails leer sind, lesen Sie die Anleitung zur Registrierung der Flottenmitgliedschaft um Ihren Cluster in der Flotte zu registrieren.

Machen Sie Ihre Anwendung über ein Ingress-Gateway verfügbar. Folgen Sie dazu der Anleitung zum Installieren und Aktualisieren von Gateways .

Istio in einem neuen GKE-Cluster installieren

In diesem Abschnitt stellen Sie einen neuen GKE-Cluster mit Open-Source-Istio für die Migrationsstrategie für den Canary-Cluster bereit.

Erstellen Sie einen neuen GKE-Cluster GKE_ISTIO_CLUSTER im selben Google Cloud Projekt (PROJECT_ID) wie Ihr vorhandener Cluster mit clusterinternem Cloud Service Mesh.

Hinweis: Beide Cluster müssen sich im selben Google Cloud Projekt befinden und in derselben Flotte registriert sein. Multi-Cluster-Gateway und Multi-Cluster-Dienste (Multi-Cluster Services, MCS) verwenden eine gemeinsame Flotte im selben Projekt, um Dienstendpunkte (ServiceImport) zu ermitteln und Live-Traffic während der Migration über beide Cluster weiterzuleiten. Diese Konfiguration im selben Projekt ist der offiziell unterstützte Ansatz für diese Migration.

Geben Sie beim Erstellen des Clusters --project an und aktivieren Sie Workload Identity mit --workload-pool=PROJECT_ID.svc.id.goog:
```
gcloud container clusters create GKE_ISTIO_CLUSTER \
    --project=PROJECT_ID \
    --location=LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog
```
Wenn Sie bereits einen Cluster erstellt haben, folgen Sie der Anleitung zu Workload Identity , um Workload Identity zu aktivieren.

Registrieren Sie Ihren Istio-Cluster in der Flotte:

gcloud container fleet memberships register \
    GKE_ISTIO_CLUSTER \
    --gke-cluster=LOCATION/GKE_ISTIO_CLUSTER \
    --enable-workload-identity \
    --location=LOCATION \
    --project=PROJECT_ID

Installieren Sie Istio gemäß der offiziellen Installationsanleitung für Istio . Dabei müssen Ingress-Gateways für eingehenden Traffic bereitgestellt werden. Für eine reibungslosere Migration empfehlen wir, dieselbe Version von Open-Source-Istio zu installieren. Wenn Sie Open-Source-Istio aktualisieren möchten, lesen Sie die Versionshinweise von Istio, um Informationen zu Verhaltensänderungen zu erhalten.

Richten Sie diesen Cluster ein, indem Sie Ihre Anwendungen auf dieselbe Weise wie auf dem GKE-Cluster mit clusterinternem Cloud Service Mesh installieren. In dieser Anleitung wird der Namespace, in dem Ingress-Gateways gehostet werden, als ISTIO_INGRESS_NAMESPACE bezeichnet.
Prüfen Sie, ob der Cluster fehlerfrei ist und Traffic verarbeiten kann. Anwendungsteams müssen bestätigen, dass alle Microservices ordnungsgemäß ausgeführt werden und die Statusprüfungen bestehen, bevor Live-Nutzertraffic weitergeleitet wird.

Multi-Cluster Gateway API auf einem dedizierten Cluster konfigurieren

In diesem Abschnitt konfigurieren Sie einen externen Application Load Balancer (L7XLB) über den GKE Gateway Controller, um Ingress-Traffic zum Mesh zu ermöglichen. Während der Migration empfehlen wir, Gateway API-Ressourcen auf einem dedizierten GKE-Konfigurationscluster bereitzustellen, um den Load Balancer zu verwalten. In dieser Anleitung wird dieser dedizierte Konfigurationscluster als GKE_CONFIG_CLUSTER bezeichnet.

Konfigurationscluster vorbereiten

Bereiten Sie den Konfigurationscluster für das Hosting von Gateway und HTTPRoute APIs vor. Folgen Sie dazu der Anleitung für Multi-Cluster-Gateway .

Dienste mit Multi-Cluster-Diensten exportieren

Exportieren Sie den istio-ingressgateway Dienst in beiden Mesh-Clustern mit ServiceExport. Folgen Sie dazu der Anleitung für Multi-Cluster-Dienste (Multi-Cluster Services, MCS):

Hinweis: Wenn Sie ServiceExport anwenden, stellt der GKE MCS-Controller automatisch Google Cloud Netzwerk-Endpunktgruppen (Network Endpoint Groups, NEGs) für die Ingress-Gateway-Pods bereit.

apiVersion: net.gke.io/v1
kind: ServiceExport
metadata:
  namespace: NAMESPACE
  name: SERVICE_EXPORT_NAME

Gateway API-Ressourcen im Konfigurationscluster bereitstellen

Folgen Sie der Anleitung für Gateway Edge-to-Mesh , um die Ressourcen Gateway und HTTPRoute in Ihrem dedizierten Konfig cluster zu erstellen. Eine Beispielkonfiguration sieht so aus:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: global-gateway
  namespace: CSM_INGRESS_NAMESPACE
spec:
  gatewayClassName: gke-l7-global-external-managed-mc
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: edge-to-mesh-route
  namespace: CSM_INGRESS_NAMESPACE
spec:
  parentRefs:
  - name: global-gateway
  rules:
  - backendRefs:
    # Backend 1: Cloud Service Mesh Cluster (CSM_INGRESS_NAMESPACE namespace)
    - group: net.gke.io
      kind: ServiceImport
      name: istio-ingressgateway
      namespace: CSM_INGRESS_NAMESPACE
      port: 80
      weight: 100

Wenn sich Ihre ServiceImport Ressourcen in einem anderen Namespace als HTTPRoute befinden, verwenden Sie ReferenceGrant , um das Traffic-Routing zwischen Namespaces zu aktivieren:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-csm-ingress-to-ISTIO_INGRESS_NAMESPACE
  namespace: ISTIO_INGRESS_NAMESPACE
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: CSM_INGRESS_NAMESPACE
  to:
  - group: net.gke.io
    kind: ServiceImport

Traffic mit Canary-Deployment migrieren

In diesem Abschnitt verschieben Sie Traffic zum neuen Cluster und schließen die Migration ab.

50% des Traffics zu Istio verschieben

In diesem Abschnitt führen Sie ein Canary-Deployment aus, um Traffic langsam zu migrieren. Weitere Informationen finden Sie in der Anleitung zum Aufteilen von Traffic.

Wenden Sie die benutzerdefinierte Ressource HTTPRoute im Konfigurationscluster an, um Canary-Traffic zum Istio-Cluster aufzuteilen:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: edge-to-mesh-route
  namespace: CSM_INGRESS_NAMESPACE
spec:
  parentRefs:
  - name: global-gateway
  rules:
  - backendRefs:
    # Backend 1: CSM Cluster (CSM_INGRESS_NAMESPACE namespace)
    - group: net.gke.io
      kind: ServiceImport
      name: istio-ingressgateway
      namespace: CSM_INGRESS_NAMESPACE
      port: 80
      weight: 50
    # Backend 2: Istio Cluster (ISTIO_INGRESS_NAMESPACE namespace)
    - group: net.gke.io
      kind: ServiceImport
      name: istio-ingressgateway
      namespace: ISTIO_INGRESS_NAMESPACE
      port: 80
      weight: 50

Validieren Sie die Verteilung des Live-Traffics, indem Sie parallele Anfragen an die öffentliche IP-Adresse des Gateways senden.

Erwartete Ausgabe: Die Antworten werden zwischen GKE_CSM_CLUSTER und GKE_ISTIO_CLUSTER verteilt.

In der Produktion migrieren Sie Traffic wie bereits erwähnt in kleineren Schritten (z. B. 1%, 5%, 10%, 25%, 50%, 100%). Es kann einige Zeit dauern, bis diese Gewichtserhöhungen vollständig an den Load Balancer weitergegeben werden. Prüfen Sie daher, ob der Traffic korrekt aufgeteilt ist, bevor Sie ihn weiter erhöhen.

Migration zum Istio-Cluster abschließen

Prüfen Sie, ob die Anwendung im Istio-Cluster mit Canary-Traffic ordnungsgemäß funktioniert und der gesamte Traffic dorthin verschoben wurde. Nachdem Sie bestätigt haben, dass das Traffic-Routing ordnungsgemäß funktioniert, schließen Sie die Migration ab, indem Sie die Ressource ServiceExport im Cluster mit clusterinternem Cloud Service Mesh löschen:

kubectl --context="GKE_CSM_CLUSTER_CONTEXT" delete serviceexport.net.gke.io istio-ingressgateway -n CSM_INGRESS_NAMESPACE

Der GKE Gateway Controller trennt die Netzwerk Endpunktgruppe (Network Endpoint Group, NEG) des Cloud Service Mesh-Clusters automatisch vom Google Cloud Backend-Dienst des Load Balancers. Der gesamte eingehende Client-Traffic wird nahtlos und ohne Ausfallzeiten zum Istio-Cluster weitergeleitet.

Bereinigen

Wenn Sie vermeiden möchten, dass Ihrem Google Cloud Konto die in dieser Anleitung verwendeten Ressourcen in Rechnung gestellt werden, bereinigen Sie die bereitgestellten Komponenten.

ServiceExport-Ressourcen im Istio-Cluster löschen:

kubectl --context="GKE_ISTIO_CLUSTER_CONTEXT" delete serviceexport.net.gke.io istio-ingressgateway -n ISTIO_INGRESS_NAMESPACE

Registrierung der Flottenmitgliedschaft aufheben:

gcloud container fleet memberships unregister \
    GKE_CSM_CLUSTER \
    --gke-cluster="LOCATION/GKE_CSM_CLUSTER" \
    --project="PROJECT_ID"

Cluster mit clusterinternem Cloud Service Mesh löschen:

gcloud container clusters delete GKE_CSM_CLUSTER \
    --location="LOCATION" \
    --project="PROJECT_ID"

Nächste Schritte

Lesen Sie den Leitfaden zur grundlegenden Architektur: Von Edge zu Multi-Cluster-Mesh: Global verteilte Anwendungen über GKE Gateway und Cloud Service Mesh bereitstellen.
Weitere Informationen zu Multi-Cluster Gateway API-Mustern.
Weitere Informationen zum Multi-Cluster-Load-Balancing.
Dokumentation zur Traffic-Verwaltung im Istio-Mesh