Clusterinternes Cloud Service Mesh deinstallieren

Auf dieser Seite wird beschrieben, wie Sie Cloud Service Mesh im Cluster deinstallieren, wenn Sie die Istio-APIs verwenden. Wenn Sie Compute Engine APIs verwenden, sind keine Schritte erforderlich. Informationen zu den Unterschieden finden Sie in der Cloud Service Mesh-Übersicht.

Wenn Sie dieser Anleitung zum Deinstallieren von clusterinternem Cloud Service Mesh folgen, werden alle Konfigurationen entfernt.

Wenn Sie verwaltetes Cloud Service Mesh deinstallieren, folgen Sie stattdessen der Anleitung zur verwalteten Deinstallation.

Wenn Sie von einem clusterinternen zu einem verwalteten Controller migrieren, folgen Sie stattdessen der Migrationsanleitung.

Auswirkungen des Entfernens von Cloud Service Mesh

Bevor Sie Cloud Service Mesh deinstallieren, sollten Sie sich überlegen, welche Funktionen aus Ihrem Cluster und Ihren Arbeitslasten entfernt werden. Wenn Sie Cloud Service Mesh-Proxys aus Ihren Arbeitslasten entfernen und sie neu starten, kehren Ihre Anwendungen zum standardmäßigen Kubernetes-Netzwerkverhalten zurück.

Sicherheit

Wenn Sie Cloud Service Mesh entfernen, gehen die folgenden Sicherheitsfunktionen verloren:

  • Verschlüsselung mit gegenseitigem TLS (mTLS): Der Traffic zwischen Diensten wird nicht mehr mit vom Mesh verwalteten mTLS-Zertifikaten verschlüsselt.
  • Autorisierungsrichtlinien: Die benutzerdefinierten Mesh-Ressourcen AuthorizationPolicy werden nicht mehr erzwungen. Sie müssen Kubernetes-NetworkPolicy-Ressourcen oder die Authentifizierung und Autorisierung auf Anwendungsebene konfigurieren, um den Traffic einzuschränken.

Beobachtbarkeit

Wenn Sie Cloud Service Mesh entfernen, gehen die folgenden Observability-Funktionen verloren:

  • Telemetrie und Messwerte: Die automatische Erfassung von Layer 7-Messwerten (z. B. Anfrageraten, Fehlerraten und Latenz) wird beendet. Mesh-Telemetrie wird nicht mehr automatisch in Cloud Monitoring aufgenommen. Standard-GKE-Messwerte sind nicht betroffen.
  • Dashboards und SLOs: Vorkonfigurierte Cloud Service Mesh-Dashboards und SLO-Monitoring (Service Level Objective) in derGoogle Cloud Console werden nicht mehr mit Daten gefüllt.
  • Zugriffsprotokollierung und ‑tracing: Sidecar-Proxy-Zugriffsprotokolle mit Client-mTLS-Identitäten und automatisierten verteilten Traces werden nicht mehr generiert.

Service Discovery und Netzwerkresilienz

Wenn Sie Cloud Service Mesh entfernen, gehen die folgenden Netzwerk- und Resilienzfunktionen verloren:

  • Netzwerkresilienz: Arbeitslasten verlieren Resilienzfunktionen auf Sidecar-Ebene, einschließlich automatischer Wiederholungsversuche, konfigurierbarer Zeitüberschreitungen für Anfragen, Leistungsschaltern, Ausreißererkennung und Verwaltung von Verbindungspools. Anwendungen müssen Verbindungsfehler und Wiederholungsversuche direkt verwalten.
  • Multi-Cluster Service Discovery: Die clusterübergreifende Endpunkterkennung und das Routing über mehrere Cluster in einer Flotte funktionieren nicht mehr über das Mesh. Dienste können Endpunkte nur in ihrem lokalen Cluster über Standard-DNS erkennen.

Cloud Service Mesh deinstallieren

Mit den folgenden Befehlen können Sie alle Cloud Service Mesh-Komponenten deinstallieren.

  1. So verhindern Sie eine Unterbrechung des Anwendungstraffics:

    • Führen Sie ein Downgrade aller STRICT mTLS-Richtlinien auf PERMISSIVE aus.
    • Entfernen Sie alle AuthorizationPolicy, die den Traffic blockieren können.

  2. Deaktivieren Sie die automatische Sidecar-Einfügung für Ihre Namespaces, sofern sie aktiviert ist. Führen Sie den folgenden Befehl aus, um Namespace-Labels aufzurufen:

     kubectl get namespace YOUR_NAMESPACE --show-labels

    Die Ausgabe sieht etwa so aus:

     NAME   STATUS   AGE     LABELS
 demo   Active   4d17h   istio.io/rev=asm-181-5

    Wenn in der Ausgabe unter der Spalte LABELS istio.io/rev= angezeigt wird, entfernen Sie dies:

     kubectl label namespace YOUR_NAMESPACE istio.io/rev-

    Wenn in der Ausgabe unter der Spalte LABELS istio-injection angezeigt wird, entfernen Sie dies:

     kubectl label namespace YOUR_NAMESPACE istio-injection-

    Wenn Sie weder die Labels istio.io/rev noch istio-injection sehen, wurde die automatische Einfügung im Namespace nicht aktiviert.

  3. Starten Sie Ihre Arbeitslasten mit eingefügten Sidecar-Dateien neu, um die Proxys zu entfernen.

  4. Löschen Sie die validatingwebhooksconfiguration- und mutatingwebhookconfiguration-Ressourcen aus Ihrem Cluster, sofern vorhanden:

      kubectl delete validatingwebhookconfiguration,mutatingwebhookconfiguration -l operator.istio.io/component=Pilot,istio.io/owned-by!=mesh.googleapis.com

  5. Sobald alle Arbeitslasten gestartet und keine Proxys beobachtet wurden, können Sie die Steuerungsebene im Cluster sicher löschen, um die Abrechnung zu beenden.

    Führen Sie den folgenden Befehl aus, um die clusterinterne Steuerungsebene zu entfernen:

    istioctl uninstall --purge

    Wenn keine anderen Steuerungsebenen vorhanden sind, können Sie den Namespace istio-system löschen, um alle Cloud Service Mesh-Ressourcen zu entfernen. Löschen Sie andernfalls die Dienste, die den Überarbeitungen von Cloud Service Mesh entsprechen. Dadurch werden freigegebene Ressourcen wie CRDs nicht gelöscht.

  6. Optional: Entfernen Sie Istio-CRs, Istio-CRDs, die ConfigMap „istio-(revision)“, die ConfigMap „asm-options“ sowie die Namespaces istio-system und asm-system, um das Service Mesh aus dem Cluster zu entfernen oder in einem anderen Istio-API-kompatiblen Service Mesh zu verwenden.

    1. Istio-CRs entfernen:

      kubectl delete gateways,virtualservices,destinationrules,serviceentries,envoyfilters,sidecars,peerauthentications,requestauthentications,authorizationpolicies,telemetries,wasmplugins,proxyconfigs --all --all-namespaces

    2. Entfernen Sie Istio-CRDs:

      kubectl get crds -o name | grep --color=never 'istio.io' | xargs kubectl delete

    3. Entfernen Sie die ConfigMap „istio-(revision)“. Sie können diesen Schritt überspringen, wenn Sie den Namespace istio-system löschen.

      kubectl delete configmap istio-RELEASE_CHANNEL -n istio-system

      Ersetzen Sie RELEASE_CHANNEL durch Ihre Release-Version.

    4. Entfernen Sie den Namespace istio-system:

      kubectl delete namespace istio-system --ignore-not-found=true

    5. Entfernen Sie den Namespace asm-system:

      kubectl delete namespace asm-system --ignore-not-found=true

      1. Prüfen Sie, ob die Löschvorgänge erfolgreich waren:

         kubectl get ns
 ```

The output should indicate a `Terminating` state and return as shown,
otherwise you might have to manually delete any remaining resources in
the namespaces and try again.

```sh
 NAME                 STATUS       AGE
 istio-system         Terminating  71m
 asm-system           Terminating  71m
 ```

  7. Wenn Sie Ihre Cluster löschen oder bereits gelöscht haben, müssen Sie dafür sorgen, dass die Registrierung jedes Clusters bei Ihrer Flotte aufgehoben wird.

  8. Wenn Sie Cloud Service Mesh auf Flottenebene nicht mehr verwenden möchten, deaktivieren Sie das Service Mesh-Feature für Ihr Flotten-Hostprojekt.

     gcloud container hub mesh disable --project FLEET_PROJECT_ID

    Dabei ist FLEET_PROJECT_ID die ID des Flotten-Hostprojekts.

Nachdem Sie diese Schritte ausgeführt haben, werden alle Cloud Service Mesh-Komponenten, einschließlich Proxys, clusterinterner Zertifizierungsstellen sowie RBAC-Rollen und ‑Bindungen, systematisch aus dem Cluster entfernt. Während der Installation wird einem Google-eigenen Dienstkonto die erforderlichen Berechtigungen zum Einrichten der Service Mesh-Ressourcen im Cluster gewährt. Durch diese Deinstallationsanleitung werden diese Berechtigungen nicht widerrufen, sodass Cloud Service Mesh in Zukunft nahtlos reaktiviert werden kann.