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

Architecture de deux clusters identiques et d'un cluster de plan de contrôle.

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 :

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

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.
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
Make sure that billing is enabled for your Google Cloud project.
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

Définissez le projet par défaut :

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

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

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

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

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.

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

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.

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

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.

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

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

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.

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'

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

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

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

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.

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

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

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.

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

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

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.

Configurez le fichier manifeste loadgenerator pour envoyer le trafic client vers Cloud Load Balancing :
```
TEMPLATE=loadgen-manifests/loadgenerator.yaml.templ && envsubst < ${TEMPLATE} > ${TEMPLATE%.*}
```

Déployez loadgenerator dans le cluster ingress-config :

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

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

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]

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"

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

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

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.
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"
```
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).

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.

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"
]

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"
]

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 ?.
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].
```

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

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.

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

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

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.

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"

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

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

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.

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

Vérifiez que tous les clusters sont supprimés :
```
gcloud container clusters list
```
Le résultat est le suivant :
```
*&lt;null&gt;*
```
Réinitialisez le fichier kubeconfig :
```
unset KUBECONFIG
```
Supprimez le dossier WORKDIR :
```
cd ${HOME}
rm -rf ${WORKDIR}
```

Supprimer le projet

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
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.

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

Architecture

Objectifs

Coûts

Avant de commencer

Configurer l'environnement

Créer et enregistrer des clusters GKE dans Hub

Créer des clusters GKE

Enregistrer des clusters GKE dans un parc

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

Configurer un objet Ingress multicluster

Configurer le générateur de charge

Surveiller le trafic

Drainer et mettre à niveau le cluster blue

Drainer le cluster blue

Mettre à niveau le cluster blue :

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

Effectuer un nettoyage

Supprimer les clusters

Supprimer le projet

Étape suivante

Drainer et mettre à niveau le cluster `blue`

Mettre à niveau le cluster `blue` :

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