Ce guide explique effectuer une mise à niveau d'Anthos Service Mesh de la version 1.4.5+ vers la version 1.4.10 sur Google Kubernetes Engine. Si vous souhaitez passer à Anthos Service Mesh 1.5, consultez la page Mettre à niveau Anthos Service Mesh sur GKE dédiée à la version 1.5.
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
Cette section décrit les étapes que vous devez suivre pour mettre à niveau Anthos Service Mesh.
Consultez la page Fonctionnalités compatibles et ce guide pour vous familiariser avec les fonctionnalités et le processus de mise à niveau.
Examinez vos stratégies d'autorisation pour voir si elles doivent être mises à jour.
Lorsque vous avez installé la version précédente d'Anthos Service Mesh, si vous avez activé des fonctionnalités facultatives en ajoutant des options
--set values
à la commande en ligneistioctl apply
, vous devez utiliser les mêmes indicateurs lorsque vous exécutezistioctl apply
pour mettre à niveau vers la version 1.4.10.Lorsque vous avez installé la version précédente d'Anthos Service Mesh, si vous avez activé des fonctionnalités facultatives en ajoutant des options
-f
à la commande en ligneistioctl apply
pour spécifier un fichier YAML, vous devez spécifier le même fichier (ou un fichier présentant le même contenu) lorsque vous exécutezistioctl apply
pour installer 1.4.10.Planifiez un temps d'arrêt. La mise à niveau peut prendre jusqu'à une heure en fonction de l'échelle du cluster. Notez que cela n'inclut pas le temps nécessaire au redéploiement des charges de travail afin de mettre à jour les proxys side-car.
Définir les valeurs par défaut du projet et du cluster
Obtenez l'ID du projet dans lequel le cluster a été créé :
gcloud
gcloud projects list
Console
Dans la console Google Cloud, accédez à la page Tableau de bord :
Cliquez sur la liste déroulante Sélectionner située en haut de la page. Sélectionnez votre projet dans la fenêtre Sélectionner qui vous est présentée. L'ID du projet est affiché sur la fiche Informations sur le projet du tableau de bord du projet.
Créez une variable d'environnement pour l'ID de projet :
export PROJECT_ID=
YOUR_PROJECT_ID
Créez une variable d'environnement pour le numéro de projet :
export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
Définissez l'ID de projet par défaut pour Google Cloud CLI :
gcloud config set project ${PROJECT_ID}
Créez les variables d'environnement suivantes :
Définissez le nom du cluster :
export CLUSTER_NAME=YOUR_CLUSTER_NAME
Définissez le paramètre
CLUSTER_LOCATION
sur la zone ou la région de votre cluster :export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION
Définissez le pool de charges de travail.
export WORKLOAD_POOL=${PROJECT_ID}.svc.id.goog
Définissez l'ID du réseau maillé.
export MESH_ID="proj-${PROJECT_NUMBER}"
Définissez la zone ou la région par défaut pour Google Cloud CLI.
Si vous disposez d'un cluster à zone unique, définissez la zone par défaut :
gcloud config set compute/zone ${CLUSTER_LOCATION}
Si vous disposez d'un cluster régional, définissez la région par défaut :
gcloud config set compute/region ${CLUSTER_LOCATION}
Définir des identifiants et des autorisations
-
Obtenez des
identifiants d'authentification pour interagir avec le cluster:
gcloud container clusters get-credentials ${CLUSTER_NAME}
-
Accordez des autorisations d'administrateur de cluster à l'utilisateur actuel. 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="$(gcloud config get-value core/account)"
Si l'erreur
"cluster-admin-binding" already exists
s'affiche, vous pouvez l'ignorer en toute sécurité et continuer avec le cluster-admin-binding existant.
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.4.10-asm.18-linux.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.4.10-asm.18-linux.tar.gz.1.sig openssl dgst -verify - -signature istio-1.4.10-asm.18-linux.tar.gz.1.sig istio-1.4.10-asm.18-linux.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
La sortie attendue est
Verified OK
. -
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.4.10-asm.18-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.4.10-asm.18-osx.tar.gz.1.sig openssl dgst -sha256 -verify /dev/stdin -signature istio-1.4.10-asm.18-osx.tar.gz.1.sig istio-1.4.10-asm.18-osx.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
La sortie attendue est
Verified OK
. -
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.4.10-asm.18-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.4.10-asm.18-win.zip.1.sig openssl dgst -verify - -signature istio-1.4.10-asm.18-win.zip.1.sig istio-1.4.10-asm.18-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.4.10-asm.18-linux.tar.gz
La commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé
istio-1.4.10-asm.18
, et qui contient les éléments suivants:- Des exemples d'application dans
samples
- Les outils suivants dans le répertoire
bin
:istioctl
: utilisezistioctl
pour installer Anthos Service Mesh.asmctl
: utilisezasmctl
pour valider votre configuration de sécurité après avoir installé Anthos Service Mesh. (Actuellement,asmctl
n'est pas compatible avec GKE sur VMware.)
- Des exemples d'application dans
-
Assurez-vous d'être dans le répertoire racine de l'installation Anthos Service Mesh.
cd istio-1.4.10-asm.18
-
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
Cette section explique comment mettre à niveau Anthos Service Mesh et activer :
- Fonctionnalités par défaut compatibles répertoriées sur la page Fonctionnalités compatibles.
- l'autorité de certification Anthos Service Mesh (Mesh CA) ;
- le pipeline de données de télémétrie qui alimente le tableau de bord Anthos Service Mesh dans Google Cloud Console.
Pour plus d'informations sur l'activation des fonctionnalités facultatives compatibles, consultez Activer des fonctionnalités facultatives.
Pour mettre à niveau Anthos Service Mesh, procédez comme suit :
Choisissez l'une des commandes suivantes pour configurer Anthos Service Mesh en mode d'authentification TLS mutuel (mTLS) PERMISSIVE
ou en mode mTLS STRICT
.
mTLS en mode PERMISSIVE
istioctl manifest apply --set profile=asm \ --set values.global.trustDomain=${WORKLOAD_POOL} \ --set values.global.sds.token.aud=${WORKLOAD_POOL} \ --set values.nodeagent.env.GKE_CLUSTER_URL=https://container.googleapis.com/v1/projects/${PROJECT_ID}/locations/${CLUSTER_LOCATION}/clusters/${CLUSTER_NAME} \ --set values.global.meshID=${MESH_ID} \ --set values.global.proxy.env.GCP_METADATA="${PROJECT_ID}|${PROJECT_NUMBER}|${CLUSTER_NAME}|${CLUSTER_LOCATION}"
mTLS en mode STRICT
istioctl manifest apply --set profile=asm \ --set values.global.trustDomain=${WORKLOAD_POOL} \ --set values.global.sds.token.aud=${WORKLOAD_POOL} \ --set values.nodeagent.env.GKE_CLUSTER_URL=https://container.googleapis.com/v1/projects/${PROJECT_ID}/locations/${CLUSTER_LOCATION}/clusters/${CLUSTER_NAME} \ --set values.global.meshID=${MESH_ID} \ --set values.global.proxy.env.GCP_METADATA="${PROJECT_ID}|${PROJECT_NUMBER}|${CLUSTER_NAME}|${CLUSTER_LOCATION}" \ --set values.global.mtls.enabled=true
Vérifier les composants du plan de contrôle
La mise à niveau nécessite de réinstaller les composants du plan de contrôle. L'exécution de l'opération prend environ cinq à dix minutes. Les anciens composants du plan de contrôle sont arrêtés, puis supprimés à mesure que les nouveaux sont installés. Vous pouvez vérifier la progression en consultant la valeur de la colonne AGE
des charges de travail.
kubectl get pod -n istio-system
NAME READY STATUS RESTARTS AGE istio-galley-76d684bf9-jwz65 2/2 Running 0 5m36s istio-ingressgateway-5bfdf7c586-v6wxx 2/2 Terminating 0 25m istio-ingressgateway-7b598c5557-b88md 2/2 Running 0 5m44s istio-nodeagent-bnjg7 1/1 Running 0 5m16s istio-nodeagent-cps2j 1/1 Running 0 5m10s istio-nodeagent-f4x46 1/1 Running 0 5m26s istio-nodeagent-jbl5x 1/1 Running 0 5m38s istio-pilot-5dc4bc4dbf-ds5dh 2/2 Running 0 5m30s istio-pilot-74665549c5-7r6qh 2/2 Terminating 0 25m istio-sidecar-injector-7ddff4b99-b76l7 1/1 Running 0 5m36s promsd-6d4d5b7c5c-dgnd7 2/2 Running 0 5m30s
Dans cet exemple, il existe deux instances de istio-ingressgateway
et istio-pilot
. Les instances comportant comme valeur 25m
dans la colonne AGE
sont en cours d'arrêt.
Tous les autres composants sont installés.
Valider la mise à niveau
Nous vous recommandons d'utiliser l'outil d'analyse asmctl
pour valider la configuration de base de votre projet, de votre cluster et de vos charges de travail. Si un test asmctl
échoue, asmctl
recommande des solutions, si possible. La commande asmctl validate
exécute des tests de base qui vérifient :
- que les API requises par Anthos Service Mesh sont activées sur le projet ;
- que la passerelle Istio-Ingress est correctement configurée pour appeler Mesh CA ;
- l'état général d'Istiod et de la passerelle Istio-Ingress.
Si vous exécutez la commande asmctl validate
avec l'option facultative --with-testing-workloads
, en plus des tests de base, asmctl
exécute les tests de sécurité qui vérifient que :
- la communication TLS mutuelle (mTLS) est correctement configurée ;
- Mesh CA peut émettre des certificats.
Pour exécuter les tests de sécurité, asmctl
déploie des charges de travail sur votre cluster dans un espace de noms de test, exécute les tests de communication mTLS, fournit les résultats et supprime l'espace de noms de test.
Pour exécuter asmctl
, procédez comme suit :
Assurez-vous que les identifiants gcloud application-default sont définis :
gcloud auth application-default login
Si vous ne l'avez pas déjà fait, obtenez des identifiants d'authentification pour interagir avec le cluster :
gcloud container clusters get-credentials ${CLUSTER_NAME}
Pour exécuter à la fois les tests de base et de sécurité (en supposant que
istio-1.4.10-asm.18/bin
) se trouve dans votrePATH
), procédez comme suit :asmctl validate --with-testing-workloads
Si l'opération réussit, la commande renvoie une sortie semblable à ce qui suit :
[asmctl version 0.3.0] Using Kubernetes context: example-project_us-central1-example-cluster To change the context, use the --context flag Validating enabled APIs OK Validating ingressgateway configuration OK Validating istio system OK Validating sample traffic Launching example services... Sent traffic to example service http code: 200 verified mTLS configuration OK Validating issued certs OK
Mettre à jour des proxys side-car
Vous devez injecter ou mettre à jour le proxy side-car pour toutes les charges de travail qui s'exécutaient sur votre cluster avant la mise à niveau d'Anthos Service Mesh afin qu'elles disposent de la version actuelle de cet outil.
Avec l'injection automatique de side-car, vous pouvez mettre à jour les side-cars pour les pods existants avec un redémarrage du pod : Le redémarrage des pods varie selon qu'ils ont été créés dans le cadre d'un déploiement ou non.
Si vous avez utilisé un déploiement, redémarrez le déploiement pour redémarrer tous les pods avec des side-cars :
kubectl rollout restart YOUR_DEPLOYMENT -n YOUR_NAMESPACE
Si vous n'avez pas utilisé de déploiement, supprimez les pods. Ils sont automatiquement recréés avec les side-cars :
kubectl delete pod -n YOUR_NAMESPACE --all
Vérifiez que tous les pods de l'espace de noms disposent de side-cars injectés :
kubectl get pod -n YOUR_NAMESPACE --all
Dans l'exemple de résultat suivant de la commande précédente, la colonne
READY
indique qu'il existe deux conteneurs pour chacune de vos charges de travail : le conteneur principal et le conteneur du proxy side-car.NAME READY STATUS RESTARTS AGE YOUR_WORKLOAD 2/2 Running 0 20s ...
Mettre à jour vos stratégies d'autorisation
Si vous effectuez une mise à niveau à partir de la version Open Source d'Istio 1.4.x ou d'une version antérieure d'Anthos Service Mesh comportant des stratégies d'autorisation existantes, vous devrez peut-être les mettre à jour. Pour en savoir plus, consultez la page Mettre à jour vos stratégies d'autorisation.