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'adresse IP persistante standard mappent une seule adresse IP persistante à un seul pod, l'équilibrage de charge basé sur les vérifications de l'état vous permet de répartir le trafic d'une ou plusieurs adresses IP persistantes sur un pool de pods sains.

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 d'état régionales, GKE surveille vos charges de travail au niveau du 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 ne route le trafic vers ces pods de secours que si tous les pods actifs principaux échouent à leur vérification de l'état.

Conditions requises et limites

  • Pour utiliser l'équilibrage de charge basé sur les vérifications de l'état, votre cluster doit être sur 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 seul objet GKEIPRoute est compatible avec 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 le plus récemment créé 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
  • Si vous souhaitez utiliser la Google Cloud CLI pour cette tâche, installez et 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ésume le workflow permettant d'implémenter l'équilibrage de charge basé sur la vérification de l'é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 les vérifications de l'état.
  3. Réservez une adresse IP : sélectionnez et réservez une adresse IP interne ou externe statique dans la même région que votre cluster. Cette adresse sert de point d'entrée persistant que GKE distribue à 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 de libellés. 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ées 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éez 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 de 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 que les vérifications d'état provenant de Google Cloud puissent 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éserver 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 des 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 correctement acheminé au sein de votre réseau privé, les adresses IP internes doivent appartenir au sous-réseau par défaut du cluster ou à un 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 bien le 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 sont compatibles qu'avec 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 correspondant à 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 effectue une recherche pour trouver 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 vide ou omis, 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 libellés doivent être distincts de ceux utilisés 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 doit disposer d'autorisations privilégiées.

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

  • Modifier le 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 alors 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 (fonctionnalité avancée).

  • 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 à l'aide de 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 définissez cette valeur sur "2", vous vous assurez que des annonces ARP sont effectuées 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 distribution 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.

Le résultat suivant 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 liés à l'équilibrage de charge basé sur les vérifications de l'état

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

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 des 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 opérationnels. 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 des champs 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 des pods correspondants ne reçoivent pas de trafic.

Cause

Il est possible que les pods qui ne reçoivent pas de trafic ne soient pas opérationnels ou ne répondent pas correctement aux vérifications d'état. Notez que si tous les pods correspondants ne sont pas opérationnels, GKE répartit le trafic sur tous les pods, quel que soit leur état.

Solution

  • Vérifiez que le pod est en bon état : utilisez la Google Cloud CLI ou la consoleGoogle Cloud pour vérifier que le pod répond correctement aux vérifications de l'état.
  • Effectuez des investigations supplémentaires 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 d'équilibreur de charge non valide

Cette section vous aide à résoudre les problèmes liés à l'état GKEIPRoute.

Backup pod and active pod are on the same node

Problème constaté

L'état GKEIPRoute signale 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, des pods correspondent 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 sur le 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 GKEIPRoute signale 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.

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 de libellé 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 la 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érifiez les libellés : assurez-vous que les libellés du champ podSelector de votre objet GKEIPRoute correspondent à ceux que vous avez appliqués au pod prévu.
  • Vérifiez l'existence du pod : assurez-vous qu'un pod avec les bons libellé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 investigations supplémentaires (si nécessaire) : si l'état Mutated persiste pendant une période prolongée, 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