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 :
Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.
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.
-
Make sure that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, 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
etus-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 fichierkubeconfig
: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 fichierkubeconfig
, 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 exploitant Workload Identity, 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
etMulticlusterService
au clusteringress-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 clustersblue
etgreen
: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
etgreen
ont l'étatRunning
: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 clusteringress-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
MulticlusterService
sur le clusteringress-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écificationserviceName
pointe vers une ressourceMulticlusterService
.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écificationclusters
. La valeurclusters
correspond à la liste des clusters enregistrés où la ressourceMulticlusterService
est créée.Vérifiez que la ressource
MulticlusterIngress
a créé un équilibreur de charge avec un service de backend pointant vers la ressourceMulticlusterService
: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 surControl+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'applicationwhereami
déployée sur deux clusters,blue
etgreen
.
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 clusteringress-config
:kubectl --context ${INGRESS_CONFIG_CLUSTER} apply -f ${WORKDIR}/loadgen-manifests
Vérifiez que les pods
loadgenerator
du clusteringress-config
présentent tous l'étatRunning
: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
etgreen
(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 sourisk8s1-
indiquent que le groupe de points de terminaison du réseau (NEG) pour les deux ressourcesMulticlusterServices
de l'interface s'exécute dans les clustersblue
etgreen
.
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 clusteringress-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écificationclusters
: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écificationclusters
, de sorte que seul le clustergreen
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 versionNodeVersion
, parmi celles figurant dans les listesMasterVersions
etNodeVersions
, qui soit supérieure à la version actuelle du clusterblue
, 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.Mettez à jour le nœud
control plane
du clusterblue
: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 clusterblue
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
etgreen
: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
etgreen
figurent maintenant dans la spécificationclusters
.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.
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çantblue
pargreen
.
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
etgreen
: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 clusteringress-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 :
*<null>*
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.
- 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 Centre d'architecture cloud.