Google Distributed Cloud (GDC) sous air gap est compatible avec les clusters standards, un cluster Kubernetes en libre-service à projet unique géré par le groupe d'opérateurs d'applications qui offre une plus grande flexibilité pour les charges de travail personnalisées. Cette page explique comment configurer Cloud NAT pour les clusters standards. Elle décrit également certaines contraintes et limites concernant les configurations NAT pour ce type de cluster.
Avant de commencer
Avant de configurer une passerelle, vous devez obtenir les autorisations IAM (Identity and Access Management) appropriées, vous assurer que votre projet dispose d'une stratégie réseau appropriée et activer le trafic sortant.
Pour en savoir plus, consultez Avant de commencer à utiliser Cloud NAT.
La passerelle Cloud NAT utilise des sous-réseaux leaf externes comme entrées. Pour en savoir plus sur la configuration des sous-réseaux externes pour Cloud NAT, consultez Créer des sous-réseaux externes pour Cloud NAT.
Présentation
Les passerelles Cloud NAT peuvent être configurées pour gérer le trafic de sortie des charges de travail exécutées sur des clusters standards de deux manières :
- Passerelle à portée de projet : passerelle qui s'applique à tout le trafic de charge de travail sur les clusters d'un projet, y compris tous les clusters partagés et standards. Il s'agit de la configuration décrite dans Créer une passerelle Cloud NAT.
- Passerelle à portée de cluster : passerelle qui ne s'applique qu'aux charges de travail d'un seul cluster standard spécifié. Il s'agit du type de passerelle présenté sur cette page.
Ces deux méthodes sont exclusivement réservées aux charges de travail et ne s'appliquent pas aux nœuds qui composent un cluster standard. Pour activer Cloud NAT pour les nœuds qui forment un cluster standard, ajoutez le libellé cluster.gdc.goog/enable-node-egress-to-outside-the-org: "true" à l'objet de cluster standard.
Créer la passerelle Cloud NAT
La procédure de création d'une passerelle pour un cluster standard reste la même que pour toute passerelle Cloud NAT de portée projet.
Dans ce cas, nous nous concentrons sur la fonctionnalité de filtrage des clusters pour Cloud NAT de cluster standard et créons une configuration semblable au premier scénario, mais en spécifiant le nom du cluster standard user-vc-1 où se trouvent les points de terminaison qui achemineront le trafic via la passerelle. Par conséquent, cette passerelle sera limitée à ce cluster spécifique.
apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
namespace: project-1
name: gateway-1
spec:
workloadSelector: # Immutable
labelSelector:
workloads:
matchLabels:
app: aa
clusters:
matchLabels:
kubernetes.io/metadata.name: user-vc-1
subnetRefs: # Mutable
- subnet-1
- subnet-2
Cette configuration sélectionnera toutes les charges de travail portant le libellé app: aa dans tous les espaces de noms du cluster standard user-vc-1.
Vérifier l'état de la passerelle
Vérifiez l'état des passerelles en exécutant la commande kubectl suivante.
export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
kubectl get cloudnatgateways gateway-1 -n project-1 --kubeconfig "${MGMT_KUBECONFIG:?}"
Si la passerelle Cloud NAT est correctement configurée, le champ de condition d'état doit afficher la condition de type Ready définie sur true et les sous-réseaux marqués comme OK, comme indiqué dans l'exemple de résultat suivant :
apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
namespace: project-1
name: gateway-1
spec:
workloadSelector: # Immutable
labelSelector:
workloads:
matchLabels:
app: aa
clusters:
matchLabels:
kubernetes.io/metadata.name: user-vc-1
subnetRefs: # Mutable
- subnet-1
- subnet-2
status:
conditions:
- lastTransitionTime: "2025-08-20T21:31:36Z"
message: ""
observedGeneration: 1
reason: Ready
status: "True"
type: Ready
- lastTransitionTime: "2025-08-20T21:31:36Z"
message: ""
observedGeneration: 1
reason: Ready
status: "True"
type: SubnetsReady
- lastTransitionTime: "2025-08-20T21:31:36Z"
message: ""
observedGeneration: 1
reason: Ready
status: "True"
type: PerimeterConfigurationReady
- lastTransitionTime: "2025-08-20T21:31:36Z"
message: ""
observedGeneration: 1
reason: Ready
status: "True"
type: EgressRoutesReady
subnets:
- name: subnet-1
status: OK
- name: subnet-2
status: OK
Tester le trafic
Testez le trafic en exécutant une commande curl depuis l'un des pods ou l'une des VM attribués à la passerelle dans le cluster standard vers un point de terminaison externe. Le point de terminaison de réception doit voir un paquet provenant de l'une des adresses IP de sortie associées à la passerelle. Les points de terminaison des clusters partagés ayant les mêmes libellés NE PEUVENT PAS faire sortir le trafic à l'aide de cette passerelle.
Contraintes concernant les configurations de passerelle spécifiques à un cluster
Les sélecteurs de libellés de charge de travail (workloadSelector.labelSelector.workloads.matchLabels) des passerelles à portée de cluster ne DOIVENT PAS chevaucher les sélecteurs de libellés de charge de travail des autres passerelles à portée de projet. Comme indiqué dans Contraintes de configuration de Cloud NAT, le workloadSelector.labelSelector.workloads.matchLabels ne doit pas se chevaucher entre les passerelles d'un même projet et d'une même zone.
Les autres contraintes listées dans Contraintes sur la configuration Cloud NAT s'appliquent également aux configurations de passerelle à portée cluster.