Mettre à niveau un environnement GKE multicluster avec un objet Ingress multicluster

Last reviewed 2022-12-15 UTC

Autopilot Standard

---

Ce tutoriel explique comment mettre à niveau un environnement Google Kubernetes Engine (GKE) multicluster à l'aide de Multi Cluster Ingress. Ce tutoriel s'inscrit dans la continuité du document concernant les mises à niveau GKE multiclusters à l'aide de Multi Cluster Ingress, qui explique en détail le processus, l'architecture et les termes. Nous vous recommandons de lire le document conceptuel avant ce tutoriel.

Pour consulter une comparaison détaillée entre le service Multi Cluster Ingress (MCI), la passerelle multicluster (MCG) et un équilibreur de charge avec des groupes de points de terminaison du réseau autonomes (LB avec NEG autonomes), consultez la page Choisir votre API d'équilibrage de charge multicluster pour GKE.

Ce document est destiné aux administrateurs Google Cloud chargés de gérer les parcs de clusters GKE.

Nous vous recommandons de mettre à niveau automatiquement vos clusters GKE. La mise à niveau automatique est une façon entièrement gérée de mettre à niveau automatiquement vos clusters (plan de contrôle et nœuds) selon un calendrier de lancement déterminé par Google Cloud. Cela ne requiert aucune intervention de l'opérateur. Toutefois, si vous souhaitez mieux contrôler comment et quand les clusters sont mis à niveau, ce tutoriel décrit une méthode de mise à niveau de plusieurs clusters pour lesquels vos applications s'exécutent sur tous les clusters. Il utilise ensuite un objet Ingress multicluster pour drainer un cluster à la fois avant la mise à niveau.

Architecture

Ce tutoriel utilise l'architecture suivante. Trois clusters au total sont utilisés : deux clusters (blue et green) agissent comme des clusters identiques avec la même application déployée, et un cluster (ingress-config) sert de cluster de plan de contrôle qui configure l'objet Ingress multicluster. Dans ce tutoriel, vous allez déployer un exemple d'application sur deux clusters d'application (clusters blue et green).

Objectifs

• Créer trois clusters GKE et les enregistrer en tant que parc.
• Configurer un cluster GKE (ingress-config) en tant que cluster de configuration central.
• Déployer un exemple d'application sur les autres clusters GKE.
• Configurer Multi Cluster Ingress de manière à envoyer le trafic client vers l'application qui s'exécute sur les deux clusters d'application.
• Configurer un générateur de charge dans l'application et configurer la surveillance.
• Supprimer (drainer) un cluster d'application de l'objet Ingress multicluster et mettre à jour le cluster drainé.
• Rediriger le trafic vers le cluster mis à niveau à l'aide de l'objet Ingress multicluster.

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

• GKE
• Networking
• Cloud Load Balancing

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

1. Pour suivre ce tutoriel, vous devez configurer Ingress multicluster de façon à obtenir la configuration suivante :
   • Deux clusters ou plus avec les mêmes applications, tels que les espaces de noms, les Déploiements et les Services, exécutées sur tous les clusters.
   • La mise à niveau automatique est désactivée pour tous les clusters.
   • Les clusters sont des clusters de VPC natif qui utilisent des plages d'adresses IP d'alias.
   • L'équilibrage de charge HTTP doit être activé (activé par défaut).
   • gcloud --version doit être au minimum en version 369. Les étapes d'enregistrement du cluster GKE s'appuient sur cette version ou une version ultérieure.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

3. Make sure that billing is enabled for your Google Cloud project.

4. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

5. Définissez le projet par défaut :

   export PROJECT=$(gcloud info --format='value(config.project)')
   gcloud config set project ${PROJECT}
   

6. Activez les API GKE, Hub et multiclusteringress :

   gcloud services enable container.googleapis.com \
                          gkehub.googleapis.com \
                          multiclusteringress.googleapis.com \
                          multiclusterservicediscovery.googleapis.com
   

Configurer l'environnement

1. Dans Cloud Shell, clonez le dépôt pour obtenir les fichiers de ce tutoriel :

   cd ${HOME}
   git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
   

2. Créez un répertoire WORKDIR :

   cd kubernetes-engine-samples/networking/gke-multicluster-upgrade-mci/
   export WORKDIR=`pwd`
   

Créer et enregistrer des clusters GKE dans Hub

Dans cette section, vous allez créer trois clusters GKE et les enregistrer dans GKE Enterprise Hub.

Créer des clusters GKE

1. Dans Cloud Shell, créez trois clusters GKE :

   gcloud container clusters create ingress-config --zone us-west1-a \
   --release-channel=None --no-enable-autoupgrade --num-nodes=4 \
   --enable-ip-alias --workload-pool=${PROJECT}.svc.id.goog --quiet --async
   gcloud container clusters create blue --zone us-west1-b --num-nodes=3 \
   --release-channel=None --no-enable-autoupgrade --enable-ip-alias \
   --workload-pool=${PROJECT}.svc.id.goog --quiet --async
   gcloud container clusters create green --zone us-west1-c --num-nodes=3 \
   --release-channel=None --no-enable-autoupgrade --enable-ip-alias \
   --workload-pool=${PROJECT}.svc.id.goog --quiet
   

   Pour les besoins de ce tutoriel, vous allez créer les clusters dans trois zones différentes au sein d'une même région : us-west1-a, us-west1-b et us-west1-c. Pour en savoir plus sur les régions et les zones, consultez la section Zones géographiques et régions.

2. Attendez quelques minutes jusqu'à ce que tous les clusters soient créés. Assurez-vous que les clusters sont en cours d'exécution :

   gcloud container clusters list
   

   Le résultat ressemble à ce qui suit :

   NAME: ingress-config
   LOCATION: us-west1-a
   MASTER_VERSION: 1.22.8-gke.202
   MASTER_IP: 35.233.186.135
   MACHINE_TYPE: e2-medium
   NODE_VERSION: 1.22.8-gke.202
   NUM_NODES: 4
   STATUS: RUNNING
   
   NAME: blue
   LOCATION: us-west1-b
   MASTER_VERSION: 1.22.8-gke.202
   MASTER_IP: 34.82.35.222
   MACHINE_TYPE: e2-medium
   NODE_VERSION: 1.22.8-gke.202
   NUM_NODES: 3
   STATUS: RUNNING
   
   NAME: green
   LOCATION: us-west1-c
   MASTER_VERSION: 1.22.8-gke.202
   MASTER_IP: 35.185.204.26
   MACHINE_TYPE: e2-medium
   NODE_VERSION: 1.22.8-gke.202
   NUM_NODES: 3
   STATUS: RUNNING
   

3. Créez un fichier kubeconfig et connectez-vous à tous les clusters pour générer des entrées dans le fichier kubeconfig :

   touch gke-upgrade-kubeconfig
   export KUBECONFIG=gke-upgrade-kubeconfig
   gcloud container clusters get-credentials ingress-config \
       --zone us-west1-a --project ${PROJECT}
   gcloud container clusters get-credentials blue --zone us-west1-b \
       --project ${PROJECT}
   gcloud container clusters get-credentials green --zone us-west1-c \
       --project ${PROJECT}
   

   Le fichier kubeconfig vous permet de créer une authentification pour les clusters en créant un utilisateur et un contexte pour chaque cluster. Une fois que vous avez créé le fichier kubeconfig, vous pouvez rapidement basculer entre différents contextes pour les clusters.

4. Vérifiez que le fichier kubeconfig comporte trois clusters :

   kubectl config view -ojson | jq -r '.clusters[].name'
   

   Le résultat est le suivant :

   gke_gke-multicluster-upgrades_us-west1-a_ingress-config
   gke_gke-multicluster-upgrades_us-west1-b_blue
   gke_gke-multicluster-upgrades_us-west1-c_green
   

5. Obtenez le contexte des trois clusters pour une utilisation ultérieure :

   export INGRESS_CONFIG_CLUSTER=$(kubectl config view -ojson | jq \
       -r '.clusters[].name' | grep ingress-config)
   export BLUE_CLUSTER=$(kubectl config view -ojson | jq \
       -r '.clusters[].name' | grep blue)
   export GREEN_CLUSTER=$(kubectl config view -ojson | jq \
       -r '.clusters[].name' | grep green)
   echo -e "${INGRESS_CONFIG_CLUSTER}\n${BLUE_CLUSTER}\n${GREEN_CLUSTER}"
   

   Le résultat est le suivant :

   gke_gke-multicluster-upgrades_us-west1-a_ingress-config
   gke_gke-multicluster-upgrades_us-west1-b_blue
   gke_gke-multicluster-upgrades_us-west1-c_green
   

Enregistrer des clusters GKE dans un parc

L'enregistrement de vos clusters dans un parc vous permet de faire fonctionner vos clusters Kubernetes dans des environnements hybrides. Les clusters enregistrés dans des parcs peuvent utiliser des fonctionnalités GKE avancées, telles que le service Multi Cluster Ingress. Pour enregistrer un cluster GKE dans un parc, vous pouvez utiliser directement un compte de service Google Cloud, ou utiliser l'approche recommandée, Workload Identity Federation for GKE, qui permet à un compte de service Kubernetes de votre cluster GKE d'agir en tant que compte de service Identity and Access Management.

1. Enregistrez les trois clusters en tant que parc :

   gcloud container fleet memberships register ingress-config \
       --gke-cluster=us-west1-a/ingress-config \
       --enable-workload-identity
   
   gcloud container fleet memberships register blue \
       --gke-cluster=us-west1-b/blue \
       --enable-workload-identity
   
   gcloud container fleet memberships register green \
       --gke-cluster=us-west1-c/green \
       --enable-workload-identity
   

2. Vérifiez que les clusters sont enregistrés :

   gcloud container fleet memberships list
   

   Le résultat ressemble à ce qui suit :

   NAME: blue
   EXTERNAL_ID: 401b4f08-8246-4f97-a6d8-cf1b78c2a91d
   
   NAME: green
   EXTERNAL_ID: 8041c36a-9d42-40c8-a67f-54fcfd84956e
   
   NAME: ingress-config
   EXTERNAL_ID: 65ac48fe-5043-42db-8b1e-944754a0d725
   

3. Configurez le cluster ingress-config en tant que cluster de configuration pour Multi Cluster Ingress en activant la fonctionnalité multiclusteringress via le Hub :

   gcloud container fleet ingress enable --config-membership=ingress-config
   

   La commande précédente ajoute les CRD (Définitions de ressources personnalisées) MulticlusterIngress et MulticlusterService au cluster ingress-config. Cette opération prend quelques minutes. Attendez la fin de l'opération avant de passer à l'étape suivante.

4. Vérifiez que le cluster ingress-cluster a bien été configuré pour Multi Cluster Ingress :

   watch gcloud container fleet ingress describe
   

   Attendez jusqu'à obtenir un résultat semblable à ce qui suit :

   createTime: '2022-07-05T10:21:40.383536315Z'
   membershipStates:
     projects/662189189487/locations/global/memberships/blue:
       state:
         code: OK
         updateTime: '2022-07-08T10:59:44.230329189Z'
     projects/662189189487/locations/global/memberships/green:
       state:
         code: OK
         updateTime: '2022-07-08T10:59:44.230329950Z'
     projects/662189189487/locations/global/memberships/ingress-config:
       state:
         code: OK
         updateTime: '2022-07-08T10:59:44.230328520Z'
   name: projects/gke-multicluster-upgrades/locations/global/features/multiclusteringress
   resourceState:
     state: ACTIVE
   spec:
     multiclusteringress:
       configMembership: projects/gke-multicluster-upgrades/locations/global/memberships/ingress-config
   state:
     state:
       code: OK
       description: Ready to use
       updateTime: '2022-07-08T10:57:33.303543609Z'
   updateTime: '2022-07-08T10:59:45.247576318Z'
   

   Remarque : Cette fonctionnalité est inutilisable tant que votre cluster de configuration n'a pas l'état OK. Si vous ne voyez pas code: OK après quelques minutes, accédez à la section de dépannage.

   Pour quitter la commande watch, appuyez sur les touches Ctrl+C.

Déployer un exemple d'application sur les clusters blue et green

1. Dans Cloud Shell, déployez l'exemple d'application whereami sur les clusters blue et green :

   kubectl --context ${BLUE_CLUSTER} apply -f ${WORKDIR}/application-manifests
   kubectl --context ${GREEN_CLUSTER} apply -f ${WORKDIR}/application-manifests
   

2. Attendez quelques minutes et assurez-vous que tous les Pods des clusters blue et green ont l'état Running :

   kubectl --context ${BLUE_CLUSTER} get pods
   kubectl --context ${GREEN_CLUSTER} get pods
   

   Le résultat ressemble à ce qui suit :

   NAME                                   READY   STATUS    RESTARTS   AGE
   whereami-deployment-756c7dc74c-zsmr6   1/1     Running   0          74s
   NAME                                   READY   STATUS    RESTARTS   AGE
   whereami-deployment-756c7dc74c-sndz7   1/1     Running   0          68s.
   

Configurer un objet Ingress multicluster

Dans cette section, vous allez créer un objet Ingress multicluster qui envoie le trafic à l'application s'exécutant sur les clusters blue et green. Vous utilisez Cloud Load Balancing pour créer un équilibreur de charge qui utilise l'application whereami dans les clusters blue et green en tant que backends. Pour créer l'équilibreur de charge, vous avez besoin de deux types de ressources : une ressource MultiClusterIngress et une ou plusieurs ressources MultiClusterServices. Les objets MultiClusterIngress et MultiClusterService sont des ressources multiclusters correspondant aux ressources Kubernetes "Ingress" et "Service" utilisées dans le contexte d'un cluster unique.

1. Dans Cloud Shell, déployez la ressource MulticlusterIngress sur le cluster ingress-config :

   kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/multicluster-manifests/mci.yaml
   

   Le résultat est le suivant :

   multiclusteringress.networking.gke.io/whereami-mci created
   

2. Déployez la ressource MulticlusterServicesur le cluster ingress-config :

   kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/multicluster-manifests/mcs-blue-green.yaml
   

   Le résultat est le suivant :

   multiclusterservice.networking.gke.io/whereami-mcs created
   

3. Pour comparer les deux ressources, procédez comme suit :

   • Inspectez la ressource MulticlusterIngress :

     kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusteringress -o yaml
     

     Le résultat contient les éléments suivants :

     spec:
       template:
         spec:
           backend:
             serviceName: whereami-mcs
             servicePort: 8080
     

     La ressource MulticlusterIngress est semblable à la ressource Ingress Kubernetes, à la différence que la spécification serviceName pointe vers une ressource MulticlusterService.

   • Inspectez la ressource MulticlusterService :

     kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice -o yaml
     

     Le résultat contient les éléments suivants :

     spec:
       clusters:
       - link: us-west1-b/blue
       - link: us-west1-c/green
       template:
         spec:
           ports:
           - name: web
             port: 8080
             protocol: TCP
             targetPort: 8080
           selector:
             app: whereami
     

     La ressource MulticlusterService est semblable à une ressource de Service Kubernetes, à la différence qu'elle comporte une spécification clusters. La valeur clusters correspond à la liste des clusters enregistrés où la ressource MulticlusterService est créée.

   • Vérifiez que la ressource MulticlusterIngress a créé un équilibreur de charge avec un service de backend pointant vers la ressource MulticlusterService :

     watch kubectl --context ${INGRESS_CONFIG_CLUSTER} \
           get multiclusteringress -o jsonpath="{.items[].status.VIP}"
     

     Cette opération peut prendre jusqu'à 10 minutes. Attendez jusqu'à obtenir un résultat semblable à ce qui suit :

     34.107.246.9
     

     Pour quitter la commande watch, appuyez sur Control+C.

4. Dans Cloud Shell, obtenez l'adresse IP virtuelle de Cloud Load Balancing :

   export GCLB_VIP=$(kubectl --context ${INGRESS_CONFIG_CLUSTER} \
          get multiclusteringress -o json | jq -r '.items[].status.VIP') \
          && echo ${GCLB_VIP}
   

   Le résultat ressemble à ce qui suit :

   34.107.246.9
   

5. Utilisez curl pour accéder à l'équilibreur de charge et à l'application déployée :

   curl ${GCLB_VIP}
   

   Le résultat ressemble à ce qui suit :

   {
     "cluster_name": "green",
     "host_header": "34.107.246.9",
     "pod_name": "whereami-deployment-756c7dc74c-sndz7",
     "pod_name_emoji": "😇",
     "project_id": "gke-multicluster-upgrades",
     "timestamp": "2022-07-08T14:26:07",
     "zone": "us-west1-c"
   }
   

6. Exécutez la commande curl à plusieurs reprises. Notez que la charge des requêtes est équilibrée entre l'application whereami déployée sur deux clusters, blue et green.

Configurer le générateur de charge

Dans cette section, vous allez configurer un Service loadgenerator qui génère du trafic client vers l'adresse IP virtuelle de Cloud Load Balancing. Tout d'abord, le trafic est envoyé vers les clusters blue et green, car la ressource MulticlusterService est configurée pour envoyer du trafic vers les deux clusters. Par la suite, vous allez configurer la ressource MulticlusterService pour envoyer du trafic vers un seul cluster.

1. Configurez le fichier manifeste loadgenerator pour envoyer le trafic client vers Cloud Load Balancing :

   TEMPLATE=loadgen-manifests/loadgenerator.yaml.templ && envsubst < ${TEMPLATE} > ${TEMPLATE%.*}
   

2. Déployez loadgenerator dans le cluster ingress-config :

   kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/loadgen-manifests
   

3. Vérifiez que les pods loadgenerator du cluster ingress-config présentent tous l'état Running :

   kubectl --context ${INGRESS_CONFIG_CLUSTER} get pods
   

   Le résultat ressemble à ce qui suit :

   NAME                             READY   STATUS    RESTARTS   AGE
   loadgenerator-5498cbcb86-hqscp   1/1     Running   0          53s
   loadgenerator-5498cbcb86-m2z2z   1/1     Running   0          53s
   loadgenerator-5498cbcb86-p56qb   1/1     Running   0          53s
   

   Si l'un des Pods n'est pas à l'état Running, attendez quelques minutes, puis exécutez à nouveau la commande.

Surveiller le trafic

Dans cette section, vous allez surveiller le trafic vers l'application whereami à l'aide de la console Google Cloud.

Dans la section précédente, vous avez configuré un déploiement loadgenerator qui simule le trafic client en accédant à l'application whereami via l'adresse IP virtuelle de Cloud Load Balancing. Vous pouvez surveiller ces métriques via la console Google Cloud. Configurez d'abord la surveillance afin de pouvoir surveiller lorsque vous drainez des clusters pour les mises à niveau (comme décrit dans la section suivante).

1. Créez un tableau de bord pour afficher le trafic atteignant Multi Cluster Ingress :

   export DASH_ID=$(gcloud monitoring dashboards create \
       --config-from-file=dashboards/cloud-ops-dashboard.json \
       --format=json | jq  -r ".name" | awk -F '/' '{print $4}')
   

   Le résultat ressemble à ce qui suit :

   Created [721b6c83-8f9b-409b-a009-9fdf3afb82f8]
   

2. Les métriques de Cloud Load Balancing sont disponibles dans la console Google Cloud. Générez l'URL :

   echo "https://console.cloud.google.com/monitoring/dashboards/builder/${DASH_ID}/?project=${PROJECT}&timeDomain=1h"
   

   Le résultat ressemble à ce qui suit :

   https://console.cloud.google.com/monitoring/dashboards/builder/721b6c83-8f9b-409b-a009-9fdf3afb82f8/?project=gke-multicluster-upgrades&timeDomain=1h"
   

3. Dans un navigateur, accédez à l'URL générée par la commande précédente.

   Le trafic vers l'exemple d'application passe du générateur de charge aux clusters blue et green (notés par les deux zones dans lesquelles se trouvent les clusters). Le graphique des métriques chronologiques montre le trafic allant aux deux backends. Les valeurs de survol avec la souris k8s1- indiquent que le groupe de points de terminaison du réseau (NEG) pour les deux ressources MulticlusterServices de l'interface s'exécute dans les clusters blue et green.

   Remarque : Les couleurs du graphique peuvent ne pas correspondre aux clusters blue et green. Il peut s'écouler plusieurs minutes avant que le trafic ne soit visible dans le graphique.

   

Drainer et mettre à niveau le cluster blue

Dans cette section, vous drainez le cluster blue. Le drainage d'un cluster signifie que vous le supprimez du pool d'équilibrage de charge. Après avoir drainé le cluster blue, tout le trafic client destiné à l'application est dirigé vers le cluster green. Vous pouvez surveiller ce processus comme décrit dans la section précédente. Une fois le cluster drainé, vous pouvez mettre à jour le cluster drainé. Après la mise à niveau, vous pouvez le réinstaller dans le pool d'équilibrage de charge. Répétez ces étapes pour mettre à niveau l'autre cluster (non illustré dans ce tutoriel).

Pour drainer le cluster blue, mettez à jour la ressource MulticlusterService dans le cluster ingress-cluster et supprimez le cluster blue de la spécification clusters.

Drainer le cluster blue

1. Dans Cloud Shell, mettez à jour la ressource MulticlusterService dans le cluster ingress-config :

   kubectl --context ${INGRESS_CONFIG_CLUSTER} \
             apply -f ${WORKDIR}/multicluster-manifests/mcs-green.yaml
   

2. Vérifiez que vous ne disposez que du cluster green dans la spécification clusters :

   kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice \
           -o json | jq '.items[].spec.clusters'
   

   Le résultat est le suivant :

   [
     {
       "link": "us-west1-c/green"
     }
   ]
   

   Seul le cluster green est répertorié dans la spécification clusters, de sorte que seul le cluster green se trouve dans le pool d'équilibrage de charge.

3. Vous pouvez consulter les métriques à partir des métriques Cloud Load Balancing dans la console Google Cloud. Générez l'URL :

   echo "https://console.cloud.google.com/monitoring/dashboards/builder/${DASH_ID}/?project=${PROJECT}&timeDomain=1h"
   

4. Dans un navigateur, accédez à l'URL générée à partir de la commande précédente.

   Le graphique montre que seul le cluster green reçoit du trafic.

   

Mettre à niveau le cluster blue :

Maintenant que le cluster blue ne reçoit plus de trafic client, vous pouvez le mettre à niveau (plan de contrôle et nœuds).

1. Dans Cloud Shell, obtenez la version actuelle des clusters :

   gcloud container clusters list
   

   Le résultat ressemble à ce qui suit :

   NAME: ingress-config
   LOCATION: us-west1-a
   MASTER_VERSION: 1.22.8-gke.202
   MASTER_IP: 35.233.186.135
   MACHINE_TYPE: e2-medium
   NODE_VERSION: 1.22.8-gke.202
   NUM_NODES: 4
   STATUS: RUNNING
   
   NAME: blue
   LOCATION: us-west1-b
   MASTER_VERSION: 1.22.8-gke.202
   MASTER_IP: 34.82.35.222
   MACHINE_TYPE: e2-medium
   NODE_VERSION: 1.22.8-gke.202
   NUM_NODES: 3
   STATUS: RUNNING
   
   NAME: green
   LOCATION: us-west1-c
   MASTER_VERSION: 1.22.8-gke.202
   MASTER_IP: 35.185.204.26
   MACHINE_TYPE: e2-medium
   NODE_VERSION: 1.22.8-gke.202
   NUM_NODES: 3
   STATUS: RUNNING
   

   Vos versions de cluster peuvent varier selon la date à laquelle vous suivez ce tutoriel.

2. Obtenez la liste des versions MasterVersions disponibles dans la zone :

   gcloud container get-server-config --zone us-west1-b --format=json | jq \
   '.validMasterVersions[0:20]'
   

   Le résultat ressemble à ce qui suit :

   [
     "1.24.1-gke.1400",
     "1.23.7-gke.1400",
     "1.23.6-gke.2200",
     "1.23.6-gke.1700",
     "1.23.6-gke.1501",
     "1.23.6-gke.1500",
     "1.23.5-gke.2400",
     "1.23.5-gke.1503",
     "1.23.5-gke.1501",
     "1.22.10-gke.600",
     "1.22.9-gke.2000",
     "1.22.9-gke.1500",
     "1.22.9-gke.1300",
     "1.22.8-gke.2200",
     "1.22.8-gke.202",
     "1.22.8-gke.201",
     "1.22.8-gke.200",
     "1.21.13-gke.900",
     "1.21.12-gke.2200",
     "1.21.12-gke.1700"
   ]
   

3. Obtenez une liste des versions NodeVersions disponibles dans la zone :

   gcloud container get-server-config --zone us-west1-b --format=json | jq \
   '.validNodeVersions[0:20]'
   

   Le résultat ressemble à ce qui suit :

   [
     "1.24.1-gke.1400",
     "1.23.7-gke.1400",
     "1.23.6-gke.2200",
     "1.23.6-gke.1700",
     "1.23.6-gke.1501",
     "1.23.6-gke.1500",
     "1.23.5-gke.2400",
     "1.23.5-gke.1503",
     "1.23.5-gke.1501",
     "1.22.10-gke.600",
     "1.22.9-gke.2000",
     "1.22.9-gke.1500",
     "1.22.9-gke.1300",
     "1.22.8-gke.2200",
     "1.22.8-gke.202",
     "1.22.8-gke.201",
     "1.22.8-gke.200",
     "1.22.7-gke.1500",
     "1.22.7-gke.1300",
     "1.22.7-gke.900"
   ]
   

4. Définissez une variable d'environnement pour une version MasterVersion et une version NodeVersion, parmi celles figurant dans les listes MasterVersions et NodeVersions, qui soit supérieure à la version actuelle du cluster blue, par exemple :

   export UPGRADE_VERSION="1.22.10-gke.600"
   

   Ce tutoriel utilise la version 1.22.10-gke.600. Vos versions de cluster peuvent varier en fonction des versions disponibles au moment où vous suivez ce tutoriel. Pour en savoir plus sur la mise à niveau, consultez la section Mettre à niveau des clusters et des pools de nœuds.

   Remarque : Nous vous recommandons de ne pas ignorer les versions mineures du cluster afin d'éviter les éventuels problèmes d'incompatibilité du plan de contrôle ou des nœuds. Pour en savoir plus, consultez la section Puis-je ignorer plusieurs versions de GKE lors de la mise à niveau d'un cluster ?.

5. Mettez à jour le nœud control plane du cluster blue :

   gcloud container clusters upgrade blue \
       --zone us-west1-b --master --cluster-version ${UPGRADE_VERSION}
   

   Pour confirmer la mise à niveau, appuyez sur Y.

   Cela prend quelques minutes. Attendez la fin de la mise à niveau avant de continuer.

   Une fois la mise à jour terminée, le résultat est le suivant :

   Updated
   [https://container.googleapis.com/v1/projects/gke-multicluster-upgrades/zones/us-west1-b/clusters/blue].
   

6. Mettez à niveau les nœuds du cluster blue :

   gcloud container clusters upgrade blue \
       --zone=us-west1-b --node-pool=default-pool \
       --cluster-version ${UPGRADE_VERSION}
   

   Pour confirmer la mise à jour, appuyez sur Y.

   Cela prend quelques minutes. Attendez la fin de la mise à niveau des nœuds avant de continuer.

   Une fois la mise à niveau terminée, le résultat est le suivant :

   Upgrading blue... Done with 3 out of 3 nodes (100.0%): 3 succeeded...done.
   Updated [https://container.googleapis.com/v1/projects/gke-multicluster-upgrades/zones/us-west1-b/clusters/blue].
   

7. Vérifiez que le cluster blue est mis à niveau :

   gcloud container clusters list
   

   Le résultat ressemble à ce qui suit :

   NAME: ingress-config
   LOCATION: us-west1-a
   MASTER_VERSION: 1.22.8-gke.202
   MASTER_IP: 35.233.186.135
   MACHINE_TYPE: e2-medium
   NODE_VERSION: 1.22.8-gke.202
   NUM_NODES: 4
   STATUS: RUNNING
   
   NAME: blue
   LOCATION: us-west1-b
   MASTER_VERSION: 1.22.10-gke.600
   MASTER_IP: 34.82.35.222
   MACHINE_TYPE: e2-medium
   NODE_VERSION: 1.22.10-gke.600
   NUM_NODES: 3
   STATUS: RUNNING
   
   NAME: green
   LOCATION: us-west1-c
   MASTER_VERSION: 1.22.8-gke.202
   MASTER_IP: 35.185.204.26
   MACHINE_TYPE: e2-medium
   NODE_VERSION: 1.22.8-gke.202
   NUM_NODES: 3
   STATUS: RUNNING
   

Replacer le cluster blue dans le pool d'équilibrage de charge

Dans cette section, vous ajoutez le cluster blue au pool d'équilibrage de charge.

1. Dans Cloud Shell, vérifiez que le déploiement de l'application s'exécute sur le cluster blue avant de le replacer dans le pool d'équilibrage de charge :

   kubectl --context ${BLUE_CLUSTER} get pods
   

   Le résultat ressemble à ce qui suit :

   NAME                                   READY   STATUS    RESTARTS   AGE
   whereami-deployment-756c7dc74c-xdnb6   1/1     Running   0          17m
   

2. Mettez à jour la ressource MutliclusterService pour ajouter de nouveau le cluster blue au pool d'équilibrage de charge :

   kubectl --context ${INGRESS_CONFIG_CLUSTER} apply \
           -f ${WORKDIR}/multicluster-manifests/mcs-blue-green.yaml
   

3. Vérifiez que la spécification des clusters contient à la fois les clusters blue et green :

   kubectl --context ${INGRESS_CONFIG_CLUSTER} get multiclusterservice \
           -o json | jq '.items[].spec.clusters'
   

   Le résultat est le suivant :

   [
     {
       "link": "us-west1-b/blue"
     },
     {
       "link": "us-west1-c/green"
     }
   ]
   

   Les clusters blue et green figurent maintenant dans la spécification clusters.

4. Les métriques issues de Cloud Load Balancing sont disponibles dans la console Google Cloud. Générez l'URL :

   echo "https://console.cloud.google.com/monitoring/dashboards/builder/${DASH_ID}/?project=${PROJECT}&timeDomain=1h"
   

5. Dans un navigateur, accédez à l'URL générée par la commande précédente.

   Le graphique montre que les clusters blue et green reçoivent le trafic du générateur de charge utilisant l'équilibreur de charge.

   Remarque : Le rééquilibrage du trafic peut prendre plusieurs minutes.

   

   Félicitations. Vous avez mis à niveau un cluster GKE dans une architecture multicluster à l'aide d'un objet Ingress multicluster.

6. Pour mettre à jour le cluster green, répétez la procédure appliquée pour drainer et mettre à jour le cluster blue, en remplaçant blue par green.

Effectuer un nettoyage

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet mais supprimez les ressources individuelles.

Le moyen le plus simple d'éviter la facturation consiste à supprimer le projet Google Cloud que vous avez créé pour le tutoriel. Vous pouvez également supprimer les différentes ressources.

Supprimer les clusters

1. Dans Cloud Shell, annulez l'enregistrement et supprimez les clusters blue et green :

   gcloud container fleet memberships unregister blue --gke-cluster=us-west1-b/blue
   gcloud container clusters delete blue --zone us-west1-b --quiet
   
   gcloud container fleet memberships unregister green --gke-cluster=us-west1-c/green
   gcloud container clusters delete green --zone us-west1-c --quiet
   

2. Supprimez la ressource MuticlusterIngress du cluster ingress-config :

   kubectl --context ${INGRESS_CONFIG_CLUSTER} delete -f ${WORKDIR}/multicluster-manifests/mci.yaml
   

   Cette commande supprime les ressources Cloud Load Balancing du projet.

3. Annuler l'enregistrement et supprimer le cluster ingress-config :

   gcloud container fleet memberships unregister ingress-config --gke-cluster=us-west1-a/ingress-config
   gcloud container clusters delete ingress-config --zone us-west1-a --quiet
   

4. Vérifiez que tous les clusters sont supprimés :

   gcloud container clusters list
   

   Le résultat est le suivant :

   *<null>*
   

5. Réinitialisez le fichier kubeconfig :

   unset KUBECONFIG
   

6. Supprimez le dossier WORKDIR :

   cd ${HOME}
   rm -rf ${WORKDIR}
   

Supprimer le projet

Attention : La suppression d'un projet entraîne les effets décrits ci-dessous :
• Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches décrites dans ce document et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
• Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.
1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Étape suivante

• En savoir plus sur l'objet Ingress multicluster.
• Découvrez comment déployer un objet Ingress multicluster sur plusieurs clusters.
• Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Cloud Architecture Center.