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

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

Suivez les étapes décrites dans la section Premiers pas pour :

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 Lorsque vous exécutez l'outil 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 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.
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 section Premiers pas pour vous préparer à utiliser un outil fourni par Google, asmcli, pour installer la nouvelle révision de plan de contrôle.
Assurez-vous de disposer de la version de asmcli qui installe Anthos Service Mesh 1.11 ou une version ultérieure :
```
./asmcli --version
```

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

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.

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 l'outil de validation :

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

Définissez la partie exécutable sur l'outil :
```
chmod +x migrate_ca
```
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
```

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 asmcli install. 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.

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 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).
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. 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é 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
```