Passerelles Cloud NAT pour les clusters standards

Google Distributed Cloud (GDC) air-gapped 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 et décrit 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 règle de réseau appropriée et activer le trafic sortant.

Pour en savoir plus, consultez la section Avant de commencer avec Cloud NAT.

La passerelle Cloud NAT utilise des sous-réseaux leaf externes comme entrées. Pour en savoir plus sur la configuration de sous-réseaux externes pour Cloud NAT, consultez Créer des sous-réseaux externes pour Cloud NAT.

Présentation

Schéma montrant la configuration d'une passerelle Cloud NAT pour un cluster standard

Les passerelles Cloud NAT peuvent être configurées pour gérer le trafic sortant 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 s'applique uniquement 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 destiné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

Le processus de création d'une passerelle pour un cluster standard reste le même que celui de la création d'une passerelle Cloud NAT à portée de projet.

Dans ce cas, nous nous concentrons sur la fonctionnalité de filtrage de cluster 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 avec les libellés 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 configuration est correcte, le champ de condition d'état de la passerelle Cloud NAT doit afficher la condition de type Ready définie sur true et les sous-réseaux marqués comme OK, comme illustré 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 à partir de l'un des pods ou 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 portant 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 correspondances de libellés de charges de travail (workloadSelector.labelSelector.workloads.matchLabels) des passerelles à portée de cluster NE DOIVENT PAS SE CHEVAUCHER avec les correspondances de libellés de charges de travail d'autres passerelles à portée de projet. Comme indiqué dans Contraintes concernant la configuration Cloud NAT, les workloadSelector.labelSelector.workloads.matchLabels ne doivent pas se chevaucher entre les passerelles du même projet et de la même zone.

Les autres contraintes listées dans Contraintes concernant la configuration Cloud NAT s'appliquent également aux configurations de passerelle à portée de cluster .