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

Cette section fournit 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' is exhausted.
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 faisant l'objet d'une assistance officielle. Vous pouvez utiliser l'outil gcpdiag pour vous aider à identifier et à résoudre les problèmes liés au projet Google Cloud. Pour plus d'informations, 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.

console Google Cloud

  1. Terminez l'exécution, puis copiez la commande suivante. 
    2. gcpdiag runbook gke/ip-exhaustion --project=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 --project=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.

Le point de terminaison Private Service Connect peut être endommagé lors de la suppression du cluster

Symptômes

Vous ne pouvez pas voir de point de terminaison connecté sous Private Service Connect dans votre cluster basé sur Private Service Connect.

Vous ne pouvez pas supprimer le sous-réseau ou le réseau VPC sur lequel le point de terminaison est alloué à Private Service Connect. Un message d'erreur semblable à celui-ci s'affiche :

projects/<PROJECT_ID>/regions/<REGION>/subnetworks/<SUBNET_NAME> is already being used by projects/<PROJECT_ID>/regions/<REGION>/addresses/gk3-<ID>
Causes probables

Sur les clusters GKE qui utilisent Private Service Connect, GKE déploie un point de terminaison Private Service Connect à l'aide d'une règle de transfert qui alloue une adresse IP interne pour accéder au plan de contrôle du cluster dans le réseau d'un plan de contrôle. Pour protéger la communication entre le plan de contrôle et les nœuds à l'aide de Private Service Connect, GKE maintient le point de terminaison invisible. Vous ne pouvez pas le voir dans la console Google Cloud ni dans gcloud CLI.

Solution

Pour éviter que le point de terminaison Private Service Connect ne soit divulgué avant la suppression du cluster, procédez comme suit :

  1. Attribuez le rôle Kubernetes Engine Service Agent role au compte de service GKE.
  2. Assurez-vous que les autorisations compute.forwardingRules.* et compute.addresses.* ne sont pas explicitement refusées par le compte de service GKE.

Si vous constatez une fuite du point de terminaison Private Service Connect, contactez l'assistance.

Étape suivante

  • Pour obtenir des informations générales sur l'analyse des problèmes de DNS de Kubernetes, consultez la section Déboguer la résolution DNS.