Résoudre les problèmes liés à Cloud NAT

Ce guide vous aide à comprendre pourquoi vos charges de travail (pods ou VM) ne peuvent pas accéder aux réseaux externes à l'aide de Cloud NAT. En tant que développeur, vous interagissez principalement avec la ressource CloudNatGateway. L'état de cette ressource est votre principale source de référence pour le débogage.

Avant de commencer

Pour résoudre les problèmes de configuration Cloud NAT, vous devez disposer des éléments suivants :

Les rôles d'identité et d'accès nécessaires. Demandez à l'administrateur IAM de votre projet de vous attribuer l'un des rôles suivants, ou les deux :
- Lecteur Cloud NAT (cloud-nat-viewer) : ce rôle offre un accès en lecture seule aux ressources Cloud NAT. Ce rôle vous permet de commencer à diagnostiquer le problème.
- Développeur Cloud NAT (cloud-nat-developer) : ce rôle fournit les autorisations nécessaires aux opérateurs d'applications pour créer, lire, mettre à jour et supprimer des objets Cloud NAT dans les projets qui leur sont attribués. Ce rôle vous permet d'effectuer la plupart des corrections décrites sur cette page.
- Des rôles supplémentaires peuvent être nécessaires pour certaines mesures et corrections de diagnostic spécifiques.

Diagnostics initiaux

Avant de vous intéresser aux codes d'erreur, assurez-vous que les ressources de base sont présentes et accessibles.

Commande :

kubectl get cloudnatgateway GATEWAY_NAME -n PROJECT_NAMESPACE -o yaml

Remplacez les éléments suivants :

GATEWAY_NAME : nom de la ressource CloudNatGateway.
PROJECT_NAMESPACE : espace de noms de votre projet.

Vérifiez les conditions d'état : une passerelle saine doit avoir toutes les conditions suivantes définies sur True :

Ready : état de santé global.
SubnetsReady : la configuration du pool d'adresses IP est valide.
PerimeterConfigurationReady : l'infrastructure réseau en amont est configurée.
EgressRoutesReady : les règles de routage de vos pods sont actives.

Si l'un de ces champs est défini sur False, vérifiez les champs reason et message dans le résultat de l'état, puis consultez les tableaux des sections suivantes.

Référence et résolution des codes d'erreur

Les codes d'erreur renvoyés par kubectl get cloudnatgateway se répartissent en trois catégories principales.

Erreurs de sous-réseau (`SubnetsReady` est défini sur "False")

Cette condition indique des problèmes liés au pool d'adresses IP attribué à la passerelle.

Code d'erreur	Signification	Étapes de résolution
`CloudNATSelectorFieldOverlapsCode`	Conflit de configuration Le `workloadSelector` de cette passerelle correspond aux mêmes charges de travail qu'une autre passerelle de votre projet. Le trafic ne peut pas être routé de manière déterministe.	Répertoriez toutes les passerelles Cloud NAT de votre projet : `kubectl get cloudnatgateway` Comparez le `workloadSelector` de cette passerelle à celui des autres. Modifiez les libellés de sorte qu'aucun pod ni aucune VM ne soit sélectionné par plusieurs passerelles.
`CloudNATSubnetRefsFieldInvalidCode`	Sous-réseau non valide. Le sous-réseau spécifié dans `subnetRefs` est inutilisable. Raisons courantes : Le sous-réseau n'existe pas. Le sous-réseau n'est pas à l'état `Ready`. Le sous-réseau n'est pas de type `Leaf`.	Vérifiez que le sous-réseau existe : `kubectl get subnet <SUBNET_NAME>` Vérifiez que l'état du sous-réseau est `Ready`. Assurez-vous que le sous-réseau `type` est `Leaf` (Cloud NAT ne peut pas utiliser les sous-réseaux racine ni de bouclage).
`CloudNATSubnetAlreadyInUseCode`	Conflit de sous-réseau. Le sous-réseau que vous avez demandé est déjà "possédé" par une autre passerelle Cloud NAT. Un sous-réseau ne peut être associé qu'à une seule passerelle à la fois.	Choisissez un autre sous-réseau pour cette passerelle. Vous pouvez également supprimer d'abord le sous-réseau de l'autre passerelle.
`UNETAPIServerErrorCode`	Erreur système. Le contrôleur ne peut pas communiquer avec le serveur d'API pour valider les sous-réseaux.	Action : il s'agit probablement d'un problème temporaire lié à la plate-forme. Si le problème persiste, contactez votre administrateur de plate-forme.

Erreurs de configuration du périmètre (`PerimeterConfigurationReady` est défini sur "False")

Cette condition reflète l'état des passerelles de périmètre.

Code d'erreur	Signification	Étapes de résolution
`NET-E0305`	Conflit de configuration (voir ci-dessus) Les sélecteurs qui se chevauchent empêchent le système de calculer le bon groupe de routage.	Répertoriez toutes les passerelles Cloud NAT de votre projet : `kubectl get cloudnatgateway` Comparez le `workloadSelector` de cette passerelle à celui des autres. Modifiez les libellés de sorte qu'aucun pod ni aucune VM ne soit sélectionné par plusieurs passerelles.
`NET-E0301`	Épuisement des ressources / Défaillance des nœuds Le système a créé la configuration, mais n'a pas pu attribuer vos adresses IP de sortie à un nœud physique opérationnel. Cela signifie généralement que le sous-réseau n'a plus d'adresses IP ou que les nœuds de passerelle sont hors service.	Vérifiez votre utilisation du [sous-réseau](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/subnets-overview). Est-ce qu'il est plein ? Si le sous-réseau dispose d'adresses IP libres et est `Ready`, cela indique un échec de l'infrastructure côté plate-forme (par exemple, aucun nœud de passerelle opérationnel n'est disponible). Action : contactez l'administrateur de la plate-forme.
`NET-E0001`	Erreur système. Échec de la communication avec la manette.	Action : Contactez l'administrateur de la plate-forme.

Erreurs d'itinéraire de sortie (`EgressRoutesReady` est défini sur "False")

Cette condition reflète l'état des règles de routage dans le cluster.

Code d'erreur Signification Étapes de résolution

Code d'erreur	Signification	Étapes de résolution
`NET-E0305`	Conflit de configuration (voir ci-dessus)	Répertoriez toutes les passerelles Cloud NAT de votre projet : `kubectl get cloudnatgateway` Comparez le `workloadSelector` de cette passerelle à celui des autres. Modifiez les libellés de sorte qu'aucun pod ni aucune VM ne soit sélectionné par plusieurs passerelles.
`NET-E0304`	Échec de la programmation. Le système n'a pas réussi à programmer les règles de routage (BPF) pour vos adresses IP de passerelle spécifiques.	Action : il s'agit d'une erreur de programmation interne ou d'une incohérence d'état. Essayez de modifier légèrement la passerelle (par exemple, en modifiant un libellé) pour déclencher une réconciliation. Si le problème persiste, contactez l'administrateur de la plate-forme.

NET-E0305

Conflit de configuration (voir ci-dessus)

Répertoriez toutes les passerelles Cloud NAT de votre projet : kubectl get cloudnatgateway
Comparez le workloadSelector de cette passerelle à celui des autres.
Modifiez les libellés de sorte qu'aucun pod ni aucune VM ne soit sélectionné par plusieurs passerelles.

NET-E0304

Échec de la programmation. Le système n'a pas réussi à programmer les règles de routage (BPF) pour vos adresses IP de passerelle spécifiques.

Action : il s'agit d'une erreur de programmation interne ou d'une incohérence d'état.

Essayez de modifier légèrement la passerelle (par exemple, en modifiant un libellé) pour déclencher une réconciliation.
Si le problème persiste, contactez l'administrateur de la plate-forme.

Autres problèmes courants

Si l'état de la passerelle est Ready: True, mais que le trafic échoue toujours, vérifiez les erreurs de configuration courantes suivantes :

Autorisation manquante au niveau du projet

Votre projet doit être explicitement autorisé à faire sortir du trafic.

Vérification : Votre ressource de projet comporte-t-elle le libellé networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true" ?
Solution : Demandez à votre administrateur de projet d'appliquer ce libellé.

Annotation de VM manquante (machines virtuelles uniquement)

Les VM contournent le chemin de sortie des pods standards et ont besoin d'instructions explicites pour utiliser Cloud NAT.

Vérification : l'objet VirtualMachineExternalAccess (VMEA) de votre VM comporte-t-il l'annotation egress.networking.gke.io/use-cloud-nat: "true" ?
Correction : ajoutez l'annotation à l'objet VMEA.

Sortie des nœuds de cluster standard

Si vous exécutez un cluster Standard, les nœuds eux-mêmes ont besoin d'une autorisation pour la sortie.

Vérification : l'objet Cluster porte-t-il le libellé cluster.gdc.goog/enable-node-egress-to-outside-the-org: "true" ?
Solution : Demandez à votre administrateur de plate-forme de libeller l'objet Cluster.

Conflit entre la fonctionnalité NAT de sortie par défaut et Cloud NAT

Une erreur de configuration courante se produit lorsqu'une charge de travail est configurée pour utiliser l'ancien mécanisme NAT de sortie par défaut tout en étant sélectionnée par une passerelle Cloud NAT. Cette combinaison entraîne une collision dans laquelle le plan de données reçoit des instructions de routage contradictoires, ce qui entraîne une perte de paquets ou un comportement de routage non déterministe.

Diagnostiquer les collisions de pods

Pour les pods, le NAT de sortie par défaut est généralement activé en ajoutant un libellé spécifique. Un pod ne peut pas avoir ce libellé s'il est également ciblé par une passerelle Cloud NAT.

Identifiez le pod cible : obtenez les libellés du pod qui rencontre des problèmes de connectivité.
```
kubectl get pod <POD_NAME> -n <NAMESPACE> --show-labels
```
Vérifiez si des libellés sont en conflit :
- Sélection Cloud NAT : les libellés du pod correspondent-ils à l'workloadSelector d'un CloudNatGateway dans l'espace de noms ?
- Libellé de sortie par défaut : le pod possède-t-il le libellé egress.networking.gke.io/enabled: "true" ?
Condition : si BOTH est défini sur "true", cela signifie qu'il y a un chevauchement.
Résolution : supprimez l'ancienne étiquette de sortie par défaut du pod (ou de son déploiement/StatefulSet parent) pour permettre à Cloud NAT de prendre le contrôle exclusif.

Diagnostiquer les collisions de VM

Pour les machines virtuelles, le mécanisme est différent. Les VM avec des objets VirtualMachineExternalAccess (VMEA) sont souvent configurées pour un accès par défaut. Pour utiliser Cloud NAT, ils doivent l'activer explicitement en ajoutant une annotation pour désactiver le chemin par défaut et activer le chemin Cloud NAT.

Identifiez le VMEA : recherchez l'objet VirtualMachineExternalAccess associé à la VM.
```
kubectl get vmea -n <NAMESPACE>
```
Vérifier si des annotations sont manquantes :
- Sélection de Cloud NAT : les libellés de la VM correspondent-ils à un CloudNatGateway ?
- Annotation d'activation : consultez le VMEA pour l'annotation egress.networking.gke.io/use-cloud-nat: "true".
Condition : si la VM correspond à une passerelle, mais NE POSSÈDE PAS cette annotation, le trafic entrera en conflit avec le système de sortie par défaut.

Résolution : ajoutez l'annotation à l'objet VMEA.

kubectl annotate vmea <VMEA_NAME> -n <NAMESPACE> egress.networking.gke.io/use-cloud-nat="true"

Résoudre les problèmes liés à Cloud NAT Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.