Cette page explique comment effectuer les actions suivantes :
Exécuter
asmcli
pour effectuer une mise à niveau à partir d'Anthos Service Mesh ou d'Istio Open Source 1.9 or a 1.10 patch release vers Anthos Service Mesh1.10.6. Les mises à niveau à partir de versions antérieures ne sont pas acceptées.Effectuez une mise à niveau Canary pour migrer vos charges de travail vers le nouveau plan de contrôle.
Avant de commencer
Avant de commencer, veillez à suivre les étapes ci-dessous :
- Consultez les conditions préalables.
Actuellement,
asmcli
ne permet pas de mettre à niveau Anthos Service Mesh sur des clusters GKE qui se trouvent dans un maillage multi-cluster dans différents projets, sauf si vous avez initialement installé Anthos Service Mesh à l'aide deasmcli
. - Consultez les informations de la section Planifier la mise à niveau.
- Installez les outils nécessaires.
- Télécharger
asmcli
- Accordez des autorisations d'administrateur de cluster.
- Validez le projet et le cluster
Personnalisations du plan de contrôle
Si vous avez personnalisé l'installation précédente, vous avez besoin des mêmes personnalisations lorsque vous effectuez une mise à niveau vers une nouvelle version d'Anthos Service Mesh ou une migration depuis Istio. Si vous avez personnalisé l'installation en ajoutant l'option --set values
à istioctl install
, vous devez ajouter ces paramètres à un fichier YAML IstioOperator
, appelé fichier de superposition. Vous spécifiez le fichier superposé en utilisant l'option --custom_overlay
avec le nom de fichier lorsque vous exécutez le script. Le script transmet le fichier de superposition à istioctl install
.
Autorité de certification
La modification de l'autorité de certification lors d'une mise à niveau entraîne des temps d'arrêt. Pendant la mise à niveau, le trafic mTLS est interrompu jusqu'à ce que toutes les charges de travail passent au nouveau plan de contrôle avec la nouvelle autorité de certification.
Mettre à niveau Anthos Service Mesh
Vous trouverez ci-dessous la procédure à suivre pour mettre à niveau Anthos Service Mesh :
Exécutez
asmcli install
pour installer Anthos Service Mesh sur un seul cluster. Consultez les sections suivantes pour obtenir des exemples de ligne de commande. Les exemples contiennent à la fois des arguments obligatoires et des arguments facultatifs qui peuvent vous être utiles. Nous vous recommandons de toujours spécifier l'argumentoutput_dir
afin de pouvoir facilement trouver des exemples de passerelles et d'outils tels queistioctl
. Consultez la barre de navigation située à droite pour obtenir la liste des exemples.Vous pouvez également installer ou mettre à niveau une passerelle d'entrée.
Pour terminer la configuration d'Anthos Service Mesh, vous devez activer l'injection side-car automatique et déployer ou redéployer des charges de travail.
Mettre à niveau avec les fonctionnalités par défaut et Mesh CA
Cette section explique comment exécuter asmcli
pour mettre à niveau Anthos Service Mesh avec les fonctionnalités compatibles par défaut de votre plate-forme et activer l'autorité de certification Anthos Service Mesh (Mesh CA) comme autorité de certification.
GKE
Exécutez la commande suivante pour installer le nouveau plan de contrôle avec les fonctionnalités par défaut. Saisissez vos valeurs dans les espaces réservés fournis.
./asmcli install \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--fleet_id FLEET_PROJECT_ID \
--output_dir DIR_PATH \
--enable_all \
--ca mesh_ca
--project_id
,--cluster_name
et--cluster_location
: spécifiez l'ID du projet dans lequel se trouve le cluster, son nom, ainsi que la zone ou la région du cluster.--fleet_id
: ID du projet du projet hôte du parc. Si vous n'incluez pas cette option,asmcli
utilise le projet dans lequel le cluster a été créé lors de son enregistrement.--output_dir
: incluez cette option pour spécifier un répertoire dans lequelasmcli
télécharge le packageanthos-service-mesh
et extrait le fichier d'installation, qui contientistioctl
, des exemples et des fichiers manifestes. Sinon,asmcli
télécharge les fichiers dans un répertoiretmp
. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement$PWD
ne fonctionne pas ici.--enable_all
: permet au script d'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
: utiliser Mesh CA comme autorité de certification. La modification des autorités de certification lors d'une mise à niveau entraîne des temps d'arrêt.asmcli
configure l'autorité de certification MeshMesh pour utiliser l'identité de charge de travail de parc.
Sur site
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez la commande suivante pour installer le nouveau plan de contrôle avec les fonctionnalités par défaut. Saisissez vos valeurs dans les espaces réservés fournis.
./asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --output_dir DIR_PATH \ --platform multicloud \ --enable_all \ --ca mesh_ca
--fleet_id
: ID du projet du projet hôte du parc.--kubeconfig
: Chemin d'accès au fichierkubeconfig
. 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 lequelasmcli
télécharge le packageanthos-service-mesh
et extrait le fichier d'installation, qui contientistioctl
, des exemples et des fichiers manifestes. Sinon,asmcli
télécharge les fichiers dans un répertoiretmp
. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement$PWD
ne fonctionne pas ici.--platform multicloud
spécifie que la plate-forme sur site est utilisée.--enable_all
: permet au script d'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
: utiliser Mesh CA comme autorité de certification. La modification des autorités de certification lors d'une mise à niveau entraîne un temps d'arrêt.asmcli
configure Mesh CA pour utiliser l'identité de charge de travail du parc.
Mettre à niveau les fonctionnalités par défaut avec l'autorité de certification d'Istio
Cette section explique comment exécuter asmcli
pour mettre à niveau Anthos Service Mesh avec les fonctionnalités compatibles par défaut de votre plate-forme et activer Istio CA.
GKE
./asmcli install \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--fleet_id FLEET_PROJECT_ID \
--output_dir DIR_PATH \
--enable_all \
--ca citadel
--project_id
,--cluster_name
et--cluster_location
: spécifiez l'ID du projet dans lequel se trouve le cluster, son nom, ainsi que la zone ou la région du cluster.--fleet_id
: ID du projet du projet hôte du parc. Si vous n'incluez pas cette option,asmcli
utilise le projet dans lequel le cluster a été créé lors de son enregistrement.--output_dir
: incluez cette option pour spécifier un répertoire dans lequelasmcli
télécharge le packageanthos-service-mesh
et extrait le fichier d'installation, qui contientistioctl
, des exemples et des fichiers manifestes. Sinon,asmcli
télécharge les fichiers dans un répertoiretmp
. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement$PWD
ne fonctionne pas ici.--enable_all
: permet au script d'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
: Utilise l'autorité de certification Istio. La modification des autorités de certification lors d'une mise à niveau entraîne un temps d'arrêt.
Sur site
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez la commande suivante pour installer Anthos Service Mesh avec les fonctionnalités par défaut et Istio CA :
./asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --output_dir DIR_PATH \ --platform multicloud \ --enable_all \ --ca citadel \
--fleet_id
: ID du projet du projet hôte du parc.--kubeconfig
: Chemin d'accès au fichierkubeconfig
. 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 lequelasmcli
télécharge le packageanthos-service-mesh
et extrait le fichier d'installation, qui contientistioctl
, des exemples et des fichiers manifestes. Sinon,asmcli
télécharge les fichiers dans un répertoiretmp
. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement$PWD
ne fonctionne pas ici.--platform multicloud
spécifie que la plate-forme sur site est utilisée.--enable_all
: permet au script d'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
: Utilise l'autorité de certification Istio. La modification de l'autorité de certification lors d'une mise à niveau entraîne des temps d'arrêt.
Passer à une édition supérieure avec des fonctionnalités facultatives
Un fichier de superposition est un fichier YAML contenant une ressource personnalisée IstioOperator
que vous transmettez à asmcli
pour configurer le plan de contrôle. Vous pouvez ignorer la configuration par défaut du plan de contrôle et activer une fonctionnalité facultative en transmettant le fichier YAML à asmcli
. Vous pouvez effectuer plusieurs couches de superpositions. Chaque fichier de superposition remplace la configuration dans les couches précédentes.
GKE
Exécutez la commande suivante pour installer le nouveau plan de contrôle avec les fonctionnalités par défaut. Saisissez vos valeurs dans les espaces réservés fournis.
./asmcli install \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--fleet_id FLEET_PROJECT_ID \
--output_dir DIR_PATH \
--enable_all \
--ca mesh_ca \
--custom_overlay OVERLAY_FILE
--project_id
,--cluster_name
et--cluster_location
: spécifiez l'ID du projet dans lequel se trouve le cluster, son nom, ainsi que la zone ou la région du cluster.--fleet_id
: ID du projet du projet hôte du parc. Si vous n'incluez pas cette option,asmcli
utilise le projet dans lequel le cluster a été créé lors de son enregistrement.--output_dir
: incluez cette option pour spécifier un répertoire dans lequelasmcli
télécharge le packageanthos-service-mesh
et extrait le fichier d'installation, qui contientistioctl
, des exemples et des fichiers manifestes. Sinon,asmcli
télécharge les fichiers dans un répertoiretmp
. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement$PWD
ne fonctionne pas ici.--enable_all
: permet au script d'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
: utiliser Mesh CA comme autorité de certification. La modification des autorités de certification lors d'une mise à niveau entraîne des temps d'arrêt.asmcli
configure l'autorité de certification MeshMesh pour utiliser l'identité de charge de travail de parc.--custom_overlay
: spécifier le nom du fichier de superposition.
Sur site
Définissez le contexte actuel sur votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Exécutez la commande suivante pour installer le nouveau plan de contrôle avec les fonctionnalités par défaut. Saisissez vos valeurs dans les espaces réservés fournis.
./asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --output_dir DIR_PATH \ --platform multicloud \ --enable_all \ --ca mesh_ca \ --custom_overlay OVERLAY_FILE
--fleet_id
: ID du projet du projet hôte du parc.--kubeconfig
: Chemin d'accès au fichierkubeconfig
. 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 lequelasmcli
télécharge le packageanthos-service-mesh
et extrait le fichier d'installation, qui contientistioctl
, des exemples et des fichiers manifestes. Sinon,asmcli
télécharge les fichiers dans un répertoiretmp
. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement$PWD
ne fonctionne pas ici.--platform multicloud
spécifie que la plate-forme sur site est utilisée.--enable_all
: permet au script d'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
: utiliser Mesh CA comme autorité de certification. La modification des autorités de certification lors d'une mise à niveau entraîne des temps d'arrêt.asmcli
configure l'autorité de certification MeshMesh pour utiliser l'identité de charge de travail de parc.--custom_overlay
: spécifier le nom du fichier de superposition.
Mettre à niveau les passerelles
Si des passerelles sont déjà déployées, vous devrez également les mettre à niveau. Pour une mise à niveau simple, suivez la section "Mises à niveau sur place" du guide Installer et mettre à niveau les passerelles.
Passer au nouveau plan de contrôle
Obtenez le libellé de révision qui se trouve sur
istiod
.kubectl get pod -n istio-system -L istio.io/rev
La sortie de la commande ressemble à ceci :
NAME READY STATUS RESTARTS AGE REV istiod-asm-176-1-67998f4b55-lrzpz 1/1 Running 0 68m asm-198-3 istiod-asm-176-1-67998f4b55-r76kr 1/1 Running 0 68m asm-198-3 istiod-asm-182-2-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1106-2 istiod-asm-182-2-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1106-2
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 estasm-1106-2
.Notez également la valeur du libellé de révision pour l'ancienne version de
istiod
. Vous devrez supprimer l'ancienne version deistiod
lorsque vous aurez fini de déplacer les charges de travail vers la nouvelle version. Dans l'exemple de résultat, la valeur du libellé de révision pour l'ancienne version estasm-198-3
.
Ajoutez le libellé de révision à un espace de noms d'application et supprimez le libellé
istio-injection
(s'il existe). Dans la commande suivante, remplacezREVISION
par la valeur correspondant à la nouvelle révision deistiod
.kubectl label namespace NAMESPACE istio.io/rev=REVISION 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 leistio-injection
et le libellé de révision, toutes les commandeskubectl 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
Vérifiez que vos pods sont configurés pour pointer vers la nouvelle version de
istiod
.kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
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.
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.
Accédez au répertoire dans lequel se trouvent les fichiers du dépôt GitHub
anthos-service-mesh
.Configurez le webhook de validation pour utiliser le nouveau plan de contrôle.
kubectl apply -f asm/istio/istiod-service.yaml
Supprimez l'ancienne version 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 deistiod
dans la commande suivante.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
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 :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 ouistio-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
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
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
Supprimez la nouvelle version de
istiod
. Assurez-vous que la valeur deREVISION
dans la commande suivante est correcte.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
Supprimez la nouvelle version de la configuration
IstioOperator
.kubectl delete IstioOperator installed-state-REVISION -n istio-system
Le résultat attendu ressemble à ce qui suit :
istiooperator.install.istio.io "installed-state-REVISION" deleted
Si vous n'avez pas ajouté l'option
--disable_canonical_service
, le script a activé le contrôleur de service canonique. Nous vous recommandons de conserver cette option activée. Cependant, si vous devez la désactiver, consultez la section Activer et désactiver le contrôleur de service canonique.Si vous avez déployé des passerelles, veillez à modifier le libellé de révision sur l'espace de noms ou le déploiement pour qu'il corresponde à la version précédente de
istiod
. Suivez la même procédure que celle décrite dans la section "Mise à niveau sur place" du guide Installer et mettre à niveau des passerelles.