Passer à une mise en réseau multicluster avec des clusters Google Kubernetes Engine (GKE) Autopilot et Standard

Last reviewed 2022-02-17 UTC

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 :

Les services multiclusters facilitent la communication entre les services d'un cluster et la passerelle multicluster déploie des équilibreurs de charge pour acheminer le trafic entre les clusters.

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 :

Un unique cluster en mode GKE Standard qui exécute tous les services exposés à l'aide d'un service LoadBalancer externe HTTP standard

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 :

Les services multiclusters s'exécutent sur trois clusters GKE, mais le trafic est toujours dirigé vers un seul cluster à l'aide d'un service LoadBalancer externe HTTP standard.

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.

Les services multiclusters s'exécutent sur trois clusters GKE. Le trafic est désormais réparti entre les services frontend de tous les clusters à l'aide d'une passerelle externe multicluster.

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 Services multiclusters.
  • 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. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

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.

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

    Activate Cloud Shell

  2. 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}
    
  3. 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 enable
    

    Les 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.
    
  4. Vérifiez que les services multiclusters affichent l'état ACTIVE :

    gcloud container fleet multi-cluster-services describe
    

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

  1. 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 \
        --async
    

    La 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-pool lorsque vous créez ces clusters comme vous le faites avec les clusters GKE Standard.

  2. 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: PROVISIONING
    
  3. Une fois que tous les clusters sont à l'état RUNNING (en cours d'exécution), appuyez sur CTRL-C pour interrompre la commande.

  4. 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
    [...]
    
  5. 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.
    
  6. 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 $PROJECT
    

    Pour chaque commande, la sortie ressemble à ce qui suit :

    Fetching cluster endpoint and auth data.
    kubeconfig entry generated for std-west.
    
  7. 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-central
    

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

  1. Créez l'espace de noms onlineboutique sur std-west :

    kubectl create namespace onlineboutique --context std-west
    

    Le résultat ressemble à celui de l'exemple ci-dessous.

    namespace/onlineboutique created
    
  2. Clonez 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`
    
  3. Déployez Online Boutique sur std-west. Ce processus crée Deployments et Services pour 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-west
    
  4. Attendez que le service LoadBalancer obtienne 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   43s
    

    Lorsque le Service est prêt, la colonne EXTERNAL-IP affiche l'adresse IP publique de l'équilibreur de charge.

  5. Une fois que le Service est 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 Pod
    

    La 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 :

Un unique cluster en mode GKE Standard qui exécute tous les services exposés via un service LoadBalancer externe HTTP standard

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.

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

    Pour chaque commande, la sortie ressemble à ce qui suit :

    namespace/onlineboutique created
    
  2. Exportez cartservice du cluster std-west vers tous les autres clusters de ClusterSet. L'objet ServiceExport enregistre 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, Service et ServiceExport de frontend.
  • Le deuxième fichier manifeste sert à déployer les Services de 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.

  1. 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-migration
    
  2. Appliquez 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-central
    
  3. Appliquez 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 :

Les services multiclusters s'exécutent sur trois clusters GKE, mais le trafic est toujours dirigé vers un seul cluster à l'aide d'un service LoadBalancer externe HTTP standard.

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.

  1. Vérifiez que tous les clusters ont bien été enregistrés dans le parc :

    gcloud container fleet memberships list --project=$PROJECT
    

    L'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-612f14810012
    
  2. Installez 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, Gateway et HTTPRoute. 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.

  3. 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=$PROJECT
    

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

  4. Vérifiez que les GatewayClasses sont disponibles sur le cluster config-central :

    kubectl get gatewayclasses --context=config-central
    

    Le 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   16s
    

    Différentes ressources GatewayClass ont des fonctionnalités différentes. Pour savoir quand utiliser quel type, consultez la section Fonctionnalités GatewayClass.

  5. Déployez la ressource Gateway external-http sur config-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-central
    

    Comme indiqué par le champ gatewayClassName, cette ressource est de GatewayClass gke-l7-global-external-managed-mc qui gère Cloud Load Balancing de couche 7 externe et expose les application multiclusters.

  6. Déployez la ressource HTTPRoute nommé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-central
    

    Lorsque vous déployez la ressource HTTPRoute, elle crée une ressource Cloud Load Balancing de couche 7 externe et expose le ServiceImport de 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 :

    Les services multiclusters s'exécutent sur trois clusters GKE. Le trafic est désormais réparti entre les services frontend de tous les clusters à l'aide d'une passerelle externe multicluster.

  7. 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-k09mfhk74gop
    
  8. Une 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}')
    
  9. 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 HTTPRoute pour mapper le nom d'hôte store.example.com sur le ServiceImport de frontend, vous devez fournir l'en-tête HOST lorsque 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 Pod
    

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

  1. 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'
    
  2. 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 Pod dans 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 Pod
    

    La 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-trzc4
    
  3. Exécutez la même requête curl depuis le client Pod dans 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 Pod
    

    La 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-scdws
    

    Comme 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 assigned
    
  4. Exécutez curl à partir du client Pod dans 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 Pod
    

    La 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-x2fv4
    

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

  1. Exécutez la commande curl depuis le Pod client-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 Pod
    

    La 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-trzc4
    
  2. Supprimez le Deployment de frontend du cluster std-west :

    kubectl delete deploy frontend \
        -n onlineboutique --context=std-west
    

    Le résultat ressemble à celui de l'exemple ci-dessous.

    deployment.apps "frontend" deleted
    
  3. Envoyez une autre requête à partir du Pod client-west dans le cluster std-west. Une réponse de l'un des Deployments de 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 Pod
    

    Une sortie semblable à l'exemple suivant indique l'emplacement du Pod opé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-x2fv4
    

    ou

    <b>Cluster: </b>auto-east<br/>
    <b>Zone: </b>us-east1-d<br/>
    <b>Pod: </b>frontend-6784b6df98-scdws
    

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

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

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

Étape suivante