Mettre à niveau Anthos Service Mesh sur GKE dans un réseau maillé multiprojet

Ce guide explique comment passer de 1.9 or a 1.10 patch release à Anthos Service Mesh 1.10.6 sur un cluster Google Kubernetes Engine (GKE) pour un maillage contenant plusieurs clusters qui se trouvent dans des projets Google Cloud différents.

Avant de commencer

Avant d'installer Anthos Service Mesh, assurez-vous de disposer des éléments suivants :

Préparer la mise à niveau

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.

Le script suit le processus de mise à niveau basé sur la révision (processus appelé mises à jour "Canary" dans la documentation d'Istio). Avec une mise à niveau basée sur la révision, le script installe une nouvelle révision du plan de contrôle en parallèle du plan de contrôle existant. Lors de l'installation de la nouvelle version, le script inclut un libellé revision qui identifie le nouveau plan de contrôle.

Vous effectuez ensuite une migration vers la nouvelle version en définissant le même libellé revision sur vos charges de travail et en effectuant un redémarrage progressif pour réinjecter les proxys afin qu'ils utilisent la nouvelle version et la nouvelle configuration 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ù les nouveaux composants du plan de contrôle remplacent la version précédente.

Configurer les variables d'environnement

  1. Obtenez l'ID du projet dans lequel le cluster a été créé et le numéro du projet hôte d'Environ.

    gcloud

    Exécutez la commande suivante :

    gcloud projects list

    Console

    1. Accédez à la page Tableau de bord de la console Google Cloud.

      Accéder à la page "Tableau de bord"

    2. Cliquez sur la liste déroulante de sélection du projet située en haut de la page. Sélectionnez votre projet dans la fenêtre Sélectionnez une organisation 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.

  2. Créez une variable d'environnement pour l'ID du projet dans lequel le cluster a été créé: 

    export PROJECT_ID=YOUR_PROJECT_ID

  3. Créez une variable d'environnement pour le numéro du projet hôte d'Environ.

    export ENVIRON_PROJECT_NUMBER=YOUR_ENVIRON_PROJECT_NUMBER

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

  5. Définissez la zone ou la région par défaut pour Google Cloud CLI. Si vous ne définissez pas la valeur par défaut ici, veillez à spécifier l'option --zone ou --region dans les commandes gcloud container clusters de cette page.

    • 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}

    Conseil : Pour faciliter la configuration de votre environnement shell à l'avenir, vous pouvez copier et coller les instructions export de chaque variable d'environnement dans un script shell simple auquel vous appliquez source lorsque vous démarrez une nouvelle interface système. Vous pouvez également ajouter les commandes gcloud qui définissent des valeurs par défaut pour le script, ou utiliser gcloud init pour créer et activer une configuration nommée gcloud.

Définir des identifiants et des autorisations

  1. Obtenez des identifiants d'authentification pour interagir avec le cluster : Cette commande définit également le contexte actuel de kubectl sur le cluster.

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --project=${PROJECT_ID}

  2. 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 poursuivre avec le cluster-admin-binding existant.

Télécharger le fichier d'installation

Linux

  1. 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.10.6-asm.2-linux-amd64.tar.gz

  2. 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.10.6-asm.2-linux-amd64.tar.gz.1.sig
openssl dgst -verify /dev/stdin -signature istio-1.10.6-asm.2-linux-amd64.tar.gz.1.sig istio-1.10.6-asm.2-linux-amd64.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

    Le résultat attendu est Verified OK.

  3. 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.10.6-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.10.6-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épertoire bin
    • Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire manifests/profiles

  4. Assurez-vous d'être dans le répertoire racine de l'installation Anthos Service Mesh.

    cd istio-1.10.6-asm.2

macOS

  1. 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.10.6-asm.2-osx.tar.gz

  2. 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.10.6-asm.2-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.10.6-asm.2-osx.tar.gz.1.sig istio-1.10.6-asm.2-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

    Le résultat attendu est Verified OK.

  3. 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.10.6-asm.2-osx.tar.gz

    Cette commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé istio-1.10.6-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épertoire bin
    • Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire manifests/profiles

  4. Assurez-vous d'être dans le répertoire racine de l'installation Anthos Service Mesh.

    cd istio-1.10.6-asm.2

Windows

  1. 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.10.6-asm.2-win.zip

  2. 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.10.6-asm.2-win.zip.1.sig
openssl dgst -verify - -signature istio-1.10.6-asm.2-win.zip.1.sig istio-1.10.6-asm.2-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

    Le résultat attendu est Verified OK.

  3. 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.10.6-asm.2-win.zip

    Cette commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé istio-1.10.6-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épertoire bin
    • Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire manifests/profiles

  4. Assurez-vous d'être dans le répertoire racine de l'installation Anthos Service Mesh.

    cd istio-1.10.6-asm.2

Préparer les fichiers de configuration des ressources

Lorsque vous exécutez la commande istioctl install, vous spécifiez -f istio-operator.yaml sur la ligne de commande. Ce fichier contient des informations sur le projet et le cluster requis par Anthos Service Mesh. Vous devez télécharger un package contenant istio-operator.yaml et d'autres fichiers de configuration des ressources afin de pouvoir définir les informations sur le projet et le cluster.

Pour préparer les fichiers de configuration des ressources, procédez comme suit :

Mesh CA

  1. Créez un répertoire pour les fichiers de configuration des ressources du package Anthos Service Mesh. Nous vous recommandons d'utiliser le nom du cluster comme nom de répertoire.

  2. Accédez au répertoire dans lequel vous souhaitez télécharger le package Anthos Service Mesh.

  3. Validez la version de kpt. Assurez-vous d'exécuter une version antérieure à 1.x de kpt :

    kpt version

    La sortie devrait ressembler à ce qui suit :

    0.39.2

    Si vous disposez de la version 1.x ou d'une version ultérieure de kpt, consultez la page Configurer votre environnement pour télécharger la version requise pour votre système d'exploitation.

  4. Téléchargez le package :

    kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.10-asm asm

  5. Définissez l'ID du projet dans lequel le cluster a été créé :

    kpt cfg set asm gcloud.core.project ${PROJECT_ID}

  6. Définissez le numéro de projet du projet hôte du parc :

    kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}

  7. Définissez le nom du cluster :

    kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}

  8. Définissez la zone ou la région par défaut :

    kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}

  9. Définissez le tag sur la version d'Anthos Service Mesh que vous installez :

    kpt cfg set asm anthos.servicemesh.tag 1.10.6-asm.2

  10. Définissez la révision dans les fichiers de configuration des ressources du package Anthos Service Mesh :

    kpt cfg set asm anthos.servicemesh.rev asm-1106-2

    Lorsque vous installez Anthos Service Mesh, vous définissez un libellé de révision sur istiod. Vous devez définir la même révision sur le webhook de validation.

  11. Comme les clusters de votre configuration multicluster se trouvent dans différents projets, vous devez configurer les alias de domaine de confiance pour les autres projets qui forment les maillages de services multi-clusters/multiprojets.

    1. Obtenez l'ID de projet de tous les clusters qui se trouveront dans le maillage multicluster/multiprojet.

    2. Pour l'ID de projet de chaque cluster, définissez les alias de domaine de confiance. Par exemple, si vous avez des clusters dans trois projets, exécutez la commande suivante en remplaçant PROJECT_ID_1, PROJECT_ID_2 et PROJECT_ID_3 par l'ID de projet de chaque cluster.

      kpt cfg set asm anthos.servicemesh.trustDomainAliases PROJECT_ID_1.svc.id.goog PROJECT_ID_2.svc.id.goog PROJECT_ID_3.svc.id.goog

      Lorsque vous configurez les clusters dans les autres projets, vous pouvez exécuter la même commande.

      Les alias de domaine de confiance permettent à Mesh CA d'authentifier les charges de travail sur les clusters d'autres projets. En plus de définir les alias de domaine de confiance, vous devez activer l'équilibrage de charge interclusters après avoir installé Anthos Service Mesh.

  12. Affichez les valeurs des setters kpt :

    kpt cfg list-setters asm

    La sortie de la commande ressemble à ceci : 

                              NAME                                                       VALUE
anthos.servicemesh.canonicalServiceHub               gke.gcr.io/asm/canonical-service-controller:1.10.6-asm.2
anthos.servicemesh.controlplane.monitoring.enabled   true
anthos.servicemesh.hub                               gke.gcr.io/asm
anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
anthos.servicemesh.tag                               1.10.6-asm.2
anthos.servicemesh.trustDomainAliases                [example-project-12345.svc.id.goog,example-project-23456.svc.id.goog,example-project-98765.svc.id.goog]
base-dir                                             base
gcloud.compute.location                              us-central
gcloud.compute.network                               default
gcloud.compute.subnetwork                            default
gcloud.container.cluster                             example-cluster-1
gcloud.container.cluster.clusterSecondaryRange
gcloud.container.cluster.releaseChannel              REGULAR
gcloud.container.cluster.servicesSecondaryRange
gcloud.container.nodepool.max-nodes                  4
gcloud.core.project                                  example-project-12345
gcloud.project.environProjectID                      FLEET_PROJECT_ID
gcloud.project.environProjectNumber                  1234567890123
gcloud.project.projectNumber                         9876543210987

    Vérifiez que les valeurs pour les setters suivantes sont correctes :

    • anthos.servicemesh.rev
    • anthos.servicemesh.tag
    • anthos.servicemesh.trustDomainAliases
    • gcloud.compute.location
    • gcloud.container.cluster
    • gcloud.core.project
    • gcloud.project.environProjectNumber

    Vous pouvez ignorer les valeurs des autres setters.

Istio CA

  1. Créez un répertoire pour les fichiers de configuration des ressources du package Anthos Service Mesh. Nous vous recommandons d'utiliser le nom du cluster comme nom de répertoire.

  2. Accédez au répertoire dans lequel vous souhaitez télécharger le package Anthos Service Mesh.

  3. Validez la version de kpt. Assurez-vous d'exécuter une version antérieure à 1.x de kpt :

    kpt version

    La sortie devrait ressembler à ce qui suit :

    0.39.2

    Si vous disposez de la version 1.x ou ultérieure de kpt, téléchargez la version requise :

    curl -L https://github.com/GoogleContainerTools/kpt/releases/download/v0.39.2/kpt_linux_amd64 > kpt_0_39_2
chmod +x kpt_0_39_2
alias kpt="$(readlink -f kpt_0_39_2)"

  4. Téléchargez le package :

    kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.10-asm asm

  5. Définissez l'ID du projet dans lequel le cluster a été créé :

    kpt cfg set asm gcloud.core.project ${PROJECT_ID}

  6. Définissez le numéro de projet du projet hôte du parc :

    kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}

  7. Définissez le nom du cluster :

    kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}

  8. Définissez la zone ou la région par défaut :

    kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}

  9. Définissez le tag sur la version d'Anthos Service Mesh que vous installez :

    kpt cfg set asm anthos.servicemesh.tag 1.10.6-asm.2

  10. Définissez la révision dans les fichiers de configuration des ressources du package Anthos Service Mesh :

    kpt cfg set asm anthos.servicemesh.rev asm-1106-2

  11. Affichez les valeurs des setters kpt :

    kpt cfg list-setters asm

    La sortie de la commande ressemble à ceci : 

                              NAME                                                       VALUE
anthos.servicemesh.canonicalServiceHub               gke.gcr.io/asm/canonical-service-controller:1.10.6-asm.2
anthos.servicemesh.controlplane.monitoring.enabled   true
anthos.servicemesh.hub                               gke.gcr.io/asm
anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
anthos.servicemesh.tag                               1.10.6-asm.2
anthos.servicemesh.trustDomainAliases
base-dir                                             base
gcloud.compute.location                              us-central
gcloud.compute.network                               default
gcloud.compute.subnetwork                            default
gcloud.container.cluster                             example-cluster-1
gcloud.container.cluster.clusterSecondaryRange
gcloud.container.cluster.releaseChannel              REGULAR
gcloud.container.cluster.servicesSecondaryRange
gcloud.container.nodepool.max-nodes                  4
gcloud.core.project                                  example-project-12345
gcloud.project.environProjectID                      FLEET_PROJECT_ID
gcloud.project.environProjectNumber                  1234567890123
gcloud.project.projectNumber                         9876543210987

    Vérifiez que les valeurs pour les setters suivantes sont correctes :

    • anthos.servicemesh.rev
    • anthos.servicemesh.tag
    • gcloud.compute.location
    • gcloud.container.cluster
    • gcloud.core.project
    • gcloud.project.environProjectNumber

    Vous pouvez ignorer les valeurs des autres setters.

Mettre à niveau Anthos Service Mesh

Mesh CA

  1. Vérifiez que le contexte kubeconfig actuel pointe vers le cluster sur lequel vous souhaitez installer Anthos Service Mesh :

    kubectl config current-context

    Le résultat est au format suivant :

    gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

    Le contexte kubeconfig et les valeurs des Setters kpt doivent correspondre. Si nécessaire, exécutez la commande gcloud container clusters get-credentials pour définir le contexte kubeconfig actuel.

  2. Si nécessaire, basculez vers le répertoire istio-1.10.6-asm.2. Le client istioctl dépend de la version. Veillez à utiliser la version dans le répertoire istio-1.10.6-asm.2/bin.

  3. Exécutez la commande suivante pour déployer le nouveau plan de contrôle avec le profil asm-gcp-multiproject. Si vous souhaitez activer une fonctionnalité facultative compatible, incluez -f et le nom de fichier YAML dans la ligne de commande suivante. Pour plus d'informations, consultez la page Activer les fonctionnalités facultatives.

    bin/istioctl install \
  -f asm/istio/istio-operator.yaml \
  -f asm/istio/options/multiproject.yaml \
  -f asm/istio/options/multicluster.yaml \
  --revision=asm-1106-2

    L'argument --revision ajoute un libellé de révision au format istio.io/rev=asm-1106-2 à istiod. Le libellé de révision est utilisé par le webhook d'injecteur side-car automatique pour associer les side-cars injectés à une révision istiod particulière. Pour activer l'injection side-car automatique sur un espace de noms, vous devez lui attribuer un libellé associé à une révision correspondant à un déploiement istiod.

    Les fichiers suivants remplacent les paramètres du fichier istio-operator.yaml :

    • Le fichier multiproject.yaml définit le profil asm-gcp-multiproject.

    • Le fichier multicluster.yaml configure les paramètres dont Anthos Service Mesh a besoin pour une configuration multicluster.

  4. Vérifiez que les pods du plan de contrôle dans istio-system sont opérationnels :

    kubectl get pods -n istio-system

    Exemple de résultat :

    NAME                                        READY   STATUS    RESTARTS   AGE
istio-ingressgateway-c56675fcd-86zdn        1/1     Running   0          2m9s
istiod-asm-1106-2-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

    Deux services et déploiements de plan de contrôle s'exécutent côte à côte.

  5. Déployez le contrôleur de service canonique sur votre cluster :

    kubectl apply -f asm/canonical-service/controller.yaml

    Le contrôleur de service canonique regroupe les charges de travail appartenant au même service logique. Pour en savoir plus sur les services canoniques, consultez la présentation du Service canonique.

Istio CA

  1. Vérifiez que le contexte kubeconfig actuel pointe vers le cluster sur lequel vous souhaitez installer Anthos Service Mesh :

    kubectl config current-context

    Le résultat est au format suivant :

    gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

    Le contexte kubeconfig et les valeurs des Setters kpt doivent correspondre. Si nécessaire, exécutez la commande gcloud container clusters get-credentials pour définir le contexte kubeconfig actuel.

  2. Si nécessaire, basculez vers le répertoire istio-1.10.6-asm.2. Le client istioctl dépend de la version. Veillez à utiliser la version dans le répertoire istio-1.10.6-asm.2/bin.

  3. Exécutez la commande suivante pour déployer le nouveau plan de contrôle avec le profil asm-gcp-multiproject. Si vous souhaitez activer une fonctionnalité facultative compatible, incluez -f et le nom de fichier YAML dans la ligne de commande suivante. Pour plus d'informations, consultez la page Activer les fonctionnalités facultatives.

    bin/istioctl install \
  -f asm/istio/istio-operator.yaml \
  -f asm/istio/options/citadel-ca.yaml \
  -f asm/istio/options/multiproject.yaml \
  -f asm/istio/options/multicluster.yaml \
  --revision=asm-1106-2

    L'argument --revision ajoute un libellé de révision au format istio.io/rev=asm-1106-2 à istiod. Le libellé de révision est utilisé par le webhook d'injecteur side-car automatique pour associer les side-cars injectés à une révision istiod particulière. Pour activer l'injection side-car automatique sur un espace de noms, vous devez lui attribuer un libellé associé à une révision correspondant à un déploiement istiod.

    Les fichiers suivants remplacent les paramètres du fichier istio-operator.yaml :

    • Le fichier citadel-ca.yaml configure Istio CA en tant qu'autorité de certification.

    • Le fichier multiproject.yaml définit le profil asm-gcp-multiproject.

    • Le fichier multicluster.yaml configure les paramètres dont Anthos Service Mesh a besoin pour une configuration multicluster.

  4. Vérifiez que les pods du plan de contrôle dans istio-system sont opérationnels :

    kubectl get pods -n istio-system

    Exemple de résultat :

    NAME                                        READY   STATUS    RESTARTS   AGE
istio-ingressgateway-c56675fcd-86zdn        1/1     Running   0          2m9s
istiod-asm-1106-2-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

    Deux services et déploiements de plan de contrôle s'exécutent côte à côte.

  5. Déployez le contrôleur de service canonique sur votre cluster :

    kubectl apply -f asm/canonical-service/controller.yaml

    Le contrôleur de service canonique regroupe les charges de travail appartenant au même service logique. Pour en savoir plus sur les services canoniques, consultez la présentation du Service canonique.

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). Avec une mise à niveau basée sur la révision, la nouvelle version du plan de contrôle est installée en parallèle du plan de contrôle 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.

Lorsque vous avez exécuté istioctl install, vous avez défini un libellé de révision au format istio.io/rev=asm-1106-2 sur istiod. Pour activer l'injection automatique, vous devez ajouter un libellé de révision correspondant à votre ou vos espaces de noms. Le libellé de révision est utilisé par le webhook d'injecteur sidecar pour associer les sidecars injectés à une révision istiod particulière. Après avoir ajouté le libellé, redémarrez les pods de l'espace de noms pour que les sidecars soient injectés.

  1. Obtenez le libellé de révision associé à istiod et istio-ingressgateway.

    kubectl get pod -n istio-system -L istio.io/rev

    La sortie de la commande ressemble à ceci : 

    NAME                                             READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-65d884685d-6hrdk            1/1     Running   0          67m
istio-ingressgateway-65d884685d-94wgz            1/1     Running   0          67m
istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-1106-2
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1106-2
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

    1. 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-1106-2.

    2. 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 de résultat, la valeur du libellé de révision pour l'ancienne version est asm-198-3.

  2. Basculez istio-ingressgateway vers la nouvelle révision. Dans la commande suivante, remplacez REVISION 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"}]'

    Résultat attendu : service/istio-ingressgateway patched

  3. Ajoutez le libellé de révision à un espace de noms et supprimez le libellé istio-injection (s'il existe). Dans la commande suivante, remplacez REVISION par la valeur correspondant à la nouvelle révision de istiod.

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

  4. Redémarrez les pods pour déclencher la réinjection :

    kubectl rollout restart deployment -n NAMESPACE

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

  6. Testez votre application pour vérifier que les charges de travail fonctionnent correctement.

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

  8. 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 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 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-ingressgateway. 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. Assurez-vous que la valeur de REVISION dans la commande suivante est correcte.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true

    6. Supprimez la nouvelle version de istiod. Assurez-vous que la valeur de REVISION dans la commande suivante est correcte.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true

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

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

Étapes suivantes