Configurer l'équilibrage de charge basé sur les vérifications de l'état

Ce document explique comment implémenter la haute disponibilité pour les adresses IP persistantes sur Google Kubernetes Engine (GKE) à l'aide de l'équilibrage de charge basé sur les vérifications de l'état. Bien que les configurations d'adresses IP persistantes standards mappent une seule adresse IP persistante à un seul pod, l'équilibrage de charge basé sur la vérification de l'état vous permet de répartir le trafic d'une ou de plusieurs adresses IP persistantes sur un pool de pods opérationnels.

Pour revendiquer des adresses IP persistantes spécifiques et identifier les pods qui reçoivent du trafic, vous devez créer une ressource personnalisée GKEIPRoute. En intégrant la ressource GKEIPRoute aux vérifications de l'état régionales, GKE surveille vos charges de travail au niveau de la couche réseau et n'achemine le trafic que vers les pods prêts à le recevoir. Vous pouvez également désigner des pods de sauvegarde facultatifs à l'aide de l'objet GKEIPRoute. GKE n'achemine le trafic vers ces pods de secours que si tous les pods actifs principaux échouent à la vérification de l'état.

Conditions requises et limites

  • Pour utiliser l'équilibrage de charge basé sur des vérifications de l'état, votre cluster doit exécuter GKE version 1.32.3-gke.1440000 ou ultérieure. GKE permet de sélectionner des pods de sauvegarde uniquement sur la version 1.35.0-gke.1403000 ou ultérieure.
  • GKE Dataplane V2 et l'API Gateway doivent être activés sur votre cluster.
  • Un objet GKEIPRoute ne peut accepter qu'un seul pod correspondant par nœud. Si plusieurs pods sur un nœud correspondent au sélecteur de pods de GKEIPRoute, GKE choisit le pod créé le plus récemment sur ce nœud.
  • Vous ne pouvez pas modifier une classe Gateway après avoir créé l'objet GKEIPRoute.
  • L'équilibrage de charge basé sur les vérifications de l'état n'accepte que le trafic initié en dehors de la charge de travail. Le trafic initié depuis la charge de travail vers l'adresse IP persistante n'est pas accepté.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Pour utiliser Google Cloud CLI pour cette tâche, installez puis initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

Implémenter un équilibrage de charge basé sur les vérifications de l'état

Cette section récapitule le workflow permettant d'implémenter l'équilibrage de charge basé sur les vérifications d'état :

  1. Créer une vérification d'état régionale : définissez les paramètres que GKE utilise pour surveiller l'état de vos pods. Cet objet indique à la couche réseau quels points de terminaison sont opérationnels et éligibles pour recevoir le trafic provenant de l'adresse IP persistante.
  2. Créer un cluster : configurez un cluster GKE avec GKE Dataplane V2 et l'API Gateway activées. Ces composants fournissent l'infrastructure sous-jacente requise pour gérer le routage IP persistant et l'équilibrage de charge basé sur la vérification de l'état.
  3. Réserver une adresse IP : sélectionnez et réservez une adresse IP statique interne ou externe dans la même région que votre cluster. Cette adresse sert de point d'entrée persistant que GKE distribuera dans votre pool de pods actifs ou de sauvegarde.
  4. Créer une passerelle : configurez un objet de passerelle pour gérer vos adresses IP persistantes réservées. L'objet GKEIPRoute revendique et utilise des adresses IP spécifiques de la passerelle pour vos charges de travail.
  5. Créer un objet GKEIPRoute : définissez les règles de routage qui mappent votre adresse IP persistante à un groupe de pods à l'aide de sélecteurs d'étiquettes. Dans cet objet, vous référencez votre vérification de l'état régionale et vous pouvez éventuellement désigner des pods de sauvegarde pour les scénarios de basculement.
  6. Afficher les points de terminaison correspondants : vérifiez que GKE a correctement identifié vos pods actifs et de sauvegarde en inspectant les EndpointSlices générés automatiquement. Cette étape confirme que vos libellés correspondent aux pods attendus et que la couche réseau est prête à acheminer le trafic.

Étape 1 : Créer une vérification de l'état régionale et des règles de pare-feu

Pour créer une vérification de l'état régionale, suivez les étapes décrites dans Créer des vérifications d'état. Le nom que vous fournissez ici sera utilisé dans votre configuration GKEIPRoute. Exemple :

gcloud compute health-checks create http reg-lb-hc \
    --region=us-central1 \
    --check-interval=5s \
    --timeout=5s \
    --healthy-threshold=2 \
    --unhealthy-threshold=2

Pour permettre vérification de l'état de Google Cloud d'atteindre vos nœuds, vous devez également créer des règles de pare-feu.

Étape 2 : Créer un cluster GKE

Créez un cluster avec l'API Gateway et GKE Dataplane V2 activés. Exemple :

gcloud container clusters create cluster-1 \
    --enable-dataplane-v2 \
    --gateway-api=standard \
    --region=us-central1

Si vous configurez l'objet GKEIPRoute sur un réseau VPC différent du réseau VPC par défaut du cluster, vous devez créer un cluster GKE avec des fonctionnalités multiréseaux. Pour en savoir plus, consultez Configurer la compatibilité multiréseau pour les pods.

Étape 3 : Réservez des adresses IP

Réservez les adresses IP que vous souhaitez utiliser pour vos charges de travail. Vous pouvez choisir de réserver des adresses IP fournies par Google ou d'utiliser les vôtres (BYOIP).

Étape 3a : Réserver les adresses IP fournies par Google

Pour réserver des adresses IP externes, exécutez la commande suivante :

gcloud compute addresses create ADDRESS_NAME \
   --region=REGION

Remplacez les éléments suivants :

  • ADDRESS_NAME : nom que vous souhaitez associer à cette adresse.

  • REGION : région dans laquelle vous souhaitez réserver cette adresse. Il doit s'agir de la même région que le pod auquel vous souhaitez associer l'adresse IP.

    Remarque : Vous devez spécifier une région lorsque vous réservez une adresse IP, car les règles de transfert, qui gèrent le routage du trafic pour les adresses IP persistantes, sont régionales. Votre adresse IP et votre cluster GKE doivent se trouver dans la même région pour que le routage fonctionne correctement.

Pour réserver des adresses IP internes, exécutez la commande suivante :

gcloud compute addresses create ADDRESS_NAME \
    --region REGION
    --subnet SUBNETWORK \
    --addresses IP_ADDRESS

Remplacez les éléments suivants :

  • ADDRESS_NAME : nom d'une ou de plusieurs adresses que vous souhaitez réserver. Dans le cas de plusieurs adresses, spécifiez toutes les adresses sous forme de liste, séparées par des espaces. Par exemple, adresse-exemple-1 adresse-exemple-2 adresse-exemple-3.
  • REGION : région de la requête.
  • SUBNETWORK : sous-réseau de l'adresse IPv4 interne.
  • IP_ADDRESS : adresse IP interne non utilisée de la plage d'adresses IP principale du sous-réseau sélectionné.

Pour que le trafic soit acheminé correctement au sein de votre réseau privé, les adresses IP internes doivent appartenir au sous-réseau par défaut du cluster ou au sous-réseau réseau supplémentaire.

Pour en savoir plus sur les adresses IP externes et internes, ou pour découvrir comment réserver des adresses à l'aide de la console Google Cloud , consultez Réserver une adresse IP externe statique et Réserver une adresse IP interne statique.

Étape 3b : Utilisez vos propres adresses IP (BYOIP)

Vous pouvez importer vos propres adresses IP (BYOIP) au lieu d'utiliser celles fournies par Google. BYOIP est utile si vous avez besoin d'adresses IP spécifiques pour vos applications ou si vous migrez des systèmes existants vers Google Cloud. Pour utiliser BYOIP, Google vérifie que vous êtes propriétaire de la plage d'adresses IP. Une fois les adresses IP importées dans Google Cloud, vous pouvez les attribuer en tant qu'adresses IP pour les pods GKE. Pour en savoir plus, consultez Utiliser vos propres adresses IP.

Étape 4 : Créer des objets Gateway

Créez une passerelle à l'aide de l'une des classes de passerelle suivantes, qui ne prennent en charge que le type de réseau L3 :

  • gke-passthrough-lb-external-managed ou
  • gke-passthrough-lb-internal-managed.

L'exemple suivant définit une passerelle qui gère un pool d'adresses IP externes :

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: lb-gateway
spec:
  gatewayClassName: gke-passthrough-lb-external-managed

  listeners:
    - name: default
      port: 443
      protocol: none
      allowedRoutes:
        namespaces:
          from: All

  addresses:
    - value: "34.123.10.1/32"
      type: "gke.networking.io/cidr"
    - value: "34.123.10.2/32"
      type: "gke.networking.io/cidr"

Dans l'exemple précédent, notez les champs suivants :

  • addresses : répertorie toutes les plages d'adresses IP pour lesquelles la passerelle spécifique gère les autorisations.
  • listeners : identifie les espaces de noms à partir desquels les objets GKEIPRoute peuvent référencer cette passerelle.

Pour en savoir plus sur l'utilisation des écouteurs, consultez Créer des objets Gateway.

Étape 5 : Créer un objet GKEIPRoute avec la configuration de l'équilibrage de charge et de la vérification de l'état'état

Créez un objet GKEIPRoute dans lequel vous définissez vos sélecteurs de pods principal et de sauvegarde, et associez la vérification de l'état que vous avez créée à l'étape 1.

kind: GKEIPRoute
apiVersion: networking.gke.io/v1
metadata:
  namespace: default
  name: my-ip-route
spec:
  parentRefs:
  - name: lb-gateway
  addresses:
  - value: "34.123.10.1/32"
    type: "gke.networking.io/cidr"
  - value: "34.123.10.2/32"
    type: "gke.networking.io/cidr"
  network: default
  podSelector:
    matchLabels:
      component: activePodSelector

  loadBalancing:
    healthCheckName: "reg-lb-hc"
    backupPodSelector:
      namespaceSelector:
        matchLabels:
          environment: test
          dc: us-central
      podSelector:
        matchLabels:
          component: backupPodSelector
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: default
  name: proxy-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: proxy
  template:
    metadata:
      # annotations:  <- Include these lines if the pods are multi-nic pods
      #   networking.gke.io/default-interface: 'eth0'
      #   networking.gke.io/interfaces: '[{"interfaceName":"eth0","network":"default"}, {"interfaceName":"eth1","network":"blue-network"}]'
      labels:
        component: proxy
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Veuillez noter les points suivants :

  • podSelector : identifie les pods actifs principaux qui reçoivent le trafic des adresses IP persistantes définies. Ce champ utilise des libellés pour faire correspondre les pods dans le même espace de noms que la ressource GKEIPRoute. GKE répartit le trafic entre tous les pods opérationnels qui correspondent à ce sélecteur. Si plusieurs pods correspondants résident sur le même nœud, GKE ne sélectionne que le pod créé le plus récemment pour recevoir le trafic. Les libellés définis ici ne doivent pas chevaucher ceux du champ backupPodSelector. Ce champ est modifiable.
  • backupPodSelector : définit les pods de secours qui ne reçoivent du trafic que si tous les pods principaux correspondant à l'objet podSelector échouent à leurs vérifications d'état. Ce sélecteur inclut les éléments suivants :
    • namespaceSelector : détermine les espaces de noms dans lesquels GKE recherche ces pods de sauvegarde. Vous pouvez limiter la recherche à des espaces de noms spécifiques à l'aide de sélecteurs de libellés. Si ce champ est omis ou vide, GKE recherche les pods de sauvegarde dans tous les espaces de noms du cluster.
    • podSelector : correspond aux pods de sauvegarde en fonction de leurs libellés. Ces étiquettes doivent être distinctes de celles utilisées dans l'objet podSelector principal.

Pour en savoir plus sur les autres champs de ce fichier manifeste, consultez Créer l'objet GKEIPRoute.

Étape 6 : Utiliser les adresses IP attribuées dans le pod

L'attribution d'une adresse IP à un pod GKE à l'aide d'un objet GKEIPRoute ne rend pas automatiquement les adresses IP utilisables par votre application. Les adresses IP sont gérées au niveau du routage réseau, mais la configuration par défaut de votre pod ne les connaîtra pas. Vous devez configurer la spécification de votre pod pour qu'il reconnaisse et utilise l'adresse dans le pod. Pour ce faire, votre Pod nécessite des autorisations privilégiées.

Vous pouvez configurer la spécification de votre pod à l'aide de l'une des options suivantes :

  • Modifier sysctl net.ipv4.ip_nonlocal_bind

    Vous pouvez modifier les paramètres système pour permettre à votre application d'utiliser des adresses IP qui ne sont pas directement attribuées à son interface en définissant net.ipv4.ip_nonlocal_bindsysctl dans votre pod securityContext. Cette option est utile si votre application peut se lier à une adresse IP qui ne se trouve pas sur une interface.

    Ajoutez les éléments suivants à la spécification YAML de votre déploiement ou StatefulSet sous spec.template.spec :

    securityContext:
  sysctls:
  - name: net.ipv4.ip_nonlocal_bind
    value: "1"

  • Ajouter l'adresse IP attribuée à l'interface du pod

    Vous pouvez ajouter manuellement l'adresse IP revendiquée par l'objet GKEIPRoute à l'une des interfaces du pod à l'aide d'un conteneur init. L'adresse IP est ainsi visible par le pod comme si elle lui était directement attribuée. Pour ce faire, vous devez disposer de la fonctionnalité NET_ADMIN.

    Ajoutez les éléments suivants à la spécification YAML de votre déploiement ou StatefulSet sous spec.template.spec :

    initContainers:
- name: configure-ips
  image: gcr.io/google.com/cloudsdktool/cloud-sdk:slim
  command: ['sh', '-c', 'ip address add ASSIGNED_IP/32 dev eth0']
  securityContext:
    capabilities:
      add:
      - NET_ADMIN

    Remplacez ASSIGNED_IP par l'une des adresses IP attribuées à l'objet GKEIPRoute.

  • Sockets bruts : pour un contrôle encore plus précis, votre application peut interagir directement avec la pile réseau (avancé).

  • Pile d'adresses IP de l'espace utilisateur : dans des cas spécifiques, une application distincte peut s'exécuter dans le pod pour gérer l'adresse IP (très avancé).

Étape 7 : Activez ARP pour les adresses IP attribuées (réseau par défaut uniquement)

Pour générer des requêtes et des réponses ARP (Address Resolution Protocol) valides, et pour établir une nouvelle connexion à un pod en utilisant l'adresse IP attribuée par l'objet GKEIPRoute sur le réseau par défaut, vous devez configurer la variable arp_announce.

Pour définir la variable arp_announce, exécutez la commande suivante sur votre pod :

echo "2" > /proc/sys/net/ipv4/conf/eth0/arp_announce

où la variable arp_announce contrôle la façon dont les annonces ARP sont gérées. Si vous le définissez sur "2", vous vous assurez que des annonces ARP sont émises pour l'adresse IP persistante, ce qui permet aux autres appareils du réseau de prendre connaissance de la nouvelle association.

Étape 8 : Afficher les points de terminaison correspondants

Pour gérer la répartition du trafic, GKE crée des EndpointSlices pour chaque objet GKEIPRoute. Ces tranches servent de registre pour tous les pods désignés comme destinations de routage pour cette route spécifique.

GKE génère des EndpointSlices distincts pour les points de terminaison actifs et de sauvegarde. Le système ajuste automatiquement le nombre d'EndpointSlices en fonction de votre charge de travail. Bien qu'un seul EndpointSlice puisse accepter jusqu'à 1 000 points de terminaison, GKE crée des tranches supplémentaires si le nombre de pods correspondants dépasse cette limite.

Pour afficher tous les EndpointSlices d'un objet GKEIPRoute spécifique, exécutez la commande suivante :

kubectl get endpointslices --all-namespaces -l \
  networking.gke.io/gkeiproute-name=GKEIPROUTE_NAME,\
  networking.gke.io/gkeiproute-namespace=GKEIPROUTE_NAMESPACE

Remplacez les éléments suivants :

  • GKEIPROUTE_NAME : nom du fichier manifeste GKEIPRoute.
  • GKEIPROUTE_NAMESPACE : espace de noms du fichier manifeste GKEIPRoute.

La sortie suivante montre un exemple de EndpointSlice :

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
 name: {gkeiproute_name-truncated}-{gkeiproute_namespace-truncated}-backup-{unique_hash}
 namespace: {gkeiproute_namespace}
 labels:
  endpointslice.kubernetes.io/managed-by: gkeiproute-controller
  networking.gke.io/gkeiproute-name: {gkeiproute_name}
  networking.gke.io/gkeiproute-namespace: {gkeiproute_namespace}
  networking.gke.io/pip-es-role: backup
 ownerReferences:
  - kind: GKEIPRoute
    name: {gkeiproute_name}
    apiVersion: networking.gke.io/v1
    uid: {uid}
    controller: true
addressType: IPv4
endpoints:
 - addresses:
     - "{pod_ip_address}"
   targetRef:
     Name: {pod_name}
   nodeName: {node_name}

Pour afficher les EndpointSlices spécifiquement pour les points de terminaison actifs ou de sauvegarde, filtrez les résultats à l'aide du libellé pip-eps-role. Exemple :

kubectl get endpointslices --all-namespaces -l \
   networking.gke.io/pip-eps-role=ROLE \
  networking.gke.io/gkeiproute-name=GKEIPROUTE_NAME,

Remplacez les éléments suivants :

  • ROLE : type de point de terminaison que vous souhaitez afficher (active ou backup).
  • GKEIPROUTE_NAME : nom de votre objet GKEIPRoute spécifique.

Résoudre les problèmes d'équilibrage de charge basé sur la vérification de l'état

Cette section explique comment résoudre les problèmes liés à l'équilibrage de charge basé sur les vérifications de l'état de santé.

Certains pods actifs sont défectueux, mais les pods de sauvegarde ne reçoivent pas de trafic

Problème constaté

L'état GKEIPRoute affiche Ready, ce qui indique que la configuration de l'adresse IP pour les pods correspondants est terminée. Les vérifications de l'état ou d'autres diagnostics indiquent que certains pods actifs ne sont pas opérationnels. Toutefois, les pods de sauvegarde ne reçoivent pas de trafic.

Cause

Les pods de sauvegarde ne reçoivent pas de trafic tant que tous les pods actifs ne sont pas défectueux. D'ici là, tout le trafic est réparti entre les pods actifs et opérationnels restants.

Solution

Si nécessaire, modifiez les libellés du champ podSelector afin qu'ils ne correspondent plus à aucun pod actif. GKE achemine automatiquement le trafic vers le groupe de backends.

GKEIPRoute est configuré, mais tous les pods ne reçoivent pas de trafic

Problème constaté

L'état GKEIPRoute affiche Ready, ce qui indique que la configuration de l'adresse IP pour les pods correspondants est terminée, mais que certains pods correspondants ne reçoivent pas de trafic.

Cause

Les pods qui ne reçoivent pas de trafic ne sont peut-être pas opérationnels ou ne répondent peut-être pas correctement aux vérifications d'état. Notez que si tous les pods correspondants ne sont pas opérationnels, GKE répartit le trafic entre tous les pods, quel que soit leur état de fonctionnement.

Solution

  • Vérifiez que le pod est sain : utilisez la Google Cloud CLI ou la consoleGoogle Cloud pour vérifier que le pod répond correctement aux vérifications de l'état.
  • Approfondissez vos recherches si nécessaire : si le pod n'est pas opérationnel, vérifiez que vous avez correctement configuré les pare-feu pour les vérifications d'état et que votre pod répond.

Erreurs de configuration de l'équilibreur de charge non valides

Cette section vous aide à résoudre les erreurs d'état GKEIPRoute.

Backup pod and active pod are on the same node

Problème constaté

L'état de GKEIPRoute indique l'erreur suivante :

invalid LB configuration: Backup pod %s and active pod %s are on the same node %s. Active and backup pods must reside on different nodes.

Cause

Un pod actif et un pod de sauvegarde correspondant au même objet GKEIPRoute sont planifiés sur le même nœud. En d'autres termes, il existe des pods qui correspondent à la fois aux objets podSelector actifs et de sauvegarde sur le même nœud.

Solution

Assurez-vous que les pods actifs et de sauvegarde se trouvent sur des nœuds différents. Mettez à jour votre configuration GKEIPRoute et ajustez vos libellés podSelector ou backupPodSelector afin qu'aucun pod du même nœud ne corresponde au même objet GKEIPRoute.

Pod cannot be selected as both an active and a backup pod

Problème constaté

L'état de GKEIPRoute indique l'erreur suivante :

invalid LB configuration: pod %s cannot be selected as both an active and a backup pod. Active and backup pod sets must be mutually exclusive

Cause

Un ou plusieurs pods correspondent aux sélecteurs de libellés pour les champs podSelector (actif) et backupPodSelector (en veille). GKE exige que ces deux groupes s'excluent mutuellement. Un seul pod ne peut pas servir de sauvegarde pour lui-même.

Solution

Assurez-vous que vos pods actifs et de sauvegarde sont uniques. Modifiez le champ podSelector ou le champ backupPodSelector dans votre fichier manifeste GKEIPRoute pour utiliser des clés et des valeurs d'étiquette plus spécifiques ou distinctes.

État NoPodsFound

Problème constaté

Le fichier manifeste GKEIPRoute affiche l'état NoPodsFound, ce qui indique qu'aucun pod dans les espaces de noms ne possède d'étiquettes correspondantes.

Causes probables

  • Libellés incorrects : le pod avec lequel vous souhaitez utiliser l'adresse IP configurée peut présenter des libellés incorrects, voire aucun libellé.
  • Aucun pod n'existe : si reactionMode == Exists, vérifiez si le pod est attribué à un nœud en consultant le champ pod.Spec.nodeName. Il est possible qu'aucun pod ne s'exécute dans l'espace de noms de GKEIPRoute et ne corresponde au sélecteur.
  • Pods non prêts : si la valeur est reactionMode == ReadyCondition, vérifiez si l'état du pod est READY. Si un pod correspondant existe, mais qu'il n'est pas à l'état READY, il ne peut pas diffuser de trafic et n'est pas sélectionné.

Solution

  • Vérifier les étiquettes : assurez-vous que les étiquettes du champ podSelector de votre objet GKEIPRoute correspondent à celles que vous avez appliquées au pod prévu.
  • Vérifiez l'existence du pod : assurez-vous qu'un pod avec les libellés appropriés existe réellement dans les espaces de noms de l'objet GKEIPRoute spécifiés par les écouteurs de votre passerelle. Si l'état est reactionMode == Exists, vérifiez si le pod est attribué à un nœud en consultant le champ pod.Spec.nodeName.

  • Confirmer la disponibilité du pod : si la valeur est reactionMode == ReadyCondition, vérifiez si l'état du pod est READY. Assurez-vous que le pod est à l'état Ready à l'aide de la commande suivante :

    kubectl get pods -n NAMESPACE

    Les pods dans d'autres états (par exemple, Pending, Error) ne sont pas sélectionnés.

État Mutated lorsqu'un pod correspondant a été trouvé et que la programmation de l'adresse IP GKEIPRoute est en cours

Problème constaté

L'état GKEIPRoute affiche Mutated, ce qui indique que la configuration de l'adresse IP d'un pod correspondant est en cours.

Cause possible

Vous pouvez vous attendre à ce que l'état Mutated s'affiche pendant la configuration, lorsque le système configure le chemin de données GKE et les ressources Google Cloud pour l'adresse IP configurée.

Solution

  1. Attendez et réessayez : dans la plupart des cas, le processus de configuration se termine automatiquement en peu de temps. Vérifiez l'état après avoir attendu. Il passera à Ready en cas de succès.

  2. Effectuez des recherches supplémentaires (si nécessaire) : si l'état Mutated persiste pendant une longue période, cela peut indiquer une erreur de configuration. Examinez les autres conditions d'état de votre objet GKEIPRoute :

    • Accepté : indique si votre configuration GKEIPRoute est valide.
    • GCPReady : indique si les ressources Google Cloud sont configurées comme prévu.

Recherchez les messages d'erreur dans ces conditions pour résoudre le problème.

Étapes suivantes