Désinstaller Cloud Service Mesh

Remarque :Ce guide n'est compatible qu'avec Cloud Service Mesh avec les API Istio et non avec les API Google Cloud. Pour en savoir plus, consultez la page Présentation de Cloud Service Mesh.

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

Avertissement :Si vous suivez ces instructions pour désinstaller Cloud Service Mesh, toutes les configurations, quel que soit le type de plan de contrôle (en cluster ou géré), sont supprimées.

Désinstaller Cloud Service Mesh

Utilisez les commandes suivantes pour désinstaller tous les composants de Cloud Service Mesh. Ces commandes suppriment l'espace de noms istio-system et toutes les définitions de ressources personnalisées (CRD, Custom Resource Definition), y compris celles que vous avez appliquées.

Avertissement :Si vous avez créé des objets CRD, assurez-vous d'en avoir des copies avant de suivre les étapes suivantes.

1. 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.

2. Désactivez la gestion automatique sur ce cluster (que vous l'ayez appliquée directement ou à l'aide de la configuration par défaut du parc):

     gcloud container fleet mesh update \
        --management manual \
        --memberships MEMBERSHIP_NAME \
        --project FLEET_PROJECT_ID \
        --location MEMBERSHIP_LOCATION
   

   Remplacez les éléments suivants :

   • MEMBERSHIP_NAME est le nom d'appartenance indiqué lorsque vous avez vérifié que votre cluster était enregistré dans le parc.
   • MEMBERSHIP_LOCATION est le lieu de votre adhésion (une région ou global).

3. 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 libellés 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 aucun des libellés istio.io/rev ou istio-injection, l'injection automatique n'était pas activée sur l'espace de noms.

4. Redémarrez vos charges de travail comportant des side-cars injectés pour supprimer les proxys.

5. Si vous utilisez le maillage de services Cloud géré, vérifiez quelle implémentation de plan de contrôle vous avez dans votre cluster. Cela vous aidera à supprimer les ressources pertinentes dans les étapes suivantes.

6. Si vous utilisez le maillage de services Cloud géré, supprimez toutes les ressources controlplanerevision du cluster:

   kubectl delete controlplanerevision asm-managed asm-managed-rapid asm-managed-stable -n istio-system --ignore-not-found=true
   

7. Supprimez les webhooks de votre cluster, s'ils existent.

   Maillage de services cloud dans le cluster

   Supprimez validatingwebhooksconfiguration et mutatingwebhookconfiguration.

   kubectl delete validatingwebhookconfiguration,mutatingwebhookconfiguration -l operator.istio.io/component=Pilot
   

   Maillage de services cloud géré

   A. Supprimez validatingwebhooksconfiguration.

   kubectl delete validatingwebhookconfiguration istiod-istio-system-mcp
   

   B. Tout supprimer (mutatingwebhookconfiguration).

   Remarque : Utilisez l'option RELEASE_CHANNEL en fonction de la version disponible que vous avez configurée. Par exemple, standard(istiod-asm-managed), rapide (istiod-asm-managed-rapid) et stable (istiod-asm-managed-stable).

   kubectl delete mutatingwebhookconfiguration istiod-RELEASE_CHANNEL
   

8. 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 du cluster, exécutez la commande suivante:

   istioctl x uninstall --purge
   

   S'il n'existe aucun autre plan 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.

9. Supprimez les espaces de noms istio-system et asm-system :

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

10. 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
     asm-system           Terminating  71m
    

11. Si vous supprimez vos clusters, ou si vous les avez déjà supprimés, assurez-vous que chaque cluster est annulé dans votre parc.

12. 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 la désinstallation n'est effectuée que pour 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.

13. Si vous utilisez le maillage de services Cloud géré, supprimez le déploiement mdp-controller:

     kubectl delete deployment mdp-controller -n kube-system
    

14. Si vous utilisez un maillage de services Cloud géré et que vous disposez de l'implémentation du plan de contrôle TRAFFIC_DIRECTOR, nettoyez les ressources de vérification de l'état transparente. Normalement, elles sont supprimées automatiquement, mais vous pouvez vous assurer qu'elles le sont en procédant comme suit:

    A. Supprimez le daemonset snk.

     kubectl delete daemonset snk -n kube-system
    

    B. Supprimez la règle de pare-feu.

     gcloud compute firewall-rules delete gke-csm-thc-FIRST_8_CHARS_OF_CLUSTER_ID
    

    Remplacez les éléments suivants :

    • FIRST_8_CHARS_OF_CLUSTER_ID correspond aux huit premiers caractères de l'ID de cluster pour votre cluster spécifique.

15. Vérifiez si le ConfigMap istio-cni-plugin-config est présent:

     kubectl get configmap istio-cni-plugin-config -n kube-system
    

    Le cas échéant, supprimez le ConfigMap istio-cni-plugin-config:

     kubectl delete configmap istio-cni-plugin-config -n kube-system
    

    Avertissement :La fiabilité du réseau de votre cluster GKE peut être affectée si vous ne supprimez pas ce ConfigMap.

16. Supprimez le daemonset istio-cni-node:

     kubectl delete daemonset istio-cni-node -n kube-system
    

17. Si vous désinstallez le maillage de services Cloud Service géré et que vous conservez votre cluster, contactez l'assistance pour vous assurer que toutes les ressources Google Cloud sont nettoyées. Si vous ne suivez pas cette étape, vous pouvez également recréer l'espace de noms istio-system et les mappages de configuration.

Une fois ces étapes terminées, tous les composants de Cloud Service Mesh, y compris les proxys, les autorités de certification de cluster, ainsi que les rôles et liaisons RBAC, sont systématiquement supprimés du cluster. Au cours du processus d'installation, un compte de service appartenant à Google se voit accorder 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.