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

Une gestion efficace des adresses IP est essentielle pour la stabilité et l'évolutivité des clusters de VPC natif Google Kubernetes Engine (GKE). Les problèmes peuvent empêcher le scaling ou entraîner des défaillances de la charge de travail, par exemple l'échec de la planification des pods.

Ce document vous aidera à résoudre les problèmes liés à l'allocation d'adresses IP, à la stabilité du réseau et aux fonctionnalités de mise en réseau avancées dans les clusters GKE de VPC natif.

Ces informations sont principalement destinées aux administrateurs et aux opérateurs de plate-forme qui gèrent l'infrastructure réseau du cluster. Il aide également les développeurs d'applications à comprendre comment les limites du réseau sous-jacent, telles que l'épuisement de l'espace d'adressage IP, peuvent affecter leurs charges de travail. Même si les développeurs ne configurent pas directement les VPC, comprendre ces problèmes courants les aide à mieux collaborer avec les administrateurs et les opérateurs de la plate-forme pour les résoudre plus rapidement. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Diagnostiquer l'épuisement des adresses IP

Le manque d'adresses IP dans votre cluster peut empêcher le scaling des nœuds et perturber vos charges de travail. Cette section explique comment utiliser la surveillance de l'utilisation des adresses IP dans GKE pour détecter et résoudre les problèmes d'épuisement potentiels.

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

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, dans le menu de navigation de l'observabilité, cliquez sur Utilisation des adresses IP.

    • 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 aux pods. Cela signifie que le pourcentage reflète l'intégralité de la plage de pods d'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 affiche leur total combiné.

  5. Pour obtenir une vue détaillée de 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 l'utilisation de vos adresses IP est élevée (proche de 100 %), envisagez les solutions suivantes pour éviter l'épuisement des adresses IP :

  • Ajoutez des plages d'adresses IPv4 de pod supplémentaires en utilisant un CIDR multipod 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 récemment 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).

Comprendre le calcul de l'allocation CIDR des pods GKE

Une source de confusion courante est que GKE n'alloue pas de manière dynamique les adresses IP de pods individuels à partir d'un pool central à la demande. Au lieu de cela, lorsqu'un nouveau nœud rejoint votre cluster, GKE extrait un bloc CIDR contigu de la plage de pods secondaire du sous-réseau et l'attribue exclusivement à ce nœud.

Pour éviter les conflits de recyclage d'adresses IP lors des déploiements rapides de pods, GKE alloue une taille de bloc par nœud égale au plus petit bloc de puissance de deux contenant au moins 2 × le nombre maximal de pods par nœud :

Per-node Pod CIDR block size (addresses) = 2^(ceil(log2(2 * max_pods_per_node)))
  • Configuration par défaut (--max-pods-per-node=110) : nécessite au moins 2 × 110 = 220 adresses. La puissance de deux la plus proche est 256 adresses, ce qui attribue un bloc /24 (256 adresses IP) à chaque nœud.
  • Impact sur la capacité des nœuds du cluster : étant donné que chaque nœud consomme un bloc /24 (256 adresses IP de pod), quel que soit le nombre de pods exécutés sur ce nœud, le nombre maximal de nœuds compatibles avec une plage de pods secondaire dépend directement de votre paramètre --max-pods-per-node :
Nombre maximal de pods par nœud Bloc alloué par nœud Nombre maximal de nœuds par plage de pods /19 (8 192 adresses IP) Nombre maximal de nœuds par plage de pods /16 (65 536 adresses IP)
110 (par défaut) /24 (256 adresses IP) 32 nœuds 256 nœuds
64 /25 (128 adresses IP) 64 nœuds 512 nœuds
32 (par défaut pour Autopilot) /26 (64 adresses IP) 128 nœuds 1 024 nœuds
16 /27 (32 adresses IP) 256 nœuds 2 048 nœuds
8 /28 (16 adresses IP) 512 nœuds 4 096 nœuds

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.

Nombre de nœuds initial élevé dans les pools de nœuds réduits : GKE réserve des adresses IP pour les Pods en fonction de la capacité initiale que vous avez demandée lors de la création d'un pool de nœuds. Si vous créez un pool de nœuds avec un initial_node_count élevé, puis que vous réduisez le nombre de nœuds, GKE continue de réserver de l'espace d'adressage IP en fonction de la valeur la plus élevée entre le initial_node_count du pool de nœuds et le nombre actuel de nœuds dans le pool de nœuds. Cette situation peut entraîner un état dans lequel le cluster signale l'épuisement des adresses IP, même si le nombre actuel de nœuds actifs est faible.

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.

Commandes de diagnostic supplémentaires et playbooks de résolution non perturbateurs

Pour accélérer le dépannage et résoudre l'épuisement des adresses IP tout en minimisant les temps d'arrêt du cluster, appliquez les playbooks de diagnostic et d'exploitation suivants :

1. Bisection en ligne de commande à l'aide de Cloud Logging et de l'outil de recommandation

Pour identifier les problèmes d'épuisement des adresses IP à partir de la ligne de commande, procédez comme suit :

  • Interrogez Cloud Logging pour détecter les événements d'épuisement explicite des adresses IP : logquery resource.type="k8s_cluster" logName:"logs/container.googleapis.com" ("IP_SPACE_EXHAUSTED" OR "ran out of IPs" OR "wouldn't fit if a new node is added")
  • Interrogez l'API Recommender pour obtenir des insights Network Analyzer automatisés (utilisation supérieure à 80 %) : sh gcloud recommender insights list \ --insight-type=google.networkanalyzer.container.ipAddressInsight \ --project=PROJECT_ID --location=GLOBAL
2. Extension de sous-réseau principal en direct (pour l'épuisement des adresses IP principales des nœuds)

Contrairement aux plages secondaires, vous pouvez étendre la plage d'adresses IP hôtes principale d'un sous-réseau en direct dans Compute Engine sans recréer de clusters ni perturber les charges de travail :

gcloud compute networks subnets expand-ip-range SUBNET_NAME \
    --region=REGION \
    --prefix-length=NEW_PREFIX_LENGTH

Par exemple, l'extension d'un sous-réseau principal de /24 à /22 augmente la capacité d'adresses IP de l'hôte de VM principal de 252 à 1 020 nœuds de VM.

3. Playbook de migration de pool de nœuds bleu-vert (pour l'épuisement des adresses IP de pod)

Si un pool de nœuds existant est verrouillé sur de petites plages secondaires ou sur l'allocation d'adresses IP volumineuse de la configuration par défaut --max-pods-per-node=110, migrez les charges de travail vers un nouveau pool de nœuds avec des CIDR de taille appropriée :

# Step 1: Add a new secondary IPv4 range to your subnet
gcloud compute networks subnets update SUBNET_NAME \
    --region=REGION \
    --add-secondary-ranges=NEW_SECONDARY_RANGE_NAME=NEW_CIDR

# Step 2: Register the new Pod range with your GKE cluster
gcloud container clusters update CLUSTER_NAME \
    --region=REGION \
    --additional-pod-ipv4-ranges=NEW_SECONDARY_RANGE_NAME

# Step 3: Launch a replacement node pool with right-sized --max-pods-per-node
gcloud container node-pools create pool-blue-v2 \
    --cluster=CLUSTER_NAME \
    --region=REGION \
    --max-pods-per-node=32 \
    --pod-ipv4-range=NEW_SECONDARY_RANGE_NAME \
    --enable-autoscaling --min-nodes=2 --max-nodes=60

# Step 4: Gracefully cordon and drain old nodes
kubectl cordon -l cloud.google.com/gke-nodepool=OLD_POOL_NAME
kubectl drain -l cloud.google.com/gke-nodepool=OLD_POOL_NAME --ignore-daemonsets --delete-emptydir-data --force --grace-period=300

# Step 5: Delete old node pool after workloads migrate
gcloud container node-pools delete OLD_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --region=REGION
4. Conception de plage de classe E (240.0.0.0/4) avec IP masquerading

Si votre réseau d'entreprise manque d'espace d'adressage RFC 1918, allouez des blocs IPv4 de classe E (240.0.0.0/4) à vos plages de pods secondaires (ces blocs fournissent plus de 268 millions d'adresses). Activez l'agent de masquage d'adresses IP GKE afin que le trafic de sortie vers les bases de données sur site ou d'autres points de terminaison du réseau existants soit masqué à l'aide de l'adresse d'hôte RFC 1918 principale du nœud.

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 pris en charge. 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.

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