Cette page a été traduite par l'API Cloud Translation.

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

Last reviewed 2022-12-15 UTC

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

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

Créer des clusters GKE

Dans Cloud Shell, créez trois clusters GKE :

gcloud container clusters create ingress-config --location 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 --location 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 --location 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 \
    --location us-west1-a --project ${PROJECT}
gcloud container clusters get-credentials blue --location us-west1-b \
    --project ${PROJECT}
gcloud container clusters get-credentials green --location 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 consoleGoogle 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 dans la consoleGoogle 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 consoleGoogle 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 consoleGoogle 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 --location 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 --location 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 \
    --location 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 \
    --location=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 consoleGoogle 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.

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

Architecture

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

Drainer et mettre à niveau le cluster `blue`

Mettre à niveau le cluster `blue` :

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