Migration à base de version Canary vers Mesh CA

La migration vers l'autorité de certification Cloud Service Mesh (Mesh CA) depuis l'autorité de certification Istio (également appelée Citadel) nécessite la migration de la racine de confiance. Avant la version 1.10 de Cloud Service Mesh, si vous vouliez migrer d'Istio sur Google Kubernetes Engine (GKE) vers Cloud Service Mesh avec Mesh CA, vous deviez planifier un temps d'arrêt, car Cloud Service Mesh ne pouvait pas charger plusieurs certificats racines. Par conséquent, lors de la migration, les charges de travail nouvellement déployées approuvent le nouveau certificat racine, tandis que d'autres font confiance à l'ancien certificat racine. Les charges de travail utilisant des certificats signés par des certificats racine différents ne peuvent pas s'authentifier entre elles. Cela signifie que le trafic TLS mutuel (mTLS) est interrompu pendant la migration. L'ensemble du cluster n'est complètement rétabli que lorsque le plan de contrôle et toutes les charges de travail de tous les espaces de noms sont redéployés avec le certificat de Mesh CA. Si votre maillage comporte plusieurs clusters avec des charges de travail qui envoient des requêtes aux charges de travail d'un autre cluster, toutes les charges de travail de ces clusters doivent également être mises à jour.

Suivez les étapes décrites dans ce guide pour les cas d'utilisation suivants :

  • Migrer depuis Istio sur GKE vers le plan de contrôle au sein du cluster 1.19.10-asm.9 Cloud Service Mesh avec Mesh CA.
  • Passer de Cloud Service Mesh 1.15 or a 1.16 patch release avec Istio CA au plan de contrôle au sein du cluster Cloud Service Mesh 1.19.10-asm.9 avec Mesh CA.

Limites

  • Tous les clusters GKE doivent appartenir au même projet Google Cloud.

Prérequis

Suivez les étapes de la page Installer les outils dépendants et valider le cluster pour effectuer les opérations suivantes :

Outils requis

Pendant la migration, vous exécutez un outil fourni par Google, migrate_ca, pour valider les éléments suivants pour chaque pod du cluster :

  • Le certificat racine pour Istio CA et Mesh CA.
  • Le certificat mTLS de charge de travail émis par Istio CA et par Mesh CA.
  • Les domaines de confiance configurés par Istio CA et Mesh CA.

Cet outil comporte les dépendances suivantes :

  • awk
  • grep
  • istioctl L'exécution de asmcli install télécharge la version de istioctl qui correspond à la version de Cloud Service Mesh que vous installez.
  • jq
  • kubectl
  • openssl

Présentation de la migration

Pour migrer vers Mesh CA, suivez le processus de migration basé sur la révision (également appelé "mise à niveau Canary"). Avec une migration basée sur la révision, une nouvelle révision de plan de contrôle est déployée en même temps que le plan de contrôle existant. Vous transférez ensuite progressivement vos charges de travail vers la nouvelle révision, ce qui vous permet de surveiller l'effet de la migration tout au long du processus. Au cours du processus de migration, l'authentification et l'autorisation sont entièrement fonctionnelles entre les charges de travail utilisant l'autorité de certification Mesh et les charges de travail utilisant l'autorité de certification Istio.

Voici un aperçu de la migration vers Mesh CA :

  1. Distribuez la racine de confiance de Mesh CA.

    1. Installez une nouvelle révision de plan de contrôle qui utilise l'autorité de certification Istio avec une option permettant de distribuer la racine de confiance de Mesh CA.

    2. Migrez les charges de travail vers le nouveau plan de contrôle, espace de noms par espace de noms, et testez votre application. Lorsque toutes les charges de travail sont correctement transférées vers le nouveau plan de contrôle, supprimez l'ancien plan de contrôle.

  2. Migrez vers Mesh CA. Maintenant que tous les proxys side-car sont configurés avec l'ancienne racine de confiance et la racine de confiance de Mesh CA, vous pouvez migrer vers Mesh CA sans temps d'arrêt. Encore une fois, vous suivez le processus de migration basé sur la révision :

    1. Installez une révision de plan de contrôle avec Mesh CA activé.

    2. Migrez les charges de travail vers la nouvelle révision de plan de contrôle, espace de noms par espace de noms, et testez votre application. Lorsque toutes les charges de travail sont correctement transférées vers le nouveau plan de contrôle, supprimez l'ancien plan de contrôle.

    3. Supprimez les secrets de l'autorité de certification dans le cluster qui sont associés à l'ancienne autorité de certification et redémarrez le nouveau plan de contrôle.

Distribuer la racine de confiance de Mesh CA.

Avant de pouvoir migrer vers Mesh CA, tous les clusters GKE du maillage doivent disposer de Cloud Service Mesh 1.10 ou version ultérieure, et tous les clusters doivent être configurés avec une option de plan de contrôle qui déclenche la distribution de la racine de confiance de Mesh CA aux proxys de toutes les charges de travail du cluster. Une fois le processus terminé, chaque proxy est configuré avec l'ancienne et la nouvelle racine de confiance. Avec ce schéma, lorsque vous effectuez une migration vers Mesh CA, les charges de travail utilisant Mesh CA peuvent s'authentifier auprès des charges de travail à l'aide de l'ancienne autorité de certification.

Installer une nouvelle révision de plan de contrôle

Installez une révision de plan de contrôle avec une option qui distribue la racine de confiance de Mesh CA.

  1. Suivez les étapes de la section Installer les outils dépendants et valider le cluster pour vous préparer à utiliser un outil fourni par Google, asmcli, afin d'installer la nouvelle version du plan de contrôle.

  2. Assurez-vous de disposer de la version de asmcli qui installe Cloud Service Mesh 1.11 ou une version ultérieure:

    ./asmcli --version

  3. Exécutez asmcli install. Dans la commande suivante, remplacez les espaces réservés par vos valeurs.

     ./asmcli install \
   --fleet_id FLEET_PROJECT_ID \
   --kubeconfig KUBECONFIG_FILE \
   --enable_all \
   --ca citadel \
   --ca_cert CA_CERT_FILE_PATH \
   --ca_key CA_KEY_FILE_PATH \
   --root_cert ROOT_CERT_FILE_PATH \
   --cert_chain CERT_CHAIN_FILE_PATH \
   --option ca-migration-citadel \
   --revision_name REVISION_1 \
   --output_dir DIR_PATH
  • --fleet_id : ID du projet du projet hôte du parc.
  • --kubeconfig : Chemin d'accès au fichier kubeconfig. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
  • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
  • --enable_all : autorise l'outil à effectuer les opérations suivantes :
    • Accorder les autorisations IAM requises.
    • Activer les API Google requises.
    • Définir un libellé sur le cluster qui identifie le réseau maillé.
    • Enregistrer le cluster dans le parc si ce n'est déjà fait.

  • -ca citadel : pour éviter les temps d'arrêt, spécifiez Istio CA (l'option citadel correspond à Istio CA). Ne passez pas à Mesh CA pour le moment.
  • --ca_cert : le certificat intermédiaire
  • --ca_key : la clé du certificat intermédiaire
  • --root_cert : le certificat racine
  • --cert_chain : la chaîne de certificats
  • --option ca-migration-citadel : lorsque vous redéployez vos charges de travail, cette option déclenche la nouvelle racine de confiance pour qu'elle soit distribuée aux proxys side-car des charges de travail.
  • REVISION_1 : recommandé. Un libellé de révision est une paire clé-valeur définie sur le plan de contrôle. La clé du libellé de révision est toujours istio.io/rev. Par défaut, l'outil définit la valeur du libellé de révision en fonction de la version de Cloud Service Mesh, par exemple : asm-11910-9. Nous vous recommandons d'inclure cette option et de remplacer REVISION_1 par un nom qui décrit l'installation, tel que asm-11910-9-distribute-root. Le nom doit être un libellé DNS-1035. Il doit en outre contenir des caractères alphanumériques minuscules ou -, commencer par un caractère alphabétique et se terminer par un caractère alphanumérique (par exemple my-name ou abc-123).

Migrer les charges de travail vers le nouveau plan de contrôle

Pour terminer la distribution de la nouvelle racine de confiance, vous devez ajouter à vos espaces de noms le libellé de révision istio.io/rev=<var>REVISION_1</var>-distribute-root et redémarrer vos charges de travail. Lorsque vous testez vos charges de travail après les avoir redémarrées, vous exécutez un outil pour vérifier que le proxy side-car est configuré avec l'ancienne et la nouvelle racine de confiance de Mesh CA.

  1. Définissez le contexte actuel de kubectl. Dans la commande suivante, remplacez --region par --zone si vous disposez d'un cluster à zone unique.

    gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID \
    --region=CLUSTER_LOCATION

  2. Téléchargez l'outil de validation :

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca

  3. Définissez la partie exécutable sur l'outil :

    chmod +x migrate_ca

  4. L'outil migrate_ca appelle istioctl, qui dépend de la version. L'outil asmcli ajoute un lien symbolique à istioctl dans le répertoire que vous avez spécifié pour --output_dir. Assurez-vous que le répertoire se trouve au début de votre chemin. Dans la commande suivante, remplacez ISTIOCTL_PATH par le répertoire contenant istioctl que l'outil a téléchargé.

    export PATH=ISTIOCTL_PATH:$PATH
which istioctl
echo $PATH

  5. Obtenez le libellé de révision associé à istiod et istio-ingressgateway.

    kubectl get pod -n istio-system -L istio.io/rev

    Le résultat ressemble à ce qui suit :

    NAME                                                             READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-5fd454f8ff-t7w9x                            1/1     Running   0          36m   default
istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-z2s9p   1/1     Running   0          18m   asm-195-2-distribute-root
istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-zr2cs   1/1     Running   0          18m   asm-195-2-distribute-root
istiod-68bc495f77-shl2h                                          1/1     Running   0          36m   default
istiod-asm-195-2-distribute-root-6f764dbb7c-g9f8c                1/1     Running   0          18m   asm-195-2-distribute-root
istiod-asm-195-2-distribute-root-6f764dbb7c-z7z9s                1/1     Running   0          18m   asm-195-2-distribute-root

    1. Dans le résultat, sous la colonne REV, notez la valeur du libellé de révision de la nouvelle révision, qui correspond au libellé de révision que vous avez spécifié lors de l'exécution de asmcli install. Dans cet exemple, la valeur est asm-11910-9-distribute-root.

    2. Vous devez supprimer l'ancienne révision de istiod lorsque vous avez terminé de déplacer les charges de travail vers la nouvelle révision. Notez la valeur du libellé de révision pour l'ancienne révision istiod. L'exemple de résultat montre une migration à partir d'Istio, qui utilise la révision default.

  6. Ajoutez le libellé de révision à un espace de noms et supprimez le libellé istio-injection (s'il existe). Dans la commande suivante, remplacez NAMESPACE par l'espace de noms auquel ajouter un libellé.

    kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 istio-injection- --overwrite

    Si "istio-injection not found" apparaît dans le résultat, vous pouvez l'ignorer. Cela signifie que l'espace de noms n'avait pas auparavant l'étiquette istio-injection. Étant donné que le comportement d'injection automatique n'est pas défini lorsqu'un espace de noms possède à la fois le istio-injection et le libellé de révision, toutes les commandes kubectl label de la documentation Cloud Service Mesh s'assurent explicitement qu'un seul est défini.

  7. Redémarrez les pods pour déclencher la réinjection :

    kubectl rollout restart deployment -n NAMESPACE

  8. Testez votre application pour vérifier que les charges de travail fonctionnent correctement.

  9. Si vous avez des charges de travail dans d'autres espaces de noms, répétez les étapes pour leur ajouter des libellés et redémarrer les pods.

  10. Vérifiez que les proxys side-car de toutes les charges de travail du cluster sont configurés avec les anciens et les nouveaux certificats racines :

    ./migrate_ca check-root-cert

    Résultat attendu :

    Namespace: foo
httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA]
sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]

  11. Si vous devez migrer des passerelles, suivez les étapes décrites dans la section Mises à niveau Canary (avancées) pour installer de nouveaux déploiements de passerelle. Voici quelques points à retenir :

    • Utilisez REVISION_1 comme libellé de révision.
    • Déployez les ressources de passerelle dans le même espace de noms que la passerelle de l'ancienne installation pour effectuer une migration sans temps d'arrêt. Assurez-vous que les ressources de service pointant vers l'ancienne passerelle incluent également les déploiements les plus récents.
    • Ne supprimez pas les anciens déploiements de passerelle tant que vous n'êtes pas sûr que votre application fonctionne correctement (après l'étape suivante).

  12. Si vous êtes sûr que votre application fonctionne comme prévu, continuez de suivre les étapes pour valider la transition vers la nouvelle version de istiod. Si vous rencontrez un problème avec votre application, suivez la procédure de rollback.

    Terminer la transition

    Si vous êtes sûr que votre application fonctionne comme prévu, supprimez l'ancien plan de contrôle pour terminer la transition vers la nouvelle version.

    1. Accédez au répertoire dans lequel se trouvent les fichiers du dépôt GitHub anthos-service-mesh.

    2. Configurez le webhook de validation pour utiliser le nouveau plan de contrôle.

      kubectl apply -f asm/istio/istiod-service.yaml

    3. Supprimez l'ancien déploiement istio-ingressgateway. La commande que vous exécutez varie selon que vous effectuez la migration depuis Istio ou une mise à niveau depuis une version précédente de Cloud Service Mesh:

      Migrer

      Si vous avez effectué une migration depuis Istio, l'ancienne istio-ingressgateway ne comporte pas d'étiquette de révision.

      kubectl delete deploy/istio-ingressgateway -n istio-system

      Mettre à niveau

      Si vous avez mis à niveau à partir d'une version précédente de Cloud Service Mesh, dans la commande suivante, remplacez OLD_REVISION par le libellé de révision de la version précédente de istio-ingressgateway.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true

    4. Supprimez l'ancienne révision de istiod. La commande que vous utilisez varie selon que vous effectuez la migration depuis Istio ou une mise à niveau depuis une version précédente de Cloud Service Mesh.

      Migrer

      Si vous avez effectué une migration depuis Istio, l'ancienne istio-ingressgateway ne comporte pas d'étiquette de révision.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

      Mettre à niveau

      Si vous avez effectué une mise à niveau à partir d'une version précédente de Cloud Service Mesh, assurez-vous que OLD_REVISION correspond au libellé de révision de la version précédente de istiod dans la commande suivante.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true

    5. Supprimez l'ancienne version de la configuration IstioOperator.

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system

      Le résultat ressemble à ce qui suit :

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

    Rollback

    Si vous avez rencontré un problème lors du test de votre application avec la nouvelle version de istiod, procédez comme suit pour effectuer un rollback vers la version précédente :

    1. Supprimez les nouveaux déploiements de passerelle installés à l'étape 11.

    2. Modifiez les libellés de votre espace de noms pour activer l'injection automatique avec la version précédente de istiod. La commande que vous utilisez varie selon que vous avez utilisé une étiquette de révision ou istio-injection=enabled avec la version précédente.

      • Si vous avez utilisé un libellé de révision pour l'injection automatique :

        kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite

      • Si vous avez utilisé istio-injection=enabled :

        kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite

      Résultat attendu :

      namespace/NAMESPACE labeled

    3. Confirmez que le libellé de révision de l'espace de noms correspond au libellé de révision de la version précédente de istiod :

      kubectl get ns NAMESPACE --show-labels

    4. Redémarrez les pods pour déclencher une réinjection afin que les proxys disposent de la version précédente : 

      kubectl rollout restart deployment -n NAMESPACE

    5. Supprimez le nouveau déploiement istio-ingressgateway.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true

    6. Supprimez la nouvelle révision de istiod.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true

    7. Supprimez la nouvelle configuration IstioOperator.

      kubectl delete IstioOperator installed-state-asm-11910-9-distribute-root -n istio-system

      Le résultat attendu ressemble à ce qui suit :

      istiooperator.install.istio.io "installed-state-asm-11910-9-distribute-root" deleted

Migrer vers Mesh CA

Maintenant que les proxys side-car de toutes les charges de travail sont configurés avec l'ancienne racine de confiance et la nouvelle racine de confiance de Mesh CA, les étapes de migration vers Mesh CA sont similaires à celles que vous avez effectuées pour distribuer la racine de confiance de Mesh CA :

Installer un nouveau plan de contrôle avec Mesh CA activé

Vous utilisez asmcli install pour installer une nouvelle révision du plan de contrôle pour laquelle Mesh CA est activé.

  1. Si vous avez personnalisé l'installation précédente, vous devez spécifier les mêmes fichiers de superposition lorsque vous exécutez asmcli install.

  2. Exécutez asmcli install. Dans la commande suivante, remplacez les espaces réservés par vos valeurs.

     ./asmcli install \
   --fleet_id FLEET_PROJECT_ID \
   --kubeconfig KUBECONFIG_FILE \
   --output_dir DIR_PATH \
   --enable_all \
   --ca mesh_ca \
   --root_cert ROOT_CERT_FILE_PATH \
   --cert_chain CERT_CHAIN_FILE_PATH
   --option ca-migration-meshca \
  --revision_name REVISION_2 \
  --output_dir DIR_PATH \
  OVERLAYS
      • --fleet_id : ID du projet du projet hôte du parc.
      • --kubeconfig : chemin d'accès au fichier kubeconfig. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
      • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
      • --enable_all : autorise l'outil à effectuer les opérations suivantes :
        • Accorder les autorisations IAM requises.
        • Activer les API Google requises.
        • Définir un libellé sur le cluster qui identifie le réseau maillé.
        • Enregistrer le cluster dans le parc si ce n'est déjà fait.

      • --ca mesh_ca : vous pouvez maintenant passer à Mesh CA, car la racine de confiance de Mesh CA a été distribuée.
      • REVISION_2 : recommandé. Remplacez REVISION_2 par un nom qui décrit l'installation, tel que asm-11910-9-meshca-ca-migration. Le nom doit être un libellé DNS-1035. Il doit en outre contenir des caractères alphanumériques minuscules ou -, commencer par un caractère alphabétique et se terminer par un caractère alphanumérique (par exemple my-name ou abc-123).
      • --option ca-migration-migration : lorsque vous redéployez vos charges de travail, cette option configure les proxys pour qu'ils utilisent la racine de confiance de Mesh CA.

Migrer les charges de travail vers le nouveau plan de contrôle

Pour terminer l'installation, vous devez ajouter à vos espaces de noms le nouveau libellé de révision et redémarrer vos charges de travail.

  1. Obtenez le libellé de révision associé à istiod et istio-ingressgateway.

    kubectl get pod -n istio-system -L istio.io/rev

    Le résultat ressemble à ce qui suit :

    NAME                                                                          READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-asm-11910-9-distribute-root-65d884685d-6hrdk      1/1     Running   0          67m   asm-11910-9-distribute-root
istio-ingressgateway-asm-11910-9-distribute-root65d884685d-94wgz       1/1     Running   0          67m   asm-11910-9-distribute-root
istio-ingressgateway-asm-11910-9-meshca-ca-migration-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-11910-9-meshca-ca-migration
istio-ingressgateway-asm-11910-9-meshca-ca-migration-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-11910-9-meshca-ca-migration
istiod-asm-11910-9-distribute-root-67998f4b55-lrzpz                    1/1     Running   0          68m   asm-11910-9-distribute-root
istiod-asm-11910-9-distribute-root-67998f4b55-r76kr                    1/1     Running   0          68m   asm-11910-9-distribute-root
istiod-asm-11910-9-meshca-ca-migration-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-11910-9-meshca-ca-migration
istiod-asm-11910-9-meshca-ca-migration-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-11910-9-meshca-ca-migration

    1. Dans le résultat, sous la colonne REV, notez la valeur du libellé de révision pour la nouvelle version. Dans cet exemple, la valeur est asm-11910-9-meshca-ca-migration.

    2. Notez également la valeur du libellé de révision pour l'ancienne version de istiod. Vous devrez supprimer l'ancienne version de istiod lorsque vous aurez fini de déplacer les charges de travail vers la nouvelle version. Dans l'exemple, la valeur du libellé de révision pour la révision précédente est asm-11910-9-distribute-root.

  2. Ajoutez le nouveau libellé de révision à un espace de noms. Dans la commande suivante, remplacez NAMESPACE par l'espace de noms auquel ajouter un libellé.

    kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite

  3. Redémarrez les pods pour déclencher la réinjection :

    kubectl rollout restart deployment -n NAMESPACE

  4. Testez votre application pour vérifier que les charges de travail fonctionnent correctement. Assurez-vous que la communication mTLS fonctionne entre les charges de travail de l'ancien espace de noms et celles du nouvel espace de noms.

  5. Si vous avez des charges de travail dans d'autres espaces de noms, répétez les étapes pour leur ajouter des libellés et redémarrer les pods.

  6. Suivez les étapes décrites dans Mises à niveau sur place pour mettre à niveau les anciens déploiements de passerelle installés à l'étape 11 de la section précédente vers la dernière révision REVISION_2.

  7. Si vous êtes sûr que votre application fonctionne comme prévu, continuez de suivre les étapes pour valider la transition vers le nouveau plan de contrôle. Si vous rencontrez un problème avec votre application, suivez la procédure de rollback.

    Terminer la transition

    Si vous êtes sûr que votre application fonctionne comme prévu, supprimez l'ancien plan de contrôle pour terminer la transition vers la nouvelle version.

    1. Accédez au répertoire dans lequel se trouvent les fichiers du dépôt GitHub anthos-service-mesh.

    2. Configurez le webhook de validation pour utiliser le nouveau plan de contrôle.

      kubectl apply -f asm/istio/istiod-service.yaml

    3. Supprimez l'ancien déploiement istio-ingressgateway. Dans la commande suivante, remplacez OLD_REVISION par le libellé de révision pour la version précédente de istio-ingressgateway.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true

    4. Supprimez l'ancienne révision istiod. Dans la commande suivante, remplacez OLD_REVISION par le libellé de révision pour la version précédente de istiod.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true

    5. Supprimez l'ancienne configuration IstioOperator.

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system

      Le résultat ressemble à ce qui suit :

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

    Rollback

    Si vous avez rencontré un problème lors du test de votre application avec la nouvelle révision istiod, procédez comme suit pour effectuer un rollback vers la révision précédente :

    1. Suivez les étapes décrites dans Mises à niveau sur place pour revenir aux versions de déploiements de passerelle précédemment mis à niveau à l'étape 6 de cette section vers l'ancienne révision REVISION_1.

    2. Modifiez le libellé de votre espace de noms pour activer l'injection automatique avec la révision istiod précédente.

      kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite

      Résultat attendu :

      namespace/NAMESPACE labeled

    3. Confirmez que le libellé de révision de l'espace de noms correspond au libellé de révision de la version précédente de istiod :

      kubectl get ns NAMESPACE --show-labels

    4. Redémarrez les pods pour déclencher une réinjection afin que les proxys disposent de la version précédente : 

      kubectl rollout restart deployment -n NAMESPACE

    5. Supprimez le nouveau déploiement istio-ingressgateway.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_2 -n istio-system --ignore-not-found=true

    6. Supprimez la nouvelle version de istiod. Assurez-vous que le libellé de révision indiqué dans la commande suivante corresponde à la révision.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_2 -n istio-system --ignore-not-found=true

    7. Supprimez la nouvelle version de la configuration IstioOperator.

      kubectl delete IstioOperator installed-state-REVISION_2 -n istio-system

      Le résultat attendu ressemble à ce qui suit :

      istiooperator.install.istio.io "installed-state-REVISION_2" deleted

Supprimer les secrets de l'autorité de certification et redémarrer le nouveau plan de contrôle

  1. Conservez les secrets au cas où vous en auriez besoin :

    kubectl get secret/cacerts -n istio-system -o yaml > save_file_1
kubectl get secret/istio-ca-secret -n istio-system -o yaml > save_file_2

  2. Supprimez les secrets de l'autorité de certification dans le cluster associé à l'ancienne autorité de certification :

    kubectl delete secret cacerts istio-ca-secret -n istio-system --ignore-not-found

  3. Redémarrez le plan de contrôle nouvellement installé. Cela permet de s'assurer que l'ancienne racine de confiance est supprimée de toutes les charges de travail exécutées dans le maillage.

    kubectl rollout restart deployment -n istio-system