Anthos Service Mesh 1.11 est arrivé en fin de vie et n'est plus pris en charge. Consultez la section Mettre à niveau à partir de versions antérieures.

Accédez à la documentation la plus récente ou sélectionnez une autre version disponible :

Versions disponibles

1.20 (la plus récente)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Migrer vers Mesh CA

La migration vers l'autorité de certification Anthos 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 d'Anthos Service Mesh, si vous vouliez migrer d'Istio sur Google Kubernetes Engine (GKE) vers Anthos Service Mesh avec Mesh CA, vous deviez planifier un temps d'arrêt, car Anthos 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.

Cette page explique comment migrer d'Istio CA vers Mesh CA avec un temps d'arrêt minimal ou nul. 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 Anthos Service Mesh 1.11.8-asm.4 avec Mesh CA.
Passer d'Anthos Service Mesh 1.9 or a 1.10 patch release avec Istio CA au plan de contrôle au sein du cluster Anthos Service Mesh 1.11.8-asm.4 avec Mesh CA.

Limites

Mesh CA n'est compatible qu'avec GKE.
Tous les clusters GKE doivent appartenir au même projet Google Cloud.

Prérequis

Ce guide suppose que vous disposez des éléments suivants :

Un projet Google Cloud
Un compte Cloud Billing
Les outils requis pour exécuter le script install_asm.
Pour un maillage multicluster utilisant l'autorité de certification Istio, le même certificat racine doit être défini sur chaque cluster.

Outils requis

Pendant la migration, vous exécutez un script 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.

Ce script a les dépendances suivantes :

awk
grep
istioctl Lorsque vous exécutez le script install_asm, il télécharge la version de istioctl qui correspond à la version d'Anthos 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 :

Distribuez la racine de confiance de Mesh CA.
1. Installez une nouvelle révision du plan de contrôle avec une option qui distribuera 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.
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 d'Anthos 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.

Suivez les étapes de la page Installer Anthos Service Mesh sur GKE pour vous préparer à utiliser un script fourni par Google, install_asm, pour installer la nouvelle révision de plan de contrôle.
Assurez-vous de disposer de la version de install_asm qui installe Anthos Service Mesh 1.10 ou une version ultérieure :
```
./install_asm --version
```
Exécutez install_asm. Dans la commande suivante, remplacez les espaces réservés par vos valeurs.
- PROJECT_ID : valeur obligatoire. ID du projet dans lequel le cluster a été créé.
- CLUSTER_NAME : valeur obligatoire. Nom du cluster.
- CLUSTER_LOCATION : valeur obligatoire. Zone ou région dans laquelle se trouve le cluster.
- 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, le script définit la valeur du libellé de révision en fonction de la version d'Anthos Service Mesh, par exemple : asm-1118-4. Nous vous recommandons d'inclure cette option et de remplacer REVISION_1 par un nom qui décrit l'installation, tel que asm-1118-4-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). L'expression régulière utilisée pour la validation est la suivante : '[a-z]([-a-z0-9]*[a-z0-9])?').
- DIR_PATH : valeur obligatoire. Chemin d'accès relatif vers un répertoire dans lequel le script télécharge le package anthos-service-mesh et le fichier d'installation d'Anthos Service Mesh, qui contient istioctl, des exemples et des fichiers manifestes.
- OVERLAYS : facultatif. Si vous souhaitez activer des fonctionnalités facultatives, incluez --custom_overlay avec le nom du fichier de superposition pour chaque fonctionnalité. Si vous n'activez pas les fonctionnalités facultatives, supprimez cette ligne et la barre oblique inverse de la ligne précédente.
```
./install_asm \
  --project_id  PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --enable_all \
  --option ca-migration-citadel \
  --revision_name REVISION_1  \
  --output_dir DIR_PATH \
  OVERLAYS
```
Les arguments de ligne de commande suivants sont requis :
- --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.
- --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.

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=asm-1118-4-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 script pour vérifier que le proxy side-car est configuré avec l'ancienne et la nouvelle racine de confiance de Mesh CA.

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

Téléchargez le script de validation :

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

Définissez la partie exécutable sur le script :
```
chmod +x migrate_ca
```
Le script migrate_ca appelle istioctl, qui dépend de la version. Le script install_asm 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 le script a téléchargé.
```
export PATH=ISTIOCTL_PATH:$PATH
which istioctl
echo $PATH
```

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

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 install_asm. Dans cet exemple, la valeur est asm-1118-4-distribute-root.
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.

Basculez istio-ingressgateway vers la nouvelle révision. Dans la commande suivante, assurez-vous que REVISION_1 correspond à la valeur du libellé de révision de la nouvelle révision.

kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION_1"}]'

Résultat attendu :

service/istio-ingressgateway patched

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 le libellé istio-injection. Étant donné que l'injection automatique échoue si 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 Anthos Service Mesh incluent la suppression du libellé istio-injection.
Redémarrez les pods pour déclencher la réinjection :
```
kubectl rollout restart deployment -n NAMESPACE
```
Testez votre application pour vérifier que les charges de travail fonctionnent correctement.
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.
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]
```
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 d'Anthos Service Mesh :
  Migrer
  Si vous avez effectué une migration depuis Istio, l'ancienne istio-ingressgateway ne comporte pas de libellé 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 d'Anthos 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 d'Anthos Service Mesh.
  Migrer
  Si vous avez effectué une migration depuis Istio, l'ancienne istio-ingressgateway ne comporte pas de libellé 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 d'Anthos 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. Revenez à l'ancienne version de istio-ingressgatewqy. Dans la commande suivante, remplacez OLD_REVISION par l'ancienne révision.
  kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
2. Modifier les libellés à votre espace de noms afin d'activer l'injection automatique avec la version précédente de istiod. La commande que vous utilisez varie selon que vous avez utilisé un libellé 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-1118-4-distribute-root -n istio-system
  Le résultat attendu ressemble à ce qui suit :
  istiooperator.install.istio.io "installed-state-asm-1118-4-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 install_asm pour installer une nouvelle révision du plan de contrôle pour laquelle Mesh CA est activé.

Si vous avez personnalisé l'installation précédente, vous devez spécifier les mêmes fichiers de superposition lorsque vous exécutez install_asm.
Exécutez install_asm. Dans la commande suivante, remplacez les espaces réservés par vos valeurs.
- PROJECT_ID : valeur obligatoire. ID du projet dans lequel le cluster a été créé.
- CLUSTER_NAME : valeur obligatoire. Nom du cluster.
- CLUSTER_LOCATION : valeur obligatoire. Zone ou région dans laquelle se trouve le cluster.
- REVISION_2 : recommandé. Remplacez REVISION_2 par un nom qui décrit l'installation, tel que asm-1118-4-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). L'expression régulière utilisée pour la validation est la suivante : '[a-z]([-a-z0-9]*[a-z0-9])?').
- DIR_PATH : valeur obligatoire. Chemin d'accès relatif vers un répertoire dans lequel le script télécharge le package anthos-service-mesh et le fichier d'installation d'Anthos Service Mesh, qui contient istioctl, des exemples et des fichiers manifestes.
- OVERLAYS : facultatif. Si vous souhaitez activer des fonctionnalités facultatives, incluez --custom_overlay avec le nom du fichier de superposition pour chaque fonctionnalité. Si vous n'activez pas les fonctionnalités facultatives, supprimez cette ligne et la barre oblique inverse de la ligne précédente.
```
./install_asm \
  --project_id  PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca mesh_ca \
  --enable_all \
  --option ca-migration-meshca \
  --revision_name REVISION_2 \
  --output_dir DIR_PATH \
  OVERLAYS
```
Les arguments de ligne de commande suivants sont requis :
- --ca mesh_ca : vous pouvez maintenant passer à Mesh CA, car la racine de confiance de Mesh CA a été distribuée.
- --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.

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-1118-4-distribute-root-65d884685d-6hrdk      1/1     Running   0          67m   asm-1118-4-distribute-root
istio-ingressgateway-asm-1118-4-distribute-root65d884685d-94wgz       1/1     Running   0          67m   asm-1118-4-distribute-root
istio-ingressgateway-asm-1118-4-meshca-ca-migration-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-1118-4-meshca-ca-migration
istio-ingressgateway-asm-1118-4-meshca-ca-migration-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1118-4-meshca-ca-migration
istiod-asm-1118-4-distribute-root-67998f4b55-lrzpz                    1/1     Running   0          68m   asm-1118-4-distribute-root
istiod-asm-1118-4-distribute-root-67998f4b55-r76kr                    1/1     Running   0          68m   asm-1118-4-distribute-root
istiod-asm-1118-4-meshca-ca-migration-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1118-4-meshca-ca-migration
istiod-asm-1118-4-meshca-ca-migration-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1118-4-meshca-ca-migration

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-1118-4-meshca-ca-migration.
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-1118-4-distribute-root.

Basculez istio-ingressgateway vers la nouvelle révision. Dans la commande suivante, remplacez REVISION_2 par la valeur correspondant au libellé de révision de la nouvelle version.

kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION_2"}]'

Résultat attendu :

service/istio-ingressgateway patched

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
```
Redémarrez les pods pour déclencher la réinjection :
```
kubectl rollout restart deployment -n NAMESPACE
```
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.
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.
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. Revenez à la version précédente de istio-ingressgatewqy. Dans la commande suivante, remplacez OLD_REVISION par l'ancienne révision.
  kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
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

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

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

Migrer vers Mesh CA

Limites

Prérequis

Outils requis

Présentation de la migration

Distribuer la racine de confiance de Mesh CA.

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

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

Terminer la transition

Migrer

Mettre à niveau

Migrer

Mettre à niveau

Rollback

Migrer vers Mesh CA

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

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

Terminer la transition

Rollback

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