Résoudre les problèmes de perte de paquets Cloud NAT à partir d'un cluster

Dans les clusters Google Kubernetes Engine (GKE) natifs du VPC, les nœuds sans adresse IP externe renforcent la sécurité. Ces nœuds utilisent Cloud NAT pour les connexions Internet sortantes. Une perte de paquets peut se produire si une VM de nœud épuise ses ports et adresses IP Cloud NAT alloués, souvent en cas de charge de sortie élevée, ce qui perturbe le trafic de sortie.

Ce document vous explique comment consigner et surveiller les paquets supprimés, examiner votre configuration Cloud NAT et mettre en œuvre des mesures pour réduire les pertes de paquets à l'avenir.

Ces informations sont importantes pour les administrateurs et opérateurs de plate-forme, ainsi que pour les administrateurs réseau qui gèrent des clusters GKE avec des nœuds sans accès à Internet et qui s'appuient sur Cloud NAT pour la connectivité externe. 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 la perte de paquets

Les sections suivantes expliquent comment consigner les paquets supprimés à l'aide de Cloud Logging et diagnostiquer la cause de ces paquets supprimés à l'aide de Cloud Monitoring.

Enregistrer les paquets supprimés dans le journal

Vous pouvez consigner les paquets supprimés à l'aide de la requête suivante dans Cloud Logging:

resource.type="nat_gateway"
resource.labels.region=REGION
resource.labels.gateway_name=GATEWAY_NAME
jsonPayload.allocation_status="DROPPED"

Remplacez les éléments suivants :

  • REGION: nom de la région dans laquelle se trouve le cluster
  • GATEWAY_NAME: nom de la passerelle Cloud NAT.

Cette commande renvoie la liste de tous les paquets supprimés par une passerelle Cloud NAT, mais n'identifie pas la cause.

Surveiller les causes de perte de paquets

Pour identifier les causes des paquets supprimés, interrogez l'observateur de métriques dans Cloud Monitoring. Les paquets sont supprimés pour l'une des trois raisons suivantes:

  • OUT_OF_RESOURCES
  • ENDPOINT_INDEPENDENT_CONFLICT
  • NAT_ALLOCATION_FAILED

Pour identifier les paquets supprimés en raison de codes d'erreur OUT_OF_RESOURCES ou ENDPOINT_ALLOCATION_FAILED, utilisez la requête suivante:

fetch nat_gateway
  metric 'router.googleapis.com/nat/dropped_sent_packets_count'
  filter (resource.gateway_name == GATEWAY_NAME)
  align rate(1m)
  every 1m
  group_by [metric.reason],
    [value_dropped_sent_packets_count_aggregate:
       aggregate(value.dropped_sent_packets_count)]

Si vous identifiez des paquets supprimés pour ces raisons, consultez Paquets supprimés avec le motif "ressources épuisées" et Paquets supprimés avec un motif : conflit indépendant du point de terminaison pour obtenir des conseils de dépannage.

Pour identifier les paquets supprimés en raison du code d'erreur NAT_ALLOCATION_FAILED, utilisez la requête suivante :

fetch nat_gateway
  metric 'router.googleapis.com/nat/nat_allocation_failed'
  group_by 1m,
    [value_nat_allocation_failed_count_true:
       count_true(value.nat_allocation_failed)]
  every 1m

Si vous identifiez des paquets supprimés pour cette raison, consultez Vous devez allouer plus d'adresses IP.

Examiner la configuration Cloud NAT

Si les requêtes précédentes renvoient des résultats vides et que les pods GKE ne parviennent pas à communiquer avec des adresses IP externes, utilisez le tableau suivant pour vous aider à résoudre les problèmes de votre configuration :

Configuration Dépannage
Cloud NAT configuré pour s'appliquer uniquement à la plage d'adresses IP principale du sous-réseau. Lorsque Cloud NAT est configuré uniquement pour la plage d'adresses IP principale du sous-réseau, les paquets envoyés depuis le cluster vers des adresses IP externes doivent disposer d'une adresse IP de nœud source. Dans cette configuration Cloud NAT :
  • Les pods peuvent envoyer des paquets aux adresses IP externes si ces destinations d'adresses IP externes sont soumises au masquage d'adresses IP. Lors du déploiement de ip-masq-agent, vérifiez que la liste nonMasqueradeCIDRs ne contient pas l'adresse IP et le port de destination. Les paquets envoyés à ces destinations sont d'abord convertis en adresses IP des nœuds sources avant d'être traités par Cloud NAT.
  • Pour autoriser les pods à se connecter à toutes les adresses IP externes avec cette configuration Cloud NAT, assurez-vous que ip-masq-agent est déployé et que la liste nonMasqueradeCIDRs ne contient que les plages d'adresses IP de nœud et de pod du cluster. Les paquets envoyés à des destinations extérieures au cluster sont d'abord convertis en adresses IP de nœuds sources avant d'être traités par Cloud NAT.
  • Pour empêcher les pods d'envoyer des paquets à certaines adresses IP externes, vous devez bloquer explicitement ces adresses pour qu'elles ne soient pas masquées. Une fois le ip-masq-agent déployé, ajoutez les adresses IP externes que vous souhaitez bloquer à la liste nonMasqueradeCIDRs. Les paquets envoyés à ces destinations quittent le nœud avec leur source d'adresse IP de pod d'origine. Les adresses IP des pods proviennent d'une plage d'adresses IP secondaire du sous-réseau du cluster. Dans cette configuration, Cloud NAT ne fonctionnera pas sur cette plage secondaire.
Cloud NAT configuré pour s'appliquer uniquement à la plage d'adresses IP secondaire du sous-réseau utilisée pour les adresses IP des pods.

Lorsque Cloud NAT est configuré uniquement pour la plage d'adresses IP secondaire du sous-réseau utilisée par les adresses IP des pods du cluster, les paquets envoyés depuis le cluster vers les adresses IP externes doivent disposer d'une adresse IP de pod source. Dans cette configuration Cloud NAT:

  • L'utilisation d'un agent de masquage d'adresses IP entraîne la perte de l'adresse IP du pod source des paquets lorsqu'elle est traitée par Cloud NAT. Pour conserver l'adresse IP du pod source, spécifiez des plages d'adresses IP de destination dans une liste nonMasqueradeCIDRs. Avec le ip-masq-agent déployé, tous les paquets envoyés aux destinations de la liste nonMasqueradeCIDRs conservent leurs adresses IP de pods sources avant d'être traités par Cloud NAT.
  • Pour autoriser les pods à se connecter à toutes les adresses IP externes avec cette configuration Cloud NAT, assurez-vous que ip-masq-agent est déployé et que la liste nonMasqueradeCIDRs est aussi grande que possible (0.0.0.0/0 spécifie toutes les destinations d'adresses IP). Les paquets envoyés à toutes les destinations conservent les adresses IP des pods sources avant d'être traités par Cloud NAT.

Réduire la perte de paquets

Après avoir diagnostiqué la cause de la perte de paquets, appliquez les recommandations suivantes pour réduire la probabilité que le problème se reproduise à l'avenir :

  • Configurer la passerelle Cloud NAT pour qu'elle utilise l'allocation de ports dynamique et augmentez le nombre maximal de ports par VM.

  • Si vous utilisez l'allocation de ports statique, augmentez le nombre minimal de ports par VM.

  • Réduisez le débit de paquets sortant de votre application. Lorsqu'une application établit plusieurs connexions sortantes vers la même adresse IP et le même port de destination, elle peut rapidement utiliser toutes les connexions que Cloud NAT peut établir vers cette destination en utilisant le nombre de tuples d'adresses sources NAT allouées et de ports sources.

    Pour plus d'informations sur la manière dont Cloud NAT utilise les adresses sources et les ports sources NAT pour établir des connexions, y compris les limites du nombre de connexions simultanées à une destination, consultez la page Ports et connexions.

    Pour réduire le taux de connexions sortantes de l'application, réutilisez les connexions ouvertes. Les méthodes courantes de réutilisation des connexions incluent le regroupement de connexions, le multiplexage de connexions à l'aide de protocoles tels que HTTP/2 ou l'établissement de connexions persistantes réutilisées pour plusieurs requêtes. Pour plus d'informations, consultez la section Ports et connexions.

Étapes suivantes