La mise en réseau multicluster est un outil précieux qui permet de mettre en œuvre des cas d'utilisation tels que la haute disponibilité régionale, la proximité mondiale des utilisateurs pour une latence réduite et l'isolation organisationnelle entre les équipes. Google Kubernetes Engine (GKE) fournit des fonctionnalités intégrées pour la mise en réseau multicluster que vous pouvez activer et utiliser à grande échelle sur un parc de clusters GKE. Cette fonctionnalité permet également de combiner ou de migrer une infrastructure déployée entre GKE Standard et Autopilot pour répondre aux besoins d'architecture de chaque application.
Ce document décrit ces fonctionnalités via plusieurs topologies de déploiement. Vous allez apprendre à prendre une application déployée dans un seul cluster GKE et à la migrer vers un déploiement multicluster sur des clusters GKE Standard et Autopilot. Utilisez les services multiclusters de GKE pour le trafic est-ouest et les passerelles multiclusters pour activer le multicluster réseau nord-sud.
Ce document est destiné aux architectes cloud et aux équipes chargées des opérations qui utilisent ou prévoient d'utiliser GKE pour déployer des services sur plusieurs clusters Kubernetes. Dans ce document, nous partons du principe que vous connaissez Kubernetes.
GKE Standard et GKE Autopilot
GKE fournit un déploiement Kubernetes géré avec un ensemble complet de fonctionnalités, y compris un plan de contrôle à haute disponibilité. Les clusters GKE peuvent être démarrés rapidement et évoluer jusqu'à 15 000 nœuds. Avec les clusters GKE Autopilot, Google gère l'infrastructure, y compris le plan de contrôle et les nœuds. Si vous préférez configurer et gérer vos nœuds vous-même, GKE fournit le mode Standard.
Pour en savoir plus sur les différences entre les modes, consultez la section Choisir un mode de fonctionnement du cluster.
Services multiclusters et passerelles multiclusters
Kubernetes peut s'exécuter à l'aide d'un seul plan de contrôle sur des zones cloud disparates pour assurer la résilience et la haute disponibilité de vos services.
GKE va plus loin et fournit des services multiclusters (MCS) GKE qui fournissent un mécanisme de détection et d'appel de services interclusters.
Les services qui utilisent cette fonctionnalité sont visibles et accessibles sur les clusters avec une adresse IP virtuelle, ce qui correspond au comportement d'un service ClusterIP accessible dans un cluster. Cette approche présente les avantages suivants :
- Les services peuvent être équilibrés en charge sur plusieurs clusters de la même région ou de régions différentes (trafic est-ouest).
- Les options de haute disponibilité des services interrégionaux sont réalisables.
- Les charges de travail avec état et sans état peuvent être déployées et gérées sur des clusters distincts.
- Les services partagés sont disponibles dans tous les clusters.
Pour en savoir plus sur le déploiement de MCS, consultez la page Configurer des services multiclusters.
GKE fournit une mise en œuvre de l'API Kubernetes Gateway qui utilise le contrôleur GKE Gateway. Gateway permet à GKE de déployer des équilibreurs de charge Google Cloud pour fournir un routage du trafic entrant (nord-sud) pour les services déployés sur GKE. GKE fournit également des passerelles multiclusters (MCG, Multi-Cluster Gateway) qui étendent le contrôleur GKE Gateway pour provisionner les équilibreurs de charge qui acheminent le trafic vers les services déployés sur des clusters GKE disparates.
Le schéma suivant montre comment, lorsque vous combinez MCS et MCG, vous pouvez gérer les aspects complémentaires du déploiement de service et du routage du trafic à partir d'un seul plan de contrôle :
Pour en savoir plus, consultez la section Déployer des passerelles multiclusters.
Présentation de la migration
Les fonctionnalités de mise en réseau multicluster GKE tirent parti des charges de travail de divers profils. Par exemple, vous pourriez avoir des composants sans état avec un trafic intensif que vous souhaitez faire passer à Autopilot en raison de son modèle de coût plus efficace.
Vous pouvez également placer les interfaces de vos applications plus près des utilisateurs. Cette approche permet de réduire la latence et la mise en cache, ce qui améliore les performances des applications et l'expérience utilisateur. Dans le même temps, vous pouvez avoir des composants avec état sur lesquels votre application repose, qui ne peuvent résider que dans un seul emplacement. Cette configuration nécessite l'équilibrage de charge multicluster nord-sud pour envoyer le trafic client au cluster approprié à cet emplacement. Vous avez également besoin d'un équilibrage de charge multicluster est-ouest pour envoyer du trafic entre clusters afin d'atteindre les composants avec état.
Ce document utilise l'application de démonstration de microservices cloud Online Boutique pour illustrer un modèle multicluster permettant d'améliorer le déploiement de la démonstration de zone unique. Vous commencez avec une version à zone unique de l'application. Vous ajoutez ensuite des éléments de haute disponibilité et de résilience en utilisant des services multiclusters et des passerelles multiclusters, et réduisez les tâches opérationnelles en tirant parti d'Autopilot.
Déploiement initial sur un cluster unique
Dans le schéma suivant, l'application Online Boutique est initialement déployée sur un seul cluster en mode GKE Standard nommé std-west, et est exposé à l'aide d'un service LoadBalancer :
Migrer vers des services multiclusters
À l'étape intermédiaire suivante, vous allez créer deux clusters supplémentaires. Les services sans état seront déployés dans d'autres régions. Vous allez créer deux clusters GKE Autopilot nommés auto-east et auto-central dans deux régions distinctes et différentes de l'unique Cluster GKE Standard std-ouest, et enregistrer les clusters dans le parc Google Cloud.
Un parc est un concept Google Cloud qui permet d'organiser logiquement des clusters et d'autres ressources. Il vous permet d'utiliser et de gérer des fonctionnalités multicluster, ainsi que d'appliquer des règles cohérentes à vos systèmes.
Vous allez exporter le cartservice sur le cluster std-west dans l'espace de noms onlineboutique vers les nouveaux clusters de parc à l'aide de ServiceExport.
Vous allez déployer le service de frontend d'Online Boutique sur les trois clusters et l'exposez via un service ClusterIP. Ensuite, vous allez l'exporter vers le parc à l'aide de ServiceExports.
Des services, tels que la couche de middleware d'Online Boutique (par exemple productcatalog, shipping et adservice), sont également déployés sur les trois clusters.
Un Pod qui s'exécute dans n'importe quel cluster du parc peut accéder à un Service exporté en envoyant une requête à l'URI ClusterSet pour ce service. La requête est acheminée vers un point de terminaison qui sauvegarde le service.
Le service de frontend peut utiliser localement les services de middleware (tels que productcatalogservice ou currencyservice) dans le même cluster. Cette architecture permet de conserver les requêtes entrantes localement dans les régions dont l'interface répond à la requête et d'éviter des frais de trafic réseau interrégionaux inutiles.
Le schéma suivant illustre les deux services multiclusters. Le service de frontend sans état est déployé sur trois clusters et le service de backend cartservice avec état est déployé sur un cluster. Le schéma montre également qu'à cette étape intermédiaire, le trafic entrant pour le service de frontend reste acheminé vers le cluster GKE Standard d'origine dans us-west1 à l'aide d'un équilibreur de charge réseau externe à stratégie directe créé par le service LoadBalancer de l'interface externe :
Migrer vers une passerelle multicluster
À la dernière étape, vous allez acheminer le trafic entrant du service de frontend depuis les requêtes des clients externes vers des services de plusieurs clusters du parc à l'aide d'une passerelle multicluster.
Un quatrième cluster nomméconfig-central est ajouté au parc pour héberger et gérer la configuration des ressources Gateway et HTTPRoute qui sont créées dans le cadre de cette configuration. La ressource HTTPRoute mappe le préfixe / au ServiceImport de frontend.
Le trafic destiné à l'interface d'Online Boutique est envoyé à un point de terminaison opérationnel dans l'une des régions disponibles. Cette approche ajoute des éléments à haute disponibilité à l'architecture de l'application Online Boutique.
Dans le diagramme suivant, la passerelle multicluster déploie un équilibreur de charge cloud global qui achemine le trafic externe vers le service de frontend sans état déployé sur chacun des trois clusters d'application du parc.
Dans l'état final, ce modèle affirmé illustre le couplage faible entre les parties avec état (cartservice et redis-cart) et sans état de l'application (frontend, emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice, and adservice). Bien que cette approche n'entre pas dans le cadre de ce document, elle vous offre l'occasion d'accroître la résilience et la haute disponibilité de la couche de services avec état.
Objectifs
- Créer et configurer des clusters GKE Standard et Autopilot.
- Déployer Online Boutique sur un cluster zonal GKE Standard.
- Exporter des
Servicesmulticlusters. - Déployer des fichiers manifestes sur des clusters Standard et Autopilot.
- Activer et configurer des passerelles multiclusters.
- Tester le comportement de l'application multirégionale.
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.
Avant de commencer
Les contraintes de sécurité définies par votre organisation peuvent vous empêcher d'effectuer les étapes suivantes. Pour obtenir des informations de dépannage, consultez la page Développer des applications dans un environnement Google Cloud limité.
Avant de commencer, vérifiez que les conditions suivantes sont remplies :
- Il est recommandé d'utiliser un nouveau projet pour ce guide, car le moyen le plus simple d'effectuer un nettoyage consiste à supprimer le projet une fois l'opération terminée.
- Ce guide suppose que vous disposez du rôle Propriétaire IAM pour votre projet Google Cloud. Pour les paramètres de production ou réels, il est recommandé de limiter les autorisations au moindre privilège. Pour en savoir plus, consultez les sections Utiliser IAM en toute sécurité et Gérer l'identité et l'accès.
- Familiarisez-vous avec l'architecture de l'application de démonstration des microservices Online Boutique.
Préparer l'environnement
Dans ce guide, vous utilisez Cloud Shell pour saisir des commandes. Cloud Shell vous permet d'accéder à la ligne de commande dans Google Cloud Console et comprend Google Cloud SDK ainsi que d'autres outils, tels que Google Cloud CLI. Cloud Shell apparaît sous la forme d'une fenêtre en bas de Google Cloud Console. L'initialisation peut prendre quelques minutes, mais la fenêtre apparaît immédiatement.
Dans la console Google Cloud, activez Cloud Shell.
Dans Cloud Shell, définissez les variables d'environnement utilisées dans ce guide. Remplacez PROJECT_ID par votre ID de projet :
export PROJECT=PROJECT_ID gcloud config set project ${PROJECT}Activez les services requis pour ce document :
gcloud services enable \ gkehub.googleapis.com \ multiclusteringress.googleapis.com \ dns.googleapis.com \ trafficdirector.googleapis.com \ cloudresourcemanager.googleapis.com \ multiclusterservicediscovery.googleapis.com \ container.googleapis.com gcloud container fleet multi-cluster-services enableLes services multiclusters gèrent les composants Google Cloud tels que Cloud DNS, les règles de pare-feu et Traffic Director. Ces API doivent donc également être activées. Pour en savoir plus, consultez la présentation de Traffic Director.
Le résultat ressemble à celui de l'exemple ci-dessous.
Operation "operations/acf.p2-822685001869-ee4ebe78-6dd8-465e-b0fd-3b0e5f964bad" finished successfully. Waiting for Feature Multi-cluster Services to be created...done.Vérifiez que les services multiclusters affichent l'état ACTIVE :
gcloud container fleet multi-cluster-services describeLe résultat ressemble à celui de l'exemple ci-dessous.
createTime: '2021-11-30T21:59:25.245190894Z' name: projects/PROJECT_ID/locations/global/features/multiclusterservicediscovery resourceState: state: ACTIVE spec: {} updateTime: '2021-11-30T21:59:27.459063070Z'Si la valeur de state n'est pas ACTIVE, consultez la section de dépannage de la documentation MCS.
Créer et configurer des clusters GKE
Pour illustrer le modèle multicluster de ce guide, vous utiliserez trois clusters d'application dans trois régions cloud distinctes et un cluster pour héberger la configuration pour les ressources Gateway. Vous enregistrez tous les clusters avec le parc associé à votre projet. Un projet Google Cloud ne peut être associé qu'à un seul parc. Ce projet est appelé projet hôte du parc.
Créez des clusters GKE Standard et Autopilot :
gcloud container clusters create std-west \ --zone us-west1-a \ --num-nodes=6 \ --enable-ip-alias \ --release-channel regular \ --workload-pool=${PROJECT}.svc.id.goog \ --async gcloud container clusters create-auto auto-east \ --region us-east1 \ --release-channel regular \ --async gcloud container clusters create-auto auto-central \ --region us-central1 \ --release-channel regular \ --async gcloud container clusters create config-central \ --region us-central1 \ --num-nodes=1 \ --enable-ip-alias \ --release-channel regular \ --workload-pool=${PROJECT}.svc.id.goog \ --asyncLa fédération d'identité de charge de travail pour GKE est activée par défaut sur les clusters GKE Autopilot. Vous n'avez donc pas besoin d'utiliser l'option
--workload-poollorsque vous créez ces clusters comme vous le faites avec les clusters GKE Standard.Attendez que l'état (STATUS) des clusters passe de PROVISIONING à RUNNING. Notez que cette opération peut prendre jusqu'à 10 minutes. Vous pouvez suivre la progression en utilisant une boucle de contrôle pendant que vous prenez une tasse de café ou que vous faites quelques étirements avant de poursuivre :
watch -n 20 --difference=permanent "gcloud container clusters list"Le résultat ressemble à celui de l'exemple ci-dessous.
NAME: auto-central LOCATION: us-central1 MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: 107.178.213.138 MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 3 STATUS: PROVISIONING NAME: config-central LOCATION: us-central1 MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 9 STATUS: PROVISIONING NAME: auto-east LOCATION: us-east1 MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: 35.229.88.209 MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 3 STATUS: PROVISIONING NAME: std-west LOCATION: us-west1-a MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: 35.197.93.113 MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 6 STATUS: PROVISIONINGUne fois que tous les clusters sont à l'état RUNNING (en cours d'exécution), appuyez sur
CTRL-Cpour interrompre la commande.Ajoutez une liaison de stratégie IAM (Identity and Access Management) qui accorde au compte de service MCS du projet hôte du parc le rôle Utilisateur du réseau sur son propre projet :
gcloud projects add-iam-policy-binding ${PROJECT} \ --member "serviceAccount:${PROJECT}.svc.id.goog[gke-mcs/gke-mcs-importer]" \ --role "roles/compute.networkViewer"Vous utilisez la fédération d'identité de charge de travail pour GKE afin d'accorder au service MCS un accès en lecture à la configuration du réseau VPC de votre projet. Par conséquent, le compte de service de l'importateur GKE MCS du projet du hôte de parc a besoin de ce rôle.
Le résultat ressemble à celui de l'exemple ci-dessous.
- members: - serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer] role: roles/compute.networkViewer [...]Enregistrez les clusters GKE Standard et Autopilot pour le parc de votre projet. Pour en savoir plus, consultez la section Enregistrer un cluster. Cette étape peut prendre jusqu'à cinq minutes :
gcloud container fleet memberships register std-west \ --gke-cluster us-west1-a/std-west \ --enable-workload-identity \ --project=${PROJECT} gcloud container fleet memberships register auto-east \ --gke-cluster us-east1/auto-east \ --enable-workload-identity \ --project=${PROJECT} gcloud container fleet memberships register auto-central \ --gke-cluster us-central1/auto-central \ --enable-workload-identity \ --project=${PROJECT} gcloud container fleet memberships register config-central \ --gke-cluster us-central1/config-central \ --enable-workload-identity \ --project=${PROJECT}Pour chaque commande, la sortie ressemble à ce qui suit :
Waiting for membership to be created...done. Created a new membership [projects/PROJECT_ID/locations/global/memberships/std-west] for the cluster [std-west] Generating the Connect Agent manifest... Deploying the Connect Agent on cluster [std-west] in namespace [gke-connect]... Deployed the Connect Agent on cluster [std-west] in namespace [gke-connect]. Finished registering the cluster [std-west] with the Hub.Connectez-vous aux clusters et générez des entrées kubeconfig :
gcloud container clusters get-credentials std-west \ --zone us-west1-a --project $PROJECT gcloud container clusters get-credentials auto-east \ --region us-east1 --project $PROJECT gcloud container clusters get-credentials auto-central \ --region us-central1 --project $PROJECT gcloud container clusters get-credentials config-central \ --region us-central1 --project $PROJECTPour chaque commande, la sortie ressemble à ce qui suit :
Fetching cluster endpoint and auth data. kubeconfig entry generated for std-west.Renommez les contextes des clusters afin de les rendre plus faciles à utiliser dans la suite de ce document :
kubectl config rename-context \ gke_${PROJECT}_us-west1-a_std-west \ std-west kubectl config rename-context \ gke_${PROJECT}_us-east1_auto-east \ auto-east kubectl config rename-context \ gke_${PROJECT}_us-central1_auto-central \ auto-central kubectl config rename-context \ gke_${PROJECT}_us-central1_config-central \ config-centralDans ce guide, les contextes sont nommés en fonction de leur emplacement. Bien que vous puissiez fournir d'autres noms, les étapes restantes de ce guide utilisent les noms utilisés dans cette étape.
Déployer Online Boutique sur GKE Standard
Dans la première étape du déploiement de démonstration, vous déployez l'ensemble complet des services d'application Online Boutique sur le cluster GKE Standard unique std-west dans us-west1.
Créez l'espace de noms onlineboutique sur std-west :
kubectl create namespace onlineboutique --context std-westLe résultat ressemble à celui de l'exemple ci-dessous.
namespace/onlineboutique createdClonez le dépôt GitHub Online Boutique et configurez une variable WORKDIR :
cd ~ git clone --branch release/v0.4.1 \ https://github.com/GoogleCloudPlatform/microservices-demo.git cd microservices-demo/release && export WORKDIR=`pwd`Déployez Online Boutique sur std-west. Ce processus crée
DeploymentsetServicespour tous les microservices d'Online Boutique, et inclut un service de type LoadBalancer qui expose en externe le service de frontend d'Online Boutique :cd $WORKDIR kubectl apply -f kubernetes-manifests.yaml \ -n onlineboutique --context=std-westAttendez que le service
LoadBalancerobtienne une adresse IP externe :watch -n 20 --difference=permanent \ "kubectl get svc frontend-external -n onlineboutique --context=std-west"Tout d'abord, la sortie ressemble à l'exemple ci-dessous :
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend-external LoadBalancer 10.60.5.62 <pending> 80:30359/TCP 43sLorsque le
Serviceest prêt, la colonne EXTERNAL-IP affiche l'adresse IP publique de l'équilibreur de charge.Une fois que le
Serviceest prêt, obtenez l'adresse IP externe de l'équilibreur de charge et utilisez curl pour vérifier que l'interface est prête. Si cette commande curl renvoie une erreur, attendez quelques instants avant de réessayer :curl $(kubectl get svc frontend-external \ -n onlineboutique --context=std-west \ -o=jsonpath="{.status.loadBalancer.ingress[0].ip}") | \ grep -e Cluster -e Zone -e PodLa sortie réussie de la commande curl aboutit à l'exemple suivant :
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-b7bddcc97-wdjsk
Vous disposez maintenant d'une version à zone unique d'Online Boutique s'exécutant dans us-west1-a.
Vous pouvez également utiliser un navigateur Web pour accéder à l'adresse IP externe attribuée au service LoadBalancer frontend-external pour accéder à l'application et observer son comportement. Ce déploiement unique initial est illustré dans le schéma suivant :
Exporter le cartservice en tant que service multicluster
Dans cette section, vous allez commencer à ajouter des éléments de haute disponibilité à l'application. Vous allez exporter le cartservice de backend en tant que service multicluster vers les clusters GKE Autopilot.
Créez l'espace de noms onlineboutique sur les clusters restants :
kubectl create namespace onlineboutique --context auto-east kubectl create namespace onlineboutique --context auto-central kubectl create namespace onlineboutique --context config-centralPour chaque commande, la sortie ressemble à ce qui suit :
namespace/onlineboutique createdExportez cartservice du cluster std-west vers tous les autres clusters de
ClusterSet. L'objetServiceExportenregistre le service cartservice, avec des services multicluster GKE, pour l'exportation vers tous les clusters du parc disposant de l'espace de noms onlineboutique. Pour en savoir plus, consultez la section Enregistrer un service pour l'exportation.cat <<EOF>> $WORKDIR/cartservice-export.yaml kind: ServiceExport apiVersion: net.gke.io/v1 metadata: namespace: onlineboutique name: cartservice EOF kubectl apply -f $WORKDIR/cartservice-export.yaml \ -n onlineboutique --context=std-west
Appliquer les fichiers manifestes d'applications pour le modèle multicluster
Dans cette section, vous allez appliquer deux fichiers manifestes sélectionnés afin de déployer le modèle multicluster. Ces fichiers manifestes contiennent des parties sélectionnées du fichier kubernetes-manifests.yaml que vous avez précédemment appliqué au cluster std-west :
- Le premier fichier manifeste sert aux
Deployment,ServiceetServiceExportde frontend. - Le deuxième fichier manifeste sert à déployer les
Servicesde middleware (emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice et adservice) à toutes les régions disposant d'un frontend en cours d'exécution. En conservant une requête locale dans une région aussi longtemps que possible, vous évitez des frais de trafic réseau interrégionaux inutiles.
Un Pod qui s'exécute dans n'importe quel cluster du parc peut accéder à un Service exporté en envoyant une requête à l'URI ClusterSet pour ce service au format SERVICE_NAME.NAMESPACE.svc.clusterset.local. Par exemple, les Deployments de frontend dans les trois exemples de clusters peuvent utiliser le cartservice, dans l'espace de noms onlineboutique, en envoyant une requête à cartservice.onlineboutique.svc.clusterset.local.
Pour cette raison, dans chaque fichier manifeste, le nom d'hôte du service cartservice a été mis à jour vers son URI ClusterSet. Cette étape est essentielle. Si ce nom d'hôte de service n'est pas mis à jour, le service de frontend demande à kube-dns cartservice au lieu de cartservice.onlineboutique.svc.clusterset.local. Ce comportement entraîne des erreurs HTTP Status 500 sur les clusters où une version locale de cartservice n'est pas disponible, et le fait que les pods frontend ne sont pas opérationnels.
Définissez une variable d'environnement pour le dépôt GitHub contenant les fichiers manifestes :
export MANIFEST_REPO_PATH=https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/cluster-migrationAppliquez les fichiers manifestes pour déployer la couche frontend sur les trois clusters de charge de travail :
kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \ -n onlineboutique --context=std-west kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \ -n onlineboutique --context=auto-east kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \ -n onlineboutique --context=auto-centralAppliquez les fichiers manifestes pour déployer la couche middleware sur les trois clusters de charge de travail :
kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \ -n onlineboutique --context=std-west kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \ -n onlineboutique --context=auto-east kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \ -n onlineboutique --context=auto-central
Deployment, Service et ServiceExport de frontend sont désormais actifs dans les clusters std-ouest, auto-east et auto-central. Vous disposez également de services de middleware Online Boutique s'exécutant localement dans chaque cluster. Cependant, le trafic externe n'est toujours acheminé que vers le Service qui s'exécute dans le cluster initial dans us-west1, comme indiqué dans le schéma suivant :
Activer et configurer des passerelles multiclusters.
Dans cette section, vous allez acheminer le trafic vers les interfaces et équilibrer sa charge dans les trois clusters. Pour effectuer cette configuration, vous utilisez des passerelles multiclusters (MCG). Ce document suit les instructions de configuration de MCG décrites dans la page Activer des passerelles multiclusters.
Dans ce guide, vous hébergez la configuration des ressources Gateway à l'aide du cluster config-central.
Vérifiez que tous les clusters ont bien été enregistrés dans le parc :
gcloud container fleet memberships list --project=$PROJECTL'exemple de sortie suivant montre que tous les clusters sont bien enregistrés :
NAME: auto-central EXTERNAL_ID: 21537493-32ea-4a41-990d-02be2c1b319f NAME: config-central EXTERNAL_ID: 4369423e-ea7b-482d-a0eb-93b560e67b98 NAME: std-west EXTERNAL_ID: 7fcb048b-c796-476b-9698-001a00f91ab3 NAME: auto-east EXTERNAL_ID: aae2d2ff-b861-4a38-bcaf-612f14810012Installez la définition de ressource personnalisée de l'API Gateway sur le cluster config-central :
kubectl --context=config-central kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.5.0" \ | kubectl apply -f -Cette étape installe les définitions de ressources personnalisées de l'API Gateway, y compris les ressources
GatewayClass,GatewayetHTTPRoute. Les définitions de ressources personnalisées sont gérées par le groupe d'intérêts spécial du réseau de Kubernetes. Une fois l'installation effectuée, vous pouvez utiliser le contrôleur GKE Gateway.Activez Multi Cluster Ingress pour votre parc si vous ne l'avez pas déjà fait. L'activation de cette fonctionnalité active également le contrôleur Gateway multiclusters.
gcloud container fleet ingress enable \ --config-membership=config-central \ --project=$PROJECT gcloud container fleet ingress describe --project=$PROJECTLe résultat ressemble à celui de l'exemple ci-dessous.
createTime: '2021-12-08T23:10:52.505888854Z' name: projects/PROJECT_ID/locations/global/features/multiclusteringress resourceState: state: ACTIVE spec: multiclusteringress: configMembership: projects/zl-mcs-expf61cbd13/locations/global/memberships/config-central state: state: code: OK description: Ready to use updateTime: '2021-12-08T23:11:37.994971649Z' updateTime: '2021-12-08T23:11:38.098244178Z'Si la valeur de state n'est pas ACTIVE, consultez la section Dépannage et opérations Ingress multicluster.
Vérifiez que les
GatewayClassessont disponibles sur le cluster config-central :kubectl get gatewayclasses --context=config-centralLe résultat ressemble à celui de l'exemple ci-dessous.
NAME CONTROLLER AGE gke-l7-global-external-managed networking.gke.io/gateway 18s gke-l7-global-external-managed-mc networking.gke.io/gateway 19s gke-l7-regional-external-managed networking.gke.io/gateway 18s gke-l7-regional-external-managed-mc networking.gke.io/gateway 19s gke-l7-gxlb networking.gke.io/gateway 74s gke-l7-gxlb-mc networking.gke.io/gateway 16s gke-l7-rilb networking.gke.io/gateway 74s gke-l7-rilb-mc networking.gke.io/gateway 16sDifférentes ressources
GatewayClassont des fonctionnalités différentes. Pour savoir quand utiliser quel type, consultez la section Fonctionnalités GatewayClass.Déployez la ressource Gateway
external-httpsurconfig-central:cat <<EOF>> $WORKDIR/external-http-gateway.yaml kind: Gateway apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: external-http namespace: onlineboutique spec: gatewayClassName: gke-l7-global-external-managed-mc listeners: - protocol: HTTP port: 80 name: http EOF kubectl apply -f external-http-gateway.yaml \ -n onlineboutique --context=config-centralComme indiqué par le champ
gatewayClassName, cette ressource est deGatewayClassgke-l7-global-external-managed-mc qui gère Cloud Load Balancing de couche 7 externe et expose les application multiclusters.Déployez la ressource
HTTPRoutenommée public-frontend-route sur config-central :cat <<EOF>> $WORKDIR/public-frontend-route.yaml kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: public-frontend-route namespace: onlineboutique spec: parentRefs: - name: "external-http" hostnames: - "store.example.com" rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: frontend group: net.gke.io kind: ServiceImport port: 80 EOF kubectl apply -f public-frontend-route.yaml \ -n onlineboutique --context=config-centralLorsque vous déployez la ressource
HTTPRoute, elle crée une ressource Cloud Load Balancing de couche 7 externe et expose leServiceImportde frontend sauvegardé par les services de frontend qui s'exécutent dans les clusters std-west, auto-east et auto-central.Le schéma suivant montre comment, une fois la passerelle multicluster déployée, le trafic peut être acheminé vers l'un des services multiclusters de frontend sur l'un des trois clusters d'application :
Attendez que l'équilibreur de charge soit prêt avec une adresse IP externe provisionnée avant de passer à l'étape suivante. L'attribution de l'adresse IP peut prendre jusqu'à 10 minutes. Vous pouvez surveiller la progression à l'aide d'une boucle de contrôle. L'équilibreur de charge porte un nom au format gkemcg-onlineboutique-external-http-k09mfhk74gop :
watch -n 20 --difference=permanent \ "gcloud compute forwarding-rules list \ | grep -A 5 NAME..*external-http"Le résultat ressemble à celui de l'exemple ci-dessous.
NAME: gkemcg-onlineboutique-external-http-k09mfhk74gop REGION: IP_ADDRESS: 34.149.29.176 IP_PROTOCOL: TCP TARGET: gkemcg-onlineboutique-external-http-k09mfhk74gopUne fois que l'équilibreur de charge est prêt, exécutez la commande suivante dans Cloud Shell pour exporter l'adresse IP externe de l'équilibreur de charge créé via l'application des fichiers manifestes external-http-gateway.yaml et public-frontend-route.yaml :
export EXTERNAL_LB_IP=$(kubectl --context=config-central \ -n onlineboutique get gateway external-http \ -o=jsonpath='{.status.addresses[0].value}')Lorsque vous envoyez une requête à l'équilibreur de charge avec les en-têtes appropriés, elle renvoie le contenu HTML diffusé par le service de frontend. Par exemple, étant donné que vous avez configuré la ressource
HTTPRoutepour mapper le nom d'hôtestore.example.comsur leServiceImportde frontend, vous devez fournir l'en-têteHOSTlorsque vous effectuez la requête HTTP. Si l'exemple curl suivant renvoie une erreur, attendez quelques minutes et réessayez :curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodLa sortie réussie de la commande curl aboutit à l'exemple suivant :
<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-f<br/> <b>Pod: </b>frontend-7c7d596ddc-jdh8f
Tester le comportement de routage multirégional de l'application
L'une des puissantes fonctionnalités obtenues grâce à l'utilisation de services multiclusters et de passerelles multiclusters est que les requêtes externes sont acheminées vers le cluster géographiquement le plus proche.
Pour tester le comportement multirégional de l'application, générez le trafic provenant des différentes régions dans lesquelles vous avez déployé des clusters. Créez trois petits pods, un dans chacun des clusters de diffusion (std-west, auto-east et auto-central), que vous pouvez utiliser pour envoyer des requêtes HTTP au point de terminaison de l'équilibreur de charge. Les résultats vous permettent de voir quel Pod de frontend répond.
Créez les pods clients :
kubectl run --context=std-west \ --image=radial/busyboxplus:curl client-west \ -- sh -c 'while sleep 3600; do :; done' kubectl run --context=auto-east \ --image=radial/busyboxplus:curl client-east \ -- sh -c 'while sleep 3600; do :; done' kubectl run --context=auto-central \ --image=radial/busyboxplus:curl client-central \ -- sh -c 'while sleep 3600; do :; done'Une fois les pods en cours d'exécution, utilisez une commande curl pour envoyer une requête au point de terminaison de l'équilibreur de charge à partir du client
Poddans le cluster std-west, puis examinez la réponse :kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodLa sortie réussie de la commande curl aboutit à l'exemple suivant :
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-7cf48b79cf-trzc4Exécutez la même requête curl depuis le client
Poddans le cluster auto-east, puis examinez la réponse :kubectl exec -it --context=auto-east client-east \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodLa sortie réussie de la commande curl aboutit à l'exemple suivant :
<b>Cluster: </b>auto-east<br/> <b>Zone: </b>us-east1-d<br/> <b>Pod: </b>frontend-6784b6df98-scdwsComme il s'agit d'un cluster Autopilot, le cluster devra peut-être provisionner des ressources supplémentaires pour planifier le
Pod. Si un résultat semblable à l'exemple suivant s'affiche, attendez un peu et réessayez :Error from server (BadRequest): pod client-east does not have a host assignedExécutez curl à partir du client
Poddans le cluster auto-central et vérifiez la réponse :kubectl exec -it --context=auto-central client-central \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodLa sortie réussie de la commande curl aboutit à l'exemple suivant :
<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-b<br/> <b>Pod: </b>frontend-6784b6df98-x2fv4Ces résultats confirment que les routes de trafic vers les pods correspondants se trouvent dans les emplacements les plus proches de l'origine de la requête.
Tester la résilience multirégionale de l'application
En plus d'un routage efficace du trafic, l'exécution de vos services dans plusieurs régions offre une résilience dans les cas rares, mais toujours possibles, de défaillance de l'infrastructure.
Testez le comportement en supprimant les Deployments de frontend de clusters spécifiques, puis réessayez d'exécuter la commande curl depuis le Pod client dans ces régions. Notez que l'application est toujours disponible, et examinez l'emplacement du Pod qui répond à la requête.
Exécutez la commande curl depuis le
Podclient-west dans le cluster std-west, et observez que le résultat provient de l'interface dans us-west1 :kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodLa sortie réussie de la commande curl aboutit à l'exemple suivant :
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-7cf48b79cf-trzc4Supprimez le
Deploymentde frontend du cluster std-west :kubectl delete deploy frontend \ -n onlineboutique --context=std-westLe résultat ressemble à celui de l'exemple ci-dessous.
deployment.apps "frontend" deletedEnvoyez une autre requête à partir du
Podclient-west dans le cluster std-west. Une réponse de l'un desDeploymentsde frontend restants situés dans les clusters auto-east ou auto-central doit s'afficher :kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e PodUne sortie semblable à l'exemple suivant indique l'emplacement du
Podopérationnel qui répond à cette requête :<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-b<br/> <b>Pod: </b>frontend-6784b6df98-x2fv4ou
<b>Cluster: </b>auto-east<br/> <b>Zone: </b>us-east1-d<br/> <b>Pod: </b>frontend-6784b6df98-scdwsExécutez la commande plusieurs fois pour voir des résultats alternatifs.
Avec ce déploiement de démonstration, vous avez ajouté des éléments de résilience et de distribution géographique à l'application Online Boutique à l'aide de services multiclusters et de passerelles multiclusters. Les requêtes sont acheminées vers la région géographique la plus proche et, même si les services de frontend ou de middleware d'une région rencontrent des problèmes, l'utilisateur final peut toujours utiliser l'application.
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 et supprimez les ressources individuelles.
- Dans la console Google Cloud, accédez à la page Gérer les ressources.
- Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
- Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.
Étape suivante
- Apprenez-en plus sur la gestion de parc et de multicluster Google Cloud.
- Découvrez comment enregistrer un cluster, y compris des clusters GKE Enterprise, sur un parc Google Cloud.
- Approfondissez vos connaissances sur l'API Kubernetes Gateway et GKE Gateway.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.