Ce guide explique comment mettre à niveau Anthos Service Mesh de la version 1.7.3+ or a 1.8 patch release vers la version 1.8.2 sur des clusters Anthos sur VMware. Les mises à niveau à partir de versions antérieures ne sont pas acceptées. Si vous disposez d'une version antérieure et que vous devez la mettre à niveau, consultez la page Mise à niveau à partir de versions précédentes.
Lors de la mise à niveau, nous vous recommandons d'effectuer une mise à niveau basée sur la révision (également appelée mise à niveau Canary), où les versions nouvelle et précédente du plan de contrôle sont exécutées lorsque vous testez la nouvelle version avec un faible pourcentage de vos charges de travail. Cette approche est plus sûre qu'une mise à niveau sur place, où la nouvelle version du plan de contrôle remplace la version précédente. Notez que le serviceistio-ingressgateway
est mis à niveau. Vous devez donc prévoir certaines interruptions sur votre cluster.
Le redéploiement des composants du plan de contrôle d'Anthos Service Mesh prend environ 5 à 10 minutes. En outre, vous devez injecter de nouveaux proxys side-car dans toutes vos charges de travail afin qu'elles soient mises à jour avec la version actuelle d'Anthos Service Mesh. Le temps nécessaire à la mise à jour des proxys side-car dépend de nombreux facteurs, tels que le nombre de pods, le nombre de nœuds, les paramètres de scaling du déploiement, les budgets d'interruption de pod et d'autres paramètres de configuration. Une estimation approximative du temps nécessaire à la mise à jour des proxys side-car est de 100 pods par minute.
Préparer la mise à niveau
Si vous avez personnalisé l'installation précédente, vous avez besoin des mêmes personnalisations lors de la mise à niveau vers Anthos Service Mesh. Si vous avez personnalisé l'installation en ajoutant l'option --set values
à istioctl install
, nous vous recommandons d'ajouter ces paramètres à un fichier YAML IstioOperator
(bien que vous puissiez continuer à utiliser l'option --set_values
). Pour personnaliser l'installation, spécifiez l'option -f
avec un fichier YAML lorsque vous exécutez la commande istioctl install
.
Configurer votre environnement
Vous devez disposer des outils suivants sur la machine à partir de laquelle vous souhaitez installer Anthos Service Mesh. Notez que vous ne pouvez installer Anthos Service Mesh que sur un cluster d'utilisateur, et non sur un cluster d'administrateur.
- Outil de ligne de commande
curl
- SDK Cloud (outil de ligne de commande
gcloud
)
Après avoir installé le SDK Cloud :
Authentifiez-vous avec le SDK Cloud :
gcloud auth login
Mettez à jour les composants :
gcloud components update
Installez
kubectl
:gcloud components install kubectl
Si vous souhaitez déployer et tester votre installation avec l'exemple d'application Boutique en ligne, installez
kpt
:gcloud components install kpt
Basculez le contexte vers votre cluster d'utilisateur :
kubectl config use-context CLUSTER_NAME
Accordez des autorisations d'administrateur de cluster à votre compte utilisateur (votre adresse e-mail de connexion Google Cloud). Vous avez besoin de ces autorisations pour créer les règles de contrôle d'accès basé sur les rôles (RBAC) nécessaires pour Anthos Service Mesh :
kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole=cluster-admin \ --user=USER_ACCOUNT
Télécharger le fichier d'installation
- Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.2-asm.2-linux-amd64.tar.gz
- Téléchargez le fichier de signature et utilisez
openssl
pour valider la signature :curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.2-asm.2-linux-amd64.tar.gz.1.sig openssl dgst -verify /dev/stdin -signature istio-1.8.2-asm.2-linux-amd64.tar.gz.1.sig istio-1.8.2-asm.2-linux-amd64.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
La sortie attendue est
Verified OK
. -
Extrayez le contenu du fichier vers n’importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :
tar xzf istio-1.8.2-asm.2-linux-amd64.tar.gz
Cette commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé
istio-1.8.2-asm.2
, qui contient les éléments suivants :- Des exemples d'applications dans le répertoire
samples
- L'outil de ligne de commande
istioctl
que vous utilisez pour installer Anthos Service Mesh et qui se trouve dans le répertoirebin
- Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire
manifests/profiles
- Des exemples d'applications dans le répertoire
- Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.2-asm.2-osx.tar.gz
- Téléchargez le fichier de signature et utilisez
openssl
pour valider la signature :curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.2-asm.2-osx.tar.gz.1.sig openssl dgst -sha256 -verify /dev/stdin -signature istio-1.8.2-asm.2-osx.tar.gz.1.sig istio-1.8.2-asm.2-osx.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
La sortie attendue est
Verified OK
. -
Extrayez le contenu du fichier vers n’importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :
tar xzf istio-1.8.2-asm.2-osx.tar.gz
Cette commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé
istio-1.8.2-asm.2
, qui contient les éléments suivants :- Des exemples d'applications dans le répertoire
samples
- L'outil de ligne de commande
istioctl
que vous utilisez pour installer Anthos Service Mesh et qui se trouve dans le répertoirebin
- Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire
manifests/profiles
- Des exemples d'applications dans le répertoire
- Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.2-asm.2-win.zip
- Téléchargez le fichier de signature et utilisez
openssl
pour valider la signature :curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.2-asm.2-win.zip.1.sig openssl dgst -verify - -signature istio-1.8.2-asm.2-win.zip.1.sig istio-1.8.2-asm.2-win.zip <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
La sortie attendue est
Verified OK
. -
Extrayez le contenu du fichier vers n’importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :
tar xzf istio-1.8.2-asm.2-win.zip
Cette commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé
istio-1.8.2-asm.2
, qui contient les éléments suivants :- Des exemples d'applications dans le répertoire
samples
- L'outil de ligne de commande
istioctl
que vous utilisez pour installer Anthos Service Mesh et qui se trouve dans le répertoirebin
- Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire
manifests/profiles
- Des exemples d'applications dans le répertoire
- Assurez-vous d'être dans le répertoire racine de l'installation d'Anthos Service Mesh.
cd istio-1.8.2-asm.2
- Pour plus de commodité, ajoutez les outils du répertoire
/bin
à votre variable PATH :export PATH=$PWD/bin:$PATH
Linux
macOS
Windows
Mettre à niveau Anthos Service Mesh
Pour installer une nouvelle version d'Anthos Service Mesh, nous vous recommandons de suivre le processus de mise à niveau basé sur la révision (également appelé mise à niveau Canary). Avec une mise à niveau basée sur la révision, vous installez une nouvelle version du plan de contrôle en même temps que le plan de contrôle existant. Lors de l'installation de la nouvelle version, vous incluez le libellé revision
qui identifie la version du nouveau plan de contrôle. Chaque révision est une mise en œuvre complète du plan de contrôle d'Anthos Service Mesh avec ses propres déploiement et service.
Vous effectuez ensuite une migration vers la nouvelle version en définissant le même libellé revision
sur vos charges de travail de sorte qu'il pointe vers le nouveau plan de contrôle et en effectuant un redémarrage progressif pour réinjecter les proxys avec la nouvelle version d'Anthos Service Mesh. Avec cette approche, vous pouvez surveiller l'effet de la mise à niveau sur un petit pourcentage de vos charges de travail. Après avoir testé votre application, vous pouvez migrer tout le trafic vers la nouvelle version. Cette approche est beaucoup plus sûre qu'une mise à niveau sur place, où un nouveau plan de contrôle remplace la version précédente.
Mettre à jour le plan de contrôle
Exécutez la commande suivante pour déployer le nouveau plan de contrôle. Si vous souhaitez activer une fonctionnalité facultative compatible, incluez -f
et le nom de fichier YAML dans la ligne de commande suivante. Pour en savoir plus, consultez la page Activer les fonctionnalités facultatives.
istioctl install \ --set profile=asm-multicloud \ --set revision=asm-182-2
L'argument --set revision
ajoute un libellé istio.io/rev
à istiod
. Après avoir exécuté la commande, deux déploiements de plan de contrôle et des services s'exécutent côte à côte :
kubectl get pods -n istio-system
Exemple de résultat :
NAME READY STATUS RESTARTS AGE istio-ingressgateway-c56675fcd-86zdn 1/1 Running 0 2m9s istio-ingressgateway-c56675fcd-vn4nv 1/1 Running 0 2m21s istiod-asm-182-2-6d5cfd4b89-xztlr 1/1 Running 0 3m44s istiod-fb7f746f4-wcntn 1/1 Running 0 50m promsd-579f9f9bf4-m65nc 2/2 Running 1 50m
Déployer et redéployer des charges de travail
Votre installation n'est pas terminée tant que vous n'avez pas activé l'injection automatique du proxy side-car (injection automatique). Les migrations depuis OSS Istio et les mises à niveau suivent le processus de mise à niveau basé sur la révision (processus appelé "mises à jour Canary" dans la documentation d'Istio). Pour une mise à niveau basée sur la révision, la nouvelle version de istiod
est installée avec l'élément istiod
existant. Vous déplacez ensuite certaines de vos charges de travail vers la nouvelle version, ce qui vous permet de surveiller l'effet de la mise à niveau avec un faible pourcentage des charges de travail avant de migrer tout le trafic vers la nouvelle version.
Pour activer l'injection automatique, vous devez obtenir le libellé de révision que vous avez utilisé lorsque vous avez exécuté istioctl install
et appliquer le même libellé de révision à vos espaces de noms. Le libellé de révision est utilisé par le webhook d'injecteur sidecar afin d'associer les sidecars injectés à une révision istiod
spécifique. Après avoir ajouté le libellé, tous les pods existants dans l'espace de noms doivent être redémarrés pour que les sidecars soient injectés.
Activer l'injection automatique
Suivez ces étapes pour activer l'injection automatique.
Exécutez la commande suivante pour localiser le libellé de révision sur
istiod
:kubectl -n istio-system get pods -l app=istiod --show-labels
La sortie de la commande ressemble à ceci : Notez que le résultat de la migration est légèrement différent de celui des mises à niveau. L'exemple de résultat suivant provient d'une migration.
NAME READY STATUS RESTARTS AGE LABELS istiod-7744bc8dd7-qhlss 1/1 Running 0 49m app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7 istiod-asm-182-2-85d86774f7-flrt2 1/1 Running 0 26m app=istiod,istio.io/rev=asm-182-2,istio=istiod,pod-template-hash=85d86774f7 istiod-asm-182-2-85d86774f7-tcwtn 1/1 Running 0 26m app=istiod,istio.io/rev=asm-182-2,istio=istiod,pod-template-hash=85d86774f7
Dans le résultat, sous la colonne
LABELS
, notez la valeur du libellé de révisionistiod
pour la nouvelle version, à la suite du préfixeistio.io/rev=
. Dans cet exemple, la valeur estasm-182-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 deistiod
estdefault
.
Ajoutez le libellé de révision à un espace de noms 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 terminer 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.
Supprimez l'ancienne version de
istiod
. Dans la commande suivante, remplacezOLD_REVISION
par le libellé de révision pour la version précédente deistiod
.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
La sortie de la commande ressemble à ceci :
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
Redéployez la version précédente du fichier
istio-ingressgateway
:kubectl -n istio-system rollout undo deploy istio-ingressgateway
Résultat attendu en cas de succès :
deployment.apps/istio-ingressgateway rolled back
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 ressemble à ce qui suit :
istiooperator.install.istio.io "installed-state-REVISION" deleted