Configurazione di un gateway NAT in uscita

Questo documento descrive come configurare un gateway NAT in uscita per Google Distributed Cloud. Questo gateway fornisce indirizzi IP SNAT deterministici e permanenti per il traffico in uscita dai tuoi cluster. Quando esegui carichi di lavoro con traffico in uscita degli utenti (al di fuori dei tuoi cluster), i clienti vogliono identificare questo traffico utilizzando alcuni indirizzi IP deterministici. In questo modo, i tuoi clienti possono stabilire misure di sicurezza basate su IP, come i criteri di lista consentita.

Questa pagina è rivolta agli esperti di networking che progettano e progettano la rete per la propria organizzazione e installano, configurano e supportano le apparecchiature di rete. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività utente comuni di GKE Enterprise.

Il gateway NAT in uscita viene attivato utilizzando due risorse personalizzate. Per un determinato suo spazio dei nomi, la risorsa personalizzata NetworkGatewayGroup specifica gli indirizzi IP dinamici che possono essere configurati sull'interfaccia di rete di un Nodo scelto per fungere da gateway. La risorsa personalizzata EgressNatPolicy consente di specificare i criteri di routing in uscita per controllare il traffico sul gateway in uscita.

Se non configuri un gateway NAT in uscita o se il traffico in uscita non soddisfa le regole di selezione del traffico, il traffico in uscita da un determinato pod a una destinazione al di fuori del cluster viene mascherato con l'indirizzo IP del nodo in cui è in esecuzione il pod. In questo scenario, non è garantito che tutto il traffico in uscita da un determinato pod abbia lo stesso indirizzo IP di origine o che venga mascherato nello stesso indirizzo IP del nodo.

Il gateway NAT in uscita è un'offerta di networking avanzata basata su Dataplane V2.

Nota: se i tuoi nodi eseguono Ubuntu 18.04, il kernel Linux deve essere della versione 5.4 o successiva. Per ulteriori informazioni, consulta Configurare Ubuntu.

Come funziona il gateway NAT in uscita

La logica di selezione del traffico in uscita si basa su un selettore di spazi dei nomi, un selettore di pod e un insieme di intervalli di indirizzi IP di destinazione nella notazione dei blocchi CIDR. Per illustrare il funzionamento del gateway NAT in uscita, consideriamo il flusso di un pacchetto da un pod a un consumatore esterno e la risposta corrispondente. Supponiamo che la subnet del nodo abbia indirizzi IP nel blocco CIDR 192.168.1.0/24.

Il seguente diagramma mostra l'architettura di rete per il traffico in uscita tramite un nodo gateway.

Il flusso di pacchetti attraverso il gateway NAT in uscita potrebbe essere simile al seguente:

1. Il traffico in uscita viene generato da un pod con indirizzo IP 10.10.10.1 in un node con indirizzo IP 192.168.1.1.

   L'indirizzo di destinazione del traffico è un endpoint esterno al cluster.

2. Se il traffico corrisponde a una regola di uscita, il programma eBPF instrada il traffico in uscita al nodo gateway anziché eseguire il mascheramento direttamente con l'indirizzo IP del nodo.

3. Il nodo gateway riceve il traffico in uscita.

4. Il nodo gateway maschera l'indirizzo IP di origine del traffico di origine, 10.10.10.1, con l'indirizzo IP di uscita di origine, 192.168.1.100 specificato nella risorsa personalizzata EgressNATPolicy.

5. Il traffico di ritorno torna al nodo gateway con destinazione 192.168.1.100.

6. Il nodo gateway associa il conntrack del traffico di ritorno a quello del traffico in uscita originale e riscrivi l'indirizzo IP di destinazione come 10.10.10.1.

7. 10.10.10.1 viene trattato come traffico all'interno del cluster, indirizzato al nodo originale e nuovamente inviato al pod originale.

Configura gli indirizzi IP mobili per il traffico del nodo

La risorsa personalizzata Gruppo di gateway di rete è un componente in bundle di Google Distributed Cloud. La risorsa gestisce un elenco di uno o più indirizzi IP variabili da utilizzare per il traffico in uscita dai nodi del cluster. I Nodi partecipanti sono determinati dallo spazio dei nomi specificato. Il gruppo Network Gateway rende disponibile un indirizzo IP dinamico in qualsiasi momento su base best effort. Se un nodo che utilizza un indirizzo IP dinamico si arresta in modo anomalo, l'operatore di rete avanzato sposta l'indirizzo IP assegnato al nodo successivo disponibile. Verrà spostato anche tutto il traffico in uscita del carico di lavoro che utilizza l'indirizzo IP in questione.

Includi i dettagli del gruppo di gateway di rete (annotazione e specifiche) nel file di configurazione del cluster quando crei un nuovo cluster 1.30.300-gke.84.

Crea la risorsa personalizzata NetworkGatewayGroup

Per attivare il gruppo di gateway di rete, imposta il campo spec.clusterNetwork.advancedNetworking su true nel file di configurazione del cluster quando crei un cluster, come mostrato nell'esempio seguente:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  clusterNetwork:
    ...
    advancedNetworking: true
    ...

Quando crei la risorsa personalizzata NetworkGatewayGroup, imposta il relativo spazio dei nomi sullo spazio dei nomi del cluster e specifica un elenco di indirizzi IP flottanti, come mostrato nell'esempio seguente:

Nota: l'operatore del cluster crea una copia della risorsa personalizzata NetworkGatewayGroup nello spazio dei nomi kube-system. Questa copia della risorsa personalizzata NetworkGatewayGroup nello spazio dei nomi kube-system è responsabile della definizione degli indirizzi IP mobili utilizzati dall'operatore di reti avanzate.

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: cluster-cluster1
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102

Nota: il gateway NAT in uscita non supporta una configurazione di alta disponibilità (HA). Se il nodo del gateway di rete che gestisce l'indirizzo IP dinamico si arresta o presenta problemi di connettività, il traffico in uscita potrebbe essere interrotto per brevi periodi di tempo. L'operatore di rete avanzato riassegna automaticamente l'indirizzo IP dinamico a un nuovo nodo per ripristinare il traffico in uscita.

L'operatore di rete avanzato assegna gli IP flottanti ai nodi in base ai seguenti criteri:

• Subnet del nodo: l'indirizzo IP dinamico deve corrispondere alla subnet del nodo.
• Ruolo del nodo (control plane, worker): i nodi worker hanno la precedenza sui nodi del piano di controllo durante l'assegnazione degli indirizzi IP flottanti.
• Se un nodo ha un indirizzo IP dinamico: l'operatore dà la priorità alle assegnazioni ai nodi a cui non è già stato assegnato un IP dinamico.

La mappatura indirizzo/nodo è disponibile nella sezione status quando ottieni l'oggetto NetworkGatewayGroup. Tieni presente che l'oggetto NetworkGatewayGroup si trova nello spazio dei nomi kube-system. Se un nodo gateway non è attivo, l'operatore di rete avanzato assegna gli indirizzi IP fluttuanti al nodo successivo disponibile.

Verifica la configurazione del gateway

Dopo aver applicato le modifiche alla configurazione del gateway, puoi utilizzare kubectl per controllare lo stato del gateway e recuperare gli indirizzi IP dinamici specificati per il gateway.

1. Utilizza il seguente comando per controllare lo stato di NetworkGatewayGroup e vedere come vengono allocati gli indirizzi IP flottanti:

   kubectl -n kube-system get networkgatewaygroups.networking.gke.io default -o yaml

   La risposta per un cluster con due nodi, worker1 e worker2, potrebbe essere simile alla seguente:

   kind: NetworkGatewayGroup
   apiVersion: networking.gke.io/v1
   metadata:
     namespace: kube-system
     name: default
   spec:
     floatingIPs:
     - 192.168.1.100
     - 192.168.1.101
     - 192.168.1.102
   status:
     nodes:
       worker1: Up
       worker2: Up // Or Down
     floatingIPs:
       192.168.1.100: worker1
       192.168.1.101: worker2
       192.168.1.102: worker1
   

Impostare le regole di selezione del traffico

La risorsa personalizzata EgressNATPolicy specifica le regole di selezione del traffico e assegna un indirizzo IP deterministico per il traffico in uscita che esce dal cluster. Quando specifichi la risorsa personalizzata, egress (con almeno una regola), destinationCIDRs e egressSourceIP sono tutti obbligatori.

Nota: è possibile impostare regole di selezione del traffico che specificano un indirizzo egressSourceIP già in uso per un altro oggetto EgressNATPolicy. Ciò potrebbe causare conflitti di routing del traffico in uscita. Coordinati con il tuo team di sviluppo per determinare quali indirizzi IP mobili sono disponibili per l'utilizzo prima di specificare l'indirizzo egressSourceIP nella risorsa personalizzata EgressNATPolicy.

Utilizza kubectl apply per creare la risorsa personalizzata EgressNATPolicy. Le seguenti sezioni forniscono dettagli ed esempi per la definizione della specifica.

Specifica le regole di routing in uscita

La risorsa personalizzata EgressNatPolicy ti consente di specificare le seguenti regole per il traffico in uscita:

• Devi specificare una o più regole di selezione del traffico in uscita nella egress sezione.

  • Ogni regola è composta da un podSelector e un namespaceSelector.
  • La selezione si basa su un'etichetta dello spazio dei nomi,namespaceSelector.matchLabels.user, e un'etichetta del pod,podSelector.matchLabels.role.
  • Se un pod corrisponde a una delle regole (la corrispondenza utilizza una relazione OR), viene selezionato per il traffico in uscita.

• Specifica gli indirizzi di destinazione consentiti nella sezione destinationCIDRs.

  • destinationCIDRs accetta un elenco di blocchi CIDR.
  • Se il traffico in uscita da un pod ha un indirizzo IP di destinazione che rientra nell'intervallo di uno dei blocchi CIDR specificati, viene selezionato per il traffico in uscita.

Nell'esempio seguente, il traffico in uscita da un pod è consentito quando vengono soddisfatti i seguenti criteri:

• Il pod è etichettato con role: frontend.
• Il pod si trova in uno spazio dei nomi etichettato come user: alice o user: paul.
• Il pod comunica con gli indirizzi IP nel blocco CIDR 8.8.8.0/24.

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress
spec:
  sources:
  - namespaceSelector:
      matchLabels:
        user: alice
    podSelector:
      matchLabels:
        role: frontend
  - namespaceSelector:
      matchLabels:
        user: paul
    podSelector:
      matchLabels:
        role: frontend
  action: SNAT
  destinations:
    - cidr: 8.8.8.0/24
  gatewayRef:
    name: default
    namespace: kube-system

Per saperne di più sull'utilizzo delle etichette, consulta Etichette e selettori nella documentazione di Kubernetes.

Ottieni un indirizzo IP di origine per il traffico in uscita

La risorsa personalizzata EgressNATPolicy (criterio) utilizza i valori gatewayRef.name e gatewayRef.namespace per trovare un oggetto NetworkGatewayGroup (gateway). Il criterio utilizza uno degli indirizzi IP variabili del gateway come indirizzo IP di origine per il traffico in uscita. Se nel gateway corrispondente sono presenti più indirizzi IP variabili, il criterio utilizza il primo indirizzo IP nell'elenco floatingIPs e ignora gli altri indirizzi IP. Per il gateway di esempio, il primo indirizzo nell'elenco floatingIPs è 192.168.1.100. La presenza di campi o valori non validi nella sezione gatewayRef comporterà l'impossibilità di applicare l'oggetto della norma.

Più criteri di uscita e più oggetti gateway

Come descritto nella sezione precedente, ogni oggetto egressNATPolicy (norma) utilizza il primo indirizzo IP nell'elenco floatingIPs dell'oggetto gateway che corrisponde a gatewayRef.name e gatewayRef.namespace. Puoi creare più criteri e, se intendi utilizzare indirizzi IP diversi, devi creare più oggetti NetworkGatewayGroup e fare riferimento a ciascuno di essi.

Ogni risorsa NetworkGatewayGroup deve contenere indirizzi IP dinamici univoci. Per configurare più oggetti EgressNATPolicy in modo che utilizzino lo stesso indirizzo IP, utilizza lo stesso gatewayRef.name e gatewayRef.namespace per entrambi.

Nota: Network Gateway per GDC non ti consente di creare nuovi oggetti gateway contenenti indirizzi IP in spec.floatingIPs già utilizzati negli oggetti gateway esistenti. Questa regola viene applicata da un webhook.

Per configurare più criteri in uscita e più oggetti gateway:

1. Crea oggetti gateway nello spazio dei nomi kube-system per gestire ogni indirizzo IP dinamico. In genere, ogni criterio di uscita deve avere un oggetto gateway corrispondente per garantire l'allocazione dell'indirizzo IP corretto.

   Quindi, verifica ogni oggetto gateway con kubectl per ottenere lo stato di allocazione degli indirizzi IP flottanti:

   kind: NetworkGatewayGroup
   apiVersion: networking.gke.io/v1
   metadata:
     namespace: kube-system
     name: gateway1
   spec:
     floatingIPs:
     - 192.168.1.100
   status:
     ...
     floatingIPs:
       192.168.1.100: worker1
   ---
   kind: NetworkGatewayGroup
   apiVersion: networking.gke.io/v1
   metadata:
     namespace: kube-system
     name: gateway2
   spec:
     floatingIPs:
     - 192.168.1.101
   status:
     ...
     floatingIPs:
       192.168.1.101: worker2
   ---
   kind: NetworkGatewayGroup
   apiVersion: networking.gke.io/v1
   metadata:
     namespace: kube-system
     name: gateway3
   spec:
     floatingIPs:
     - 192.168.1.102
   status:
     ...
     floatingIPs:
       192.168.1.102: worker1
   

2. Crea più criteri che fanno riferimento agli oggetti gateway, ad esempio gateway1 creato nel passaggio precedente:

   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egress1
   spec:
     ...
     gatewayRef:
       name: gateway1
       namespace: kube-system
   ---
   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egress2
   spec:
     ...
     gatewayRef:
       name: gateway2
       namespace: kube-system
   ---
   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egress3
   spec:
     ...
     gatewayRef:
       name: gateway3
       namespace: kube-system
   

(Facoltativo) Specifica i nodi su cui posizionare gli indirizzi IP mobili

Le risorse NetworkGatewayGroup supportano i selettori dei nodi. Per specificare un sottoinsieme di nodi da considerare per l'hosting di un indirizzo IP dinamico, puoi aggiungere il selettore di nodi all'oggetto NetworkGatewayGroup come mostrato nell'esempio seguente:

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: cluster-cluster1
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102
  nodeSelector:
    node-type: "egressNat"

Il selettore dei nodi corrisponde ai nodi con l'etichetta specificata e solo questi nodi vengono presi in considerazione per l'hosting di un indirizzo IP dinamico. Se specifichi più selezionatori, la loro logica è additiva, quindi un nodo deve corrispondere a ogni etichetta per essere preso in considerazione per l'hosting di un indirizzo IP dinamico. Se non ci sono molti nodi con etichette corrispondenti, un selettore di nodi può ridurre le qualità di alta disponibilità (HA) del posizionamento degli indirizzi IP fluttuanti.

Regole di selezione del traffico in uscita e criteri di rete

Il gateway NAT in uscita è compatibile con le API di criteri di rete. I criteri di rete vengono valutati per primi e hanno la precedenza sulle regole di selezione del traffico del gateway NAT di uscita. Ad esempio, se il traffico in uscita attiva un criterio di rete che comporta l'eliminazione del pacchetto, le regole del gateway in uscita non lo controlleranno. Solo quando il criterio di rete consente l'uscita del pacchetto, le regole di selezione del traffico in uscita vengono valutate per decidere come gestire il traffico, utilizzando il gateway NAT in uscita o mascherando direttamente l'indirizzo IP del nodo in cui è in esecuzione il pod.

Limitazioni

Le limitazioni attuali del gateway NAT in uscita includono:

• Il gateway NAT in uscita è abilitato solo per la modalità IPv4.

• Gli indirizzi IP in uscita devono trovarsi nello stesso dominio di livello 2 degli indirizzi IP dei nodi.