Résoudre les problèmes de gestion des adresses IP dans les clusters de VPC

Cette page vous aide à résoudre les problèmes de gestion des adresses IP dans les clusters VPC de Google Kubernetes Engine (GKE).

Cette page explique aux administrateurs et opérateurs de plate-forme comment diagnostiquer et résoudre des problèmes tels que l'épuisement des adresses IP pour les nœuds et les pods, comment résoudre les erreurs de configuration réseau qui bloquent les opérations de cluster (comme les conflits de plages), comment gérer les plages CIDR d'adresses IP et comment configurer correctement des fonctionnalités telles que la SNAT par défaut, Cloud NAT et la mise en réseau double pile.

Cette page aide également les développeurs d'applications à comprendre comment les limites du réseau sous-jacent, telles que l'épuisement de l'espace d'adresses IP, peuvent avoir un impact sur leurs charges de travail, entraînant des problèmes tels que l'échec de la planification des pods. Bien que les développeurs ne configurent pas directement les VPC, la compréhension de ces problèmes courants les aide à mieux collaborer avec les administrateurs et opérateurs de plate-forme pour une résolution plus rapide. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenuGoogle Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Diagnostiquer l'épuisement des adresses IP

Si votre cluster manque d'adresses IP, la mise à l'échelle des nœuds peut être impossible et vos charges de travail peuvent être perturbées. Cette section explique comment utiliser la surveillance de l'utilisation des adresses IP dans GKE pour détecter et résoudre les problèmes potentiels d'épuisement.

GKE calcule l'utilisation des adresses IP à l'aide des données des insights Network Analyzer et d'autres sources de données GKE. Cette surveillance est disponible pour tous les clusters natifs du VPC.

Pour afficher l'utilisation des adresses IP d'un cluster, procédez comme suit :

  1. Dans la console Google Cloud , accédez à la page Clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Cliquez sur le nom du cluster que vous souhaitez examiner. Cette action ouvre la page Détails du cluster.

  3. Accédez à la page Utilisation des adresses IP à l'aide de l'une des méthodes suivantes :

    • Sélectionnez l'onglet Observabilité, puis cliquez sur Utilisation des adresses IP dans le menu de navigation de l'observabilité.

    • Dans la section Mise en réseau, recherchez la ligne Plage IPv4 des pods du cluster (par défaut), puis cliquez sur Afficher l'utilisation des adresses IP.

  4. Consultez la colonne État de l'attribution des adresses IP. Cette colonne indique le pourcentage d'adresses IP allouées dans la plage d'adresses IP de votre pod. GKE considère que toutes les adresses IP de la plage CIDR attribuée à un nœud sont allouées, que des adresses IP individuelles soient attribuées ou non à des pods. Cela signifie que le pourcentage reflète l'ensemble de la plage de pods pour un nœud, et pas seulement les adresses IP utilisées. Si des clusters partagent les mêmes plages d'adresses IP, le pourcentage d'utilisation affiché correspond à leur total combiné.

  5. Pour afficher en détail l'utilisation des adresses IP, y compris les plages CIDR, les informations sur les sous-réseaux et les recommandations, cliquez sur Afficher les détails.

Si votre utilisation d'adresses IP est élevée (proche de 100 %), envisagez les solutions suivantes pour éviter l'épuisement des adresses IP :

  • Ajoutez d'autres plages d'adresses IPv4 de pods à l'aide d'un CIDR multipods non contigu. Cette fonctionnalité vous permet d'ajouter des adresses IPv4 pour vos pods sans avoir à recréer votre cluster ni à configurer de nouveaux sous-réseaux.
  • Ajoutez des sous-réseaux avec des plages d'adresses IPv4 supplémentaires dans le cluster. Cette fonctionnalité permet aux nouveaux pools de nœuds d'utiliser les adresses IP des sous-réseaux nouvellement ajoutés.
  • Créez un cluster avec un nombre maximal de pods moins élevé. Cette approche réserve moins d'adresses IP pour chaque nœud, ce qui peut vous aider à gérer la consommation globale d'adresses IP dans la plage réseau de votre cluster. Pour en savoir plus, consultez Configurer le nombre maximal de pods par nœud.
  • Si vous ne disposez pas de suffisamment de plages d'adresses IP ou d'espace d'adressage RFC 1918, envisagez d'utiliser des plages non-RFC 1918 (y compris l'espace d'adressage de classe E).

Résoudre des problèmes de mise en réseau spécifiques

Les sections suivantes fournissent des conseils pour résoudre les problèmes liés aux clusters de VPC natif. Vous pouvez également consulter les insights sur l'utilisation des adresses IP GKE.

La ressource réseau par défaut n'est pas prête.

Symptômes

Un message d'erreur semblable à celui-ci s'affiche :

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default
Causes probables

Des opérations sont effectuées en parallèle sur le même sous-réseau. Par exemple, un autre cluster de VPC natif est en cours de création, ou une plage secondaire est en cours d'ajout ou de suppression sur le sous-réseau.

Solution

Relancez la commande.

Valeur incorrecte pour IPCidrRange

Symptômes

Un message d'erreur semblable à celui-ci s'affiche :

resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'
Causes probables

Un autre cluster de VPC natif est en cours de création simultanément et tente d'allouer les mêmes plages au sein du même réseau VPC.

La même plage secondaire est en cours d'ajout dans le sous-réseau du même réseau VPC.

Solution

Si cette erreur est renvoyée lors de la création du cluster alors qu'aucune plage secondaire n'a été spécifiée, relancez la commande de création du cluster.

Pas assez d'espace d'adresses IP libre pour les pods

Symptômes

Le cluster est bloqué dans un état de provisionnement pendant une période prolongée.

La création de cluster renvoie une erreur de groupe d'instances géré (MIG, Managed Instance Group).

Lorsque vous ajoutez un ou plusieurs nœuds à un cluster, l'erreur suivante s'affiche :

[IP_SPACE_EXHAUSTED] Instance 'INSTANCE_NAME' creation failed: IP space of 'projects/PROJECT_ID/regions/REGION/subnetworks/[SUBNET_NAME]-[SECONDARY_RANGE_NAME]-[HASH_8BYTES]' is exhausted. The secondary range name is in the format of 'gke-[CLUSTER_NAME]-[HASH_8BYTES]'.
Causes probables

Plage d'adresses IP de nœud épuisée : la plage d'adresses IP principale du sous-réseau attribué à votre cluster est à court d'adresses IP disponibles. Cela se produit généralement lors de l'ajustement de pools de nœuds ou de la création de clusters volumineux.

Plage d'adresses IP des pods épuisée : la plage CIDR des pods attribuée à votre cluster est pleine. Cela se produit lorsque le nombre de pods dépasse la capacité du CIDR de pod, en particulier avec une densité de pods élevée par nœud ou des déploiements importants.

Conventions de dénomination spécifiques des sous-réseaux : la façon dont un sous-réseau est nommé dans un message d'erreur peut vous aider à déterminer si le problème concerne la plage d'adresses IP des nœuds (où les nœuds eux-mêmes obtiennent leur adresse IP) ou la plage d'adresses IP des pods (où les conteneurs à l'intérieur des pods obtiennent leurs adresses IP).

Plage secondaire épuisée (Autopilot) : dans les clusters Autopilot, les plages secondaires attribuées aux adresses IP des pods sont épuisées en raison du scaling ou de la densité élevée des pods.

Solution

Rassemblez les informations suivantes sur votre cluster : nom, version du plan de contrôle, mode de fonctionnement, nom du VPC associé, nom du sous-réseau et CIDR. Notez également les plages IPv4 de pods de cluster par défaut et supplémentaires (y compris les noms et les CIDR), si l'acheminement du trafic natif du VPC est activé, et le nombre maximal de pods par nœud au niveau du cluster et du pool de nœuds (le cas échéant). Notez les pools de nœuds concernés, ainsi que leurs plages d'adresses IP IPv4 de pod et leurs configurations de nombre maximal de pods par nœud, s'ils diffèrent des paramètres du cluster. Enregistrez également les configurations par défaut et personnalisées (le cas échéant) pour le nombre maximal de pods par nœud dans la configuration du pool de nœuds.

Confirmer le problème d'épuisement des adresses IP

  • Network Intelligence Center : vérifiez les taux d'allocation d'adresses IP élevés dans les plages d'adresses IP de pods dans Network Intelligence Center pour votre cluster GKE.

    Si vous constatez un taux d'allocation d'adresses IP élevé dans les plages de pods dans Network Intelligence Center, cela signifie que votre plage d'adresses IP de pods est épuisée.

    Si les plages d'adresses IP du pod affichent des taux d'allocation normaux, mais que vous rencontrez toujours des problèmes d'épuisement des adresses IP, il est probable que votre plage d'adresses IP de nœuds soit épuisée.

  • Journaux d'audit : examinez le champ resourceName dans les entrées IP_SPACE_EXHAUSTED, en le comparant aux noms de sous-réseau ou aux noms de plage d'adresses IP de pod secondaire.

  • Vérifiez si la plage d'adresses IP épuisée est une plage d'adresses IP de nœud ou une plage d'adresses IP de pod.

    Pour vérifier si la plage d'adresses IP épuisée est une plage d'adresses IP de nœud ou une plage d'adresses IP de pod, vérifiez si la valeur de resourceName dans la partie ipSpaceExhausted d'une entrée de journal IP_SPACE_EXHAUSTED correspond au nom du sous-réseau ou au nom de la plage d'adresses IPv4 secondaire pour les pods utilisés dans le cluster GKE concerné.

    Si la valeur de resourceName est au format "[Nom_sous-réseau]", la plage d'adresses IP du nœud est épuisée. Si la valeur de resourceName est au format "[Nom_sous-réseau]-[Nom_plage_IPv4_secondaire_pour_pods]-[HASH_8BYTES]", cela signifie que la plage d'adresses IP des pods est épuisée.

Résoudre l'épuisement des adresses IP des pods :

  • Redimensionner la plage CIDR d'un pod existant : augmentez la taille de la plage d'adresses IP de pod actuelle. Vous pouvez ajouter des plages d'adresses IP de pods au cluster à l'aide d'un CIDR multipods non contigu.
  • Créer des sous-réseaux supplémentaires : ajoutez des sous-réseaux avec des CIDR de pods dédiés au cluster.

Réduisez le nombre de pods par nœud pour libérer des adresses IP :

Épuisement des adresses IP des nœuds d'adresse :

  • Vérifiez la planification des adresses IP : assurez-vous que la plage d'adresses IP des nœuds correspond à vos exigences de scaling.
  • Créer un cluster (si nécessaire) : si la plage d'adresses IP du nœud est fortement limitée, créez un cluster de remplacement avec une taille de plage d'adresses IP appropriée. Reportez-vous aux pages Plages d'adresses IP pour les clusters de VPC natif et Planifier des plages d'adresses IP.

Déboguer les problèmes d'épuisement des adresses IP avec gcpdiag

gcpdiag est un outil Open Source. Il ne s'agit pas d'un produit Google Cloud officiellement compatible. Vous pouvez utiliser l'outil gcpdiag pour vous aider à identifier et à résoudre les problèmes liés au projet Google Cloud. Pour en savoir plus, consultez le projet gcpdiag sur GitHub.

Pour examiner les causes de l'épuisement des adresses IP sur les clusters GKE Autopilot et Standard, tenez compte des points suivants :
  • État du cluster : vérifie l'état du cluster si l'épuisement de l'adresse IP est signalé.
  • Analyseur de réseau : interroge les journaux Stackdriver pour les journaux de l'Analyseur de réseau afin de vérifier si l'adresse IP du pod ou du nœud est épuisée.
  • Type de cluster : vérifie le type de cluster et fournit des recommandations pertinentes en fonction de ce type.

ConsoleGoogle Cloud

  1. Terminez l'exécution, puis copiez la commande suivante. 
    2. gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \
  2. Ouvrez la console Google Cloud et activez Cloud Shell.
    3. Ouvrir la console Cloud
  3. Collez la commande copiée.
  4. Exécutez la commande gcpdiag, qui télécharge l'image Docker gcpdiag, puis effectue des vérifications de diagnostic. Le cas échéant, suivez les instructions de sortie pour corriger les échecs de vérification.

Docker

Vous pouvez exécuter gcpdiag à l'aide d'un wrapper qui démarre gcpdiag dans un conteneur Docker. Docker ou Podman doivent être installés.

  1. Copiez et exécutez la commande suivante sur votre station de travail locale : 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Exécutez la commande gcpdiag. 
    ./gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \

Affichez les paramètres disponibles pour ce runbook.

Remplacez les éléments suivants :

  • PROJECT_ID : ID du projet contenant la ressource
  • CLUSTER_NAME : nom du cluster GKE cible dans votre projet.
  • LOCATION : zone ou région dans laquelle se trouve votre cluster.
  • start_time : heure à laquelle le problème a commencé.
  • end_time : heure à laquelle le problème s'est terminé. Définissez l'heure actuelle si le problème persiste.

Options utiles :

Pour obtenir la liste et la description de toutes les options de l'outil gcpdiag, consultez les instructions d'utilisation de gcpdiag.

Vérifier si la configuration SNAT par défaut est désactivée

Exécutez la commande suivante pour vérifier l'état de la configuration SNAT par défaut :

gcloud container clusters describe CLUSTER_NAME

Remplacez CLUSTER_NAME par le nom de votre cluster.

Le résultat ressemble à ce qui suit :

networkConfig:
  disableDefaultSnat: true
  network: ...

Impossible d'utiliser --disable-default-snat sans --enable-ip-alias

Ce message d'erreur, ainsi que le message must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster, signifient que vous devez définir explicitement l'option --disable-default-snat lors de la création du cluster, car vous utilisez des adresses IP publiques dans votre cluster privé.

Si des messages d'erreur tels que cannot disable default sNAT ... s'affichent, cela signifie que la configuration SNAT par défaut ne peut pas être désactivée dans votre cluster. Pour résoudre ce problème, examinez la configuration de votre cluster.

Déboguer Cloud NAT avec la configuration SNAT par défaut désactivée

Si un cluster privé a été créé avec l'option --disable-default-snat et que vous avez configuré Cloud NAT pour l'accès à Internet, mais que vous ne voyez pas de trafic Internet en provenance de vos pods, assurez-vous que la plage dédiée aux pods est comprise dans la configuration Cloud NAT.

En cas de problème de communication entre pods, examinez les règles iptables sur les nœuds afin de vous assurer que les plages dédiées aux pods ne sont pas masquées par celles-ci.

Pour en savoir plus, consultez la documentation sur l'IP masquerading de GKE.

Si vous n'avez pas configuré d'agent d'IP masquerading pour le cluster, GKE s'assure automatiquement que la communication entre pods n'est pas masquée. Toutefois, si un agent d'IP masquerading est configuré, il remplace les règles d'IP masquerading par défaut. Assurez-vous que des règles supplémentaires sont configurées dans l'agent d'IP masquerading pour ignorer le masquage des plages dédiées aux pods.

La communication réseau du cluster à double pile ne fonctionne pas comme prévu

Causes probables
Les règles de pare-feu créées par le cluster GKE n'incluent pas les adresses IPv6 allouées.
Solution
Vous pouvez valider la règle de pare-feu en procédant comme suit :

  1. Vérifiez le contenu de la règle de pare-feu :

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME

    Remplacez FIREWALL_RULE_NAME par le nom de la règle de pare-feu.

    Chaque cluster à double pile crée une règle de pare-feu permettant aux nœuds et aux pods de communiquer entre eux. Le contenu de la règle de pare-feu ressemble à ce qui suit :

    allowed:
- IPProtocol: esp
- IPProtocol: ah
- IPProtocol: sctp
- IPProtocol: tcp
- IPProtocol: udp
- IPProtocol: '58'
creationTimestamp: '2021-08-16T22:20:14.747-07:00'
description: ''
direction: INGRESS
disabled: false
enableLogging: false
id: '7326842601032055265'
kind: compute#firewall
logConfig:
  enable: false
name: gke-ipv6-4-3d8e9c78-ipv6-all
network: https://www.googleapis.com/compute/alpha/projects/my-project/global/networks/alphanet
priority: 1000
selfLink: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/gke-ipv6-4-3d8e9c78-ipv6-all
selfLinkWithId: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/7326842601032055265
sourceRanges:
- 2600:1900:4120:fabf::/64
targetTags:
- gke-ipv6-4-3d8e9c78-node

    La valeur sourceRanges doit être identique à celle de subnetIpv6CidrBlock. La valeur targetTags doit être identique aux tags des nœuds GKE. Pour résoudre ce problème, mettez à jour la règle de pare-feu avec les informations sur le bloc ipAllocationPolicy du cluster.

Étapes suivantes