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 ancienne avec plusieurs plans de contrôle provisionnés, le fait de suivre ces instructions supprimera 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 disposent de plans de contrôle gérés par asmcli --managed ou par l'API Mesh le sont. 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 possible si un élément est listé dans la sortie.

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 de requête 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, 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 multicluster si d'autres clusters exécutent la découverte de 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 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-
```
2. 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-
```
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 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.

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 de l'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 (une région ou global).

Vérifiez que l'état de l'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 dans 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 fichier de configuration istio-(révision), le fichier de configuration 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 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 (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 vous utilisez Certificate Authority Service, supprimez les autorisations et le pool d'autorités de certification créés lors de la configuration de Certificate Authority Service pour Managed Cloud Service Mesh.
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 que depuis 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.