Anthos Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Désinstaller Cloud Service Mesh intégré au cluster

Attention : Le plan de contrôle ISTIOD pour Cloud Service Mesh dans un cluster sur GKE sur Google Cloud est obsolète. Cloud Service Mesh avec un plan de contrôle intégré au cluster sur Google Distributed Cloud (logiciel uniquement) reste compatible, comme décrit dans Plates-formes compatibles.

Cette page explique comment désinstaller Cloud Service Mesh dans le cluster si vous utilisez les API Istio. Si vous utilisez les API Compute Engine, aucune étape n'est nécessaire. Pour comprendre les différences, consultez la présentation de Cloud Service Mesh.

Suivez ces instructions pour désinstaller Cloud Service Mesh dans le cluster et supprimer toutes les configurations.

Si vous désinstallez Cloud Service Mesh géré, suivez plutôt le guide de désinstallation gérée.

Si vous effectuez une migration depuis un déploiement au sein du cluster, suivez plutôt le guide de migration.

Impact de la suppression de Cloud Service Mesh

Avant de désinstaller Cloud Service Mesh, réfléchissez aux fonctionnalités qui seront supprimées de votre cluster et de vos charges de travail. Lorsque vous supprimez les proxys Cloud Service Mesh de vos charges de travail et que vous les redémarrez, vos applications reviennent au comportement de mise en réseau Kubernetes standard.

Sécurité

Lorsque vous supprimez Cloud Service Mesh, vous perdez les fonctionnalités de sécurité suivantes :

Chiffrement TLS mutuel (mTLS) : le trafic entre les services n'est plus chiffré en transit avec les certificats mTLS gérés par le maillage.
Règles d'autorisation : les ressources personnalisées AuthorizationPolicy de Mesh ne sont plus appliquées. Vous devez configurer des ressources NetworkPolicy Kubernetes ou l'authentification et l'autorisation au niveau de l'application pour limiter le trafic.

Observabilité

Lorsque vous supprimez Cloud Service Mesh, vous perdez les fonctionnalités d'observabilité suivantes :

Télémétrie et métriques : la collecte automatique des métriques de couche 7 (comme les taux de requêtes, les taux d'erreur et la latence) s'arrête. La télémétrie du maillage n'est plus ingérée automatiquement dans Cloud Monitoring. Les métriques GKE standards ne sont pas affectées.
Tableaux de bord et SLO : les tableaux de bord Cloud Service Mesh préconfigurés et la surveillance des objectifs de niveau de service (SLO) dans la consoleGoogle Cloud ne sont plus renseignés.
Journalisation et traçage des accès : les journaux d'accès au proxy side-car avec les identités mTLS du client et les traces distribuées automatisées ne sont plus générés.

Découverte des services et résilience du réseau

Lorsque vous supprimez Cloud Service Mesh, vous perdez les fonctionnalités de mise en réseau et de résilience suivantes :

Résilience du réseau : les charges de travail perdent les fonctionnalités de résilience au niveau du side-car, y compris les nouvelles tentatives automatiques, les délais d'expiration des requêtes configurables, les disjoncteurs, la détection des valeurs aberrantes et la gestion du pool de connexions. Les applications doivent gérer directement les échecs de connexion et les tentatives de reconnexion.
Découverte des services multiclusters : la découverte des points de terminaison et le routage entre clusters dans un parc ne fonctionnent plus via le maillage. Les services ne peuvent découvrir les points de terminaison que dans leur cluster local à l'aide du DNS standard.

Désinstaller Cloud Service Mesh

Exécutez les commandes suivantes pour désinstaller tous les composants Cloud Service Mesh.

Pour éviter toute interruption du trafic de l'application :
- Revenez aux règles mTLS STRICT en PERMISSIVE.
- Supprimez toute règle AuthorizationPolicy susceptible de bloquer le trafic.
Si l'injection side-car automatique sur vos espaces de noms est activée, désactivez-la. Exécutez la commande suivante pour afficher les étiquettes d'espace de noms :
```
 kubectl get namespace YOUR_NAMESPACE --show-labels
```
Le résultat ressemble à ce qui suit :
```
 NAME   STATUS   AGE     LABELS
 demo   Active   4d17h   istio.io/rev=asm-181-5
```
Si l'élément istio.io/rev= apparaît dans le résultat sous la colonne LABELS, supprimez-le :
```
 kubectl label namespace YOUR_NAMESPACE istio.io/rev-
```
Si l'élément istio-injection apparaît dans le résultat sous la colonne LABELS, supprimez-le :
```
 kubectl label namespace YOUR_NAMESPACE istio-injection-
```
Si vous ne voyez aucune des étiquettes istio.io/rev ou istio-injection, l'injection automatique n'était pas activée sur l'espace de noms.

Remarque : Vous devez également vérifier si des ressources telles que les déploiements, les StatefulSets, les ReplicaSets, les DaemonSets, les Jobs et les CronJobs sont injectées.
Redémarrez vos charges de travail comportant des side-cars injectés pour supprimer les proxys.

Supprimez validatingwebhooksconfiguration et mutatingwebhookconfiguration de votre cluster, s'ils existent :

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

Une fois que toutes les charges de travail sont accessibles et qu'aucun proxy n'est observé, vous pouvez supprimer le plan de contrôle au sein du cluster en toute sécurité pour arrêter la facturation.

Pour supprimer le plan de contrôle au sein du cluster, exécutez la commande suivante :
```
istioctl uninstall --purge
```
S'il n'y a pas d'autres plans de contrôle, vous pouvez supprimer l'espace de noms istio-system pour vous débarrasser de toutes les ressources Cloud Service Mesh. Sinon, supprimez les services correspondant aux révisions de Cloud Service Mesh. Cela permet d'éviter la suppression de ressources partagées, telles que les CRD.

Vous pouvez également supprimer les CR Istio, les CRD Istio, le configmap istio-(révision), le configmap asm-options, ainsi que les espaces de noms istio-system et asm-system pour supprimer le maillage de services du cluster ou les utiliser dans un autre maillage de services compatible avec l'API Istio.

Supprimez les CR Istio :

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

Supprimez les CRD Istio :

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

Supprimez le fichier de configuration istio-(révision). Vous pouvez ignorer cette étape si vous supprimez l'espace de noms istio-system.
```
kubectl delete configmap istio-RELEASE_CHANNEL -n istio-system
```
Remplacez RELEASE_CHANNEL par votre version disponible.

Supprimez l'espace de noms istio-system :

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

Supprimez l'espace de noms asm-system :

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

Vérifiez si les suppressions ont réussi :

 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
 ```

Si vous supprimez vos clusters ou si vous les avez déjà supprimés, assurez-vous que chacun d'eux est non enregistré dans votre parc.
Si vous prévoyez d'arrêter d'utiliser Cloud Service Mesh au niveau du parc, désactivez la fonctionnalité de maillage de services pour votre projet hôte de parc.
```
 gcloud container hub mesh disable --project FLEET_PROJECT_ID
```
Où FLEET_PROJECT_ID est l'ID de votre projet hôte de parc.

Une fois ces étapes effectuées, tous les composants Cloud Service Mesh, y compris les proxys, les autorités de certification intégrées au cluster, ainsi que les rôles et liaisons RBAC, sont systématiquement supprimés du cluster. Lors du processus d'installation, un compte de service appartenant à Google reçoit les autorisations nécessaires pour établir les ressources du maillage de services dans le cluster. Ces instructions de désinstallation ne révoquent pas ces autorisations, ce qui permet de réactiver facilement Cloud Service Mesh à l'avenir.