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 géré

Cette page explique comment désinstaller Cloud Service Mesh géré. Si vous désinstallez Cloud Service Mesh intégré au cluster, suivez plutôt le guide de désinstallation intégré au cluster.

Si vous utilisez une configuration héritée avec plusieurs plans de contrôle provisionnés, le suivi de ces instructions supprime tous les plans de contrôle provisionnés.

Les plans de contrôle gérés par asmcli ne sont pas compatibles avec la désinstallation, mais les clusters qui comportent des plans de contrôle gérés par asmcli --managed ou par l'API Mesh sont compatibles. Si vous n'êtes pas sûr du plan de contrôle, exécutez la commande suivante :

kubectl get controlplanerevisions -n istio-system -l 'app.kubernetes.io/created-by!=asmcli'

La désinstallation est compatible si un élément est listé dans la sortie.

Désinstaller Cloud Service Mesh

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

Pour éviter toute interruption du trafic de l'application, procédez comme suit :
- Revenez aux règles mTLS STRICT en PERMISSIVE.
- Supprimez toute règle AuthorizationPolicy susceptible de bloquer le trafic.
Désactivez le multi-cluster si d'autres clusters exécutent la découverte des points de terminaison sur le cluster que vous désinstallez.
```
kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"manual"}}'
```
Recherchez les secrets nécessitant un nettoyage, puis supprimez-les :
```
kubectl get secrets -n istio-system -l istio/multiCluster=true
```
```
kubectl delete secret SECRET_NAME
```
Où SECRET_NAME est le nom du secret. Répétez cette étape pour chaque secret listé.
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
```
1. Si istio.io/rev= s'affiche dans le résultat sous la colonne LABELS, supprimez-le :
```
 kubectl label namespace YOUR_NAMESPACE istio.io/rev-
```
2. Si istio-injection s'affiche dans le résultat sous la colonne LABELS, supprimez-le :
```
 kubectl label namespace YOUR_NAMESPACE istio-injection-
```
3. 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 les ressources, y compris les déploiements, les StatefulSets, les ReplicaSets, les DaemonSets, les tâches et les CronJobs, pour l'injection.
Redémarrez vos charges de travail comportant des side-cars injectés pour supprimer les proxys.

Vérifiez qu'aucun proxy n'est connecté au plan de contrôle géré :

  kubectl get pods --all-namespaces -o json | jq -r '
  .items[] |
  select(
     .spec.containers[].env[]? |
     select(.name == "PROXY_CONFIG" and (.value | contains("\"discoveryAddress\":\"meshconfig.googleapis.com:443\"")))
  ) |
  "\(.metadata.namespace)\t\(.metadata.name)"
  '

Mettez à jour la gestion de la spécification d'appartenance à la fonctionnalité de réseau maillé sur not-installed :
```
 gcloud alpha container fleet mesh update \
   --project FLEET_PROJECT_ID \
   --memberships MEMBERSHIP_NAME \
   --location MEMBERSHIP_LOCATION \
   --management not-installed
```
Remplacez les éléments suivants :
- MEMBERSHIP_NAME est le nom d'appartenance indiqué après avoir vérifié que votre cluster était enregistré dans le parc.
- MEMBERSHIP_LOCATION correspond à l'emplacement de votre abonnement (soit une région, soit global).

Vérifiez que l'état d'appartenance à la fonctionnalité de maillage pour l'état du plan de contrôle est DISABLED.

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Le résultat est semblable à :

 servicemesh:
   controlPlaneManagement:
     details:
     - code: DISABLED
       details: Control Plane Management is not enabled.
     state: DISABLED
   dataPlaneManagement:
     details:
     - code: DISABLED
       details: Data Plane Management is not enabled.
     state: DISABLED
 state:
   description: 'Please see https://cloud.google.com/service-mesh/docs/install for instructions to onboard to Anthos Service Mesh.'
...

Si l'état du plan de contrôle est DEPROVISIONING, vérifiez à nouveau après quelques minutes.

Si l'état du plan de contrôle est STALLED, la désinstallation est bloquée en raison d'une condition d'erreur interne. Si le problème persiste, contactez l'assistance.

Vous pouvez également supprimer les CR Istio, les CRD Istio, le ConfigMap istio-(revision), le ConfigMap asm-options et l'espace de noms istio-system pour supprimer le maillage de services du cluster ou les utiliser dans un autre maillage de services compatible avec l'API Istio.
1. Supprimez les CR Istio :
```
kubectl delete gateways,virtualservices,destinationrules,serviceentries,envoyfilters,sidecars,peerauthentications,requestauthentications,authorizationpolicies,telemetries,wasmplugins,proxyconfigs --all --all-namespaces
```
2. Supprimez les CRD Istio :
```
kubectl get crds -o name | grep --color=never 'istio.io' | xargs kubectl delete
```
3. Supprimez le ConfigMap istio-(revision). 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 (asm-managed, asm-managed-stable ou asm-managed-rapid).
4. Supprimez le ConfigMap asm-options :
```
kubectl delete configmap asm-options -n istio-system
```
5. Supprimez l'espace de noms istio-system :
```
kubectl delete namespace istio-system --ignore-not-found=true
```
6. Vérifiez si les suppressions ont réussi :
```
kubectl get ns
```
  L'état Terminating et le résultat ci-dessous doivent s'afficher dans la sortie. Sinon, vous devrez peut-être supprimer manuellement toutes les ressources restantes dans les espaces de noms, puis réessayer.
```
NAME                 STATUS       AGE
istio-system         Terminating  71m
```
Si le CNI géré était activé sur votre cluster(par défaut pour les installations modernes), nettoyez les ressources CNI :
- Clusters standards : recherchez et supprimez le ConfigMap istio-cni-plugin-config :
  1. Vérifiez si le ConfigMap istio-cni-plugin-config est présent :
```
   kubectl get configmap istio-cni-plugin-config -n kube-system
```
  2. Si le ConfigMap istio-cni-plugin-config est présent, supprimez-le :
```
   kubectl delete configmap istio-cni-plugin-config -n kube-system
```
    Attention : La suppression de ce ConfigMap est nécessaire pour éviter les échecs d’initialisation du réseau sur les nœuds nouveaux ou recyclés.
- Clusters Autopilot : GKE Autopilot limite les modifications apportées aux ressources dans l'espace de noms kube-system. Si vous conservez votre cluster Autopilot après avoir désinstallé Cloud Service Mesh géré, contactez l'assistance pour qu'elle supprime le istio-cni-plugin-config ConfigMap de kube-system.
Si vous utilisez Certificate Authority Service, nettoyez les autorisations et le pool d'autorités de certification créés lors de la configuration de Certificate Authority Service pour Cloud Service Mesh géré.
Si vous avez activé la configuration par défaut du parc Cloud Service Mesh géré et que vous souhaitez la désactiver pour les futurs clusters, désactivez-la. Vous pouvez ignorer cette étape si vous ne désinstallez qu'à partir d'un seul cluster.
```
 gcloud container hub mesh disable --fleet-default-member-config --project FLEET_PROJECT_ID
```
Où FLEET_PROJECT_ID est l'ID de votre projet hôte de 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, 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.