Gateway Cloud NAT per cluster standard

Google Distributed Cloud (GDC) air-gapped supporta i cluster standard, un cluster Kubernetes self-service a progetto singolo gestito dal gruppo di operatori di applicazioni che offre maggiore flessibilità per i carichi di lavoro personalizzati. Questa pagina spiega come configurare Cloud NAT per i cluster standard e descrive alcuni vincoli e limitazioni per le configurazioni NAT per questo tipo di cluster.

Prima di iniziare

Prima di configurare un gateway, devi ottenere le autorizzazioni Identity and Access Management (IAM) appropriate, assicurarti che il tuo progetto disponga di un criterio di rete appropriato e abilitare l'uscita.

Per informazioni dettagliate, consulta Prima di iniziare a utilizzare Cloud NAT.

Il gateway Cloud NAT utilizza le subnet esterne leaf come input. Per ulteriori informazioni sulla configurazione delle subnet esterne per Cloud NAT, vedi Crea subnet esterne per Cloud NAT.

Panoramica

Diagramma che mostra la configurazione di un gateway Cloud NAT per un cluster standard

I gateway Cloud NAT possono essere configurati per gestire il traffico in uscita per i carichi di lavoro in esecuzione su cluster standard in due modi:

  • Gateway con ambito progetto:un gateway che si applica a tutto il traffico dei carichi di lavoro sui cluster all'interno di un progetto, inclusi tutti i cluster condivisi e standard. Questa è la configurazione descritta in Crea un gateway Cloud NAT.
  • Gateway con ambito cluster: un gateway che si applica solo ai carichi di lavoro all'interno di un singolo cluster standard specificato. Questo è il tipo di gateway mostrato in questa pagina.

Questi due metodi sono esclusivamente per i workload e non si applicano ai nodi che compongono un cluster standard. Per abilitare Cloud NAT per i nodi che formano un cluster standard, aggiungi l'etichetta cluster.gdc.goog/enable-node-egress-to-outside-the-org: "true" all'oggetto cluster standard.

Crea il gateway Cloud NAT

La procedura di creazione di un gateway per un cluster standard rimane la stessa della creazione di qualsiasi gateway Cloud NAT con ambito progetto.

In questo caso, ci concentriamo sulla funzionalità di filtro dei cluster per Cloud NAT standard e creiamo una configurazione simile al primo scenario, ma specificando il nome del cluster standard user-vc-1 in cui si trovano gli endpoint che instradano il traffico tramite il gateway. Di conseguenza, questo gateway sarà limitato a questo cluster specifico.

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

Questa configurazione selezionerà tutti i workload con le etichette app: aa in tutti gli spazi dei nomi del cluster standard user-vc-1.

Controllare lo stato del gateway

Controlla lo stato dei gateway eseguendo il seguente comando kubectl.

export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
kubectl get cloudnatgateways gateway-1 -n project-1 --kubeconfig "${MGMT_KUBECONFIG:?}"

Se configurato correttamente, il campo della condizione di stato del gateway Cloud NAT dovrebbe mostrare la condizione del tipo Ready impostata su true e le subnet contrassegnate come OK, come mostrato nel seguente output di esempio:

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

Traffico di test

Testa il traffico eseguendo un comando curl da uno dei pod o delle VM assegnati al gateway nel cluster standard verso un endpoint esterno. L'endpoint di ricezione dovrebbe visualizzare un pacchetto da uno degli IP di uscita associati al gateway. Gli endpoint nei cluster condivisi con le stesse etichette NON POSSONO eseguire l'uscita del traffico utilizzando questo gateway.

Vincoli relativi alle configurazioni del gateway specifiche per il cluster

I selettori di etichette dei carichi di lavoro (workloadSelector.labelSelector.workloads.matchLabels) dei gateway con ambito cluster NON DEVONO SOVRAPPORSI ai selettori di etichette dei carichi di lavoro di altri gateway con ambito progetto. Come descritto in Vincoli alla configurazione di Cloud NAT, l'workloadSelector.labelSelector.workloads.matchLabels non deve sovrapporsi tra i gateway nello stesso progetto e nella stessa zona.

Anche gli altri vincoli elencati in Vincoli alla configurazione di Cloud NAT si applicano alle configurazioni del gateway con ambito cluster.