Configurazione di un gateway NAT in uscita

Con Google Distributed Cloud, puoi configurare la Network Address Translation dell'origine (SNAT) in modo che a un determinato traffico in uscita dal cluster utente venga assegnato un indirizzo IP di origine prevedibile.

Questo documento mostra come configurare un gateway NAT in uscita per un cluster utente.

Attenzione: non puoi eseguire l'upgrade di alcun cluster versione 1.8.x o 1.9.x con Anthos Network Gateway abilitato a una versione successiva. Ad esempio, non puoi eseguire l'upgrade di un cluster versione 1.9.0 con Anthos Network Gateway abilitato alla versione 1.9.x, né puoi eseguire l'upgrade alla versione 1.10. Puoi eseguire l'upgrade solo dei cluster con Anthos Network Gateway abilitato se sono stati creati nella versione 1.10 o successive. Puoi eliminare un cluster versione 1.8.x o 1.9.x e poi ricrearlo seguendo le istruzioni riportate in questo documento.

Introduzione

A volte hai pod in esecuzione in un cluster utente che devono inviare pacchetti a componenti in esecuzione nella tua organizzazione, ma al di fuori del cluster. Potresti voler progettare questi componenti esterni in modo che filtrino il traffico di rete in entrata in base a un insieme di indirizzi IP di origine noti.

Ecco alcuni scenari:

• Hai un firewall davanti a un database che consente l'accesso solo tramite indirizzo IP. Inoltre, il team che gestisce il firewall del database è diverso da quello che gestisce il cluster di utenti.

• I workload nel cluster utente devono accedere a un'API di terze parti su internet. Per motivi di sicurezza, il fornitore dell'API autentica e autorizza il traffico utilizzando l'indirizzo IP come identità.

Con un gateway NAT in uscita, puoi avere un controllo granulare sugli indirizzi IP di origine utilizzati per il traffico di rete che esce da un cluster.

Prezzi

L'utilizzo di questa funzionalità durante l'anteprima non prevede costi.

Come funziona un gateway NAT in uscita

Normalmente, quando un pod invia un pacchetto al di fuori del cluster, il pacchetto viene tradotto SNAT con l'indirizzo IP del nodo in cui è in esecuzione il pod.

Quando è presente un gateway NAT in uscita, puoi specificare che determinati pacchetti in uscita vengano inviati prima a un nodo gateway dedicato. L'interfaccia di rete sul nodo gateway è configurata con due indirizzi IP: l'indirizzo IP principale e un indirizzo IP di origine in uscita.

Quando un pacchetto è stato selezionato per utilizzare il gateway NAT in uscita, il pacchetto esce dal cluster dal nodo gateway e viene tradotto SNAT con l'indirizzo IP di origine in uscita configurato sull'interfaccia di rete.

Il seguente diagramma illustra il flusso dei pacchetti:

Nel diagramma precedente puoi vedere il flusso di un pacchetto inviato dal pod.

1. Su un nodo con indirizzo IP 192.168.1.1, un pod con indirizzo IP 10.10.10.1 genera un pacchetto in uscita.

2. Il pacchetto corrisponde a una regola di uscita, quindi viene inoltrato al nodo gateway.

3. Il nodo gateway modifica l'indirizzo IP di origine in 192.168.1.100 e invia il pacchetto fuori dal cluster.

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

5. Il nodo gateway utilizza conntrack per modificare l'indirizzo IP di destinazione in 10.10.10.1.

6. Il pacchetto viene trattato come traffico in-cluster e inoltrato al nodo originale e restituito al pod originale.

Utenti tipo

Questo argomento si riferisce a due buyer persona:

• Amministratore del cluster. Questa persona crea un cluster utente e specifica gli indirizzi IP mobili da utilizzare con Anthos Network Gateway.

• Sviluppatore. Questa persona esegue carichi di lavoro sul cluster utente e crea policy di uscita.

Abilita il gateway NAT in uscita

Questa sezione è rivolta agli amministratori del cluster.

Per configurare un gateway NAT in uscita, utilizza i campi enableDataplaneV2 e advancedNetworking nel file di configurazione del cluster utente e crea uno o più oggetti NetworkGatewayGroup.

Nel file di configurazione del cluster, imposta questi campi su true:

enableDataplaneV2: true
...
advancedNetworking: true

Crea il cluster utenti.

Specifica gli indirizzi IP mobili

Questa sezione è rivolta agli amministratori del cluster.

Scegli un insieme di indirizzi IP da utilizzare come indirizzi di origine di uscita. Questi indirizzi sono chiamati indirizzi IP mobili, perché Network Gateway Group li assegna, in base alle necessità, alle interfacce di rete dei nodi che sceglie come gateway di uscita.

I tuoi indirizzi IP mobili devono trovarsi nella stessa subnet dei tuoi indirizzi IP dei nodi.

Il tuo insieme di indirizzi IP mobili non deve sovrapporsi all'insieme di indirizzi IP che hai specificato per i tuoi nodi.

Ad esempio, supponiamo che una subnet abbia l'intervallo di indirizzi 192.168.1.0/24. Supponiamo di aver scelto di utilizzare gli indirizzi da 192.168.1.1 a 192.168.1.99 per i nodi. Quindi, puoi utilizzare gli indirizzi IP mobili da 192.168.1.100 a 192.168.1.104.

Crea un oggetto NetworkGatewayGroup

Questa sezione è rivolta agli amministratori del cluster.

Ecco un esempio di manifest per un oggetto NetworkGatewayGroup:

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
  - 192.168.1.103
  - 192.168.1.104

Sostituisci l'array floatingIPs con i tuoi indirizzi IP mobili e salva il manifest in un file denominato my-ngg.yaml.

Crea l'oggetto NetworkGatewayGroup:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-ngg.yaml

Esempio di una policy NAT in uscita

Questa sezione è rivolta agli sviluppatori.

Ecco un esempio di risorsa personalizzata EgressNatPolicy:

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: alice-paul
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

Nel manifest precedente, vediamo:

• Un pod è un candidato per NAT in uscita se soddisfa una delle seguenti condizioni:

  • Il pod ha l'etichetta role: frontend e si trova in uno spazio dei nomi con l'etichetta user: alice.

  • Il pod ha l'etichetta role: frontend e si trova in uno spazio dei nomi con l'etichetta user: paul.

• Il traffico da un pod candidato a un indirizzo nell'intervallo 8.8.8.0/24 viene inviato al gateway NAT in uscita.

• La sezione gatewayRef determina l'indirizzo IP di origine dell'uscita. La risorsa personalizzata EgressNATPolicy utilizza i valori gatewayRef.name e gatewayRef.namespace per trovare un oggetto NetworkGatewayGroup. Il criterio utilizza uno degli indirizzi IP mobili di NetworkGatewayGroup come indirizzo IP di origine per il traffico in uscita. Se nel NetworkGatewayGroup corrispondente sono presenti più indirizzi IP mobili, il criterio utilizza il primo indirizzo IP nell'elenco floatingIPs e ignora tutti gli altri indirizzi IP. Se sono presenti campi non validi nella sezione gatewayRef, l'applicazione dell'oggetto EgressNATPolicy non andrà a buon fine.

Crea un oggetto EgressNATPolicy

Crea il tuo manifest EgressNATPolicy. Imposta metadata.name su "my-policy". Salva il manifest in un file denominato my-policy.yaml.

Crea l'oggetto EgressNatPolicy:

kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f my-policy.yaml

Visualizzare informazioni sulla tua policy NAT in uscita

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get egressnatpolicy my-policy --output yaml

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkgatewaygroup --namespace kube-system --output yaml

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe egressnatpolicy my-policy

Ordine delle operazioni

La policy NAT in uscita è compatibile con le API delle policy di rete. Il criterio di rete viene valutato prima del criterio NAT in uscita. Se una policy di rete indica di eliminare un pacchetto, il pacchetto viene eliminato indipendentemente dalla policy NAT in uscita.

Più policy in uscita

Come descritto in precedenza, ogni EgressNATPolicy utilizza il primo indirizzo IP nell'elenco floatingIPs del NetworkGatewayGroup che corrisponde a gatewayRef.name e gatewayRef.namespace. Se crei più criteri e intendi utilizzare indirizzi IP diversi, devi creare più oggetti NetworkGatewayGroup e farvi riferimento rispettivamente. Se crei più criteri, l'oggetto gatewayRef deve essere univoco per ogni criterio.

Ogni risorsa NetworkGatewayGroup deve contenere indirizzi IP mobili 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: Anthos Network Gateway non consente di creare nuovi oggetti gateway che contengono indirizzi IP in spec.floatingIPs già utilizzati in oggetti gateway esistenti. Questa regola viene applicata da un webhook in Google Distributed Cloud versione 1.15.0 e successive.

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 mobile. 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 mobili:

   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: egresspolicy1
   spec:
     ...
     gatewayRef:
       name: gateway1
       namespace: kube-system
   ---
   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egresspolicy2
   spec:
     ...
     gatewayRef:
       name: gateway2
       namespace: kube-system
   ---
   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egresspolicy3
   spec:
     ...
     gatewayRef:
       name: gateway3
       namespace: kube-system
   

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

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

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 di nodi corrisponde ai nodi con l'etichetta specificata e solo questi nodi vengono presi in considerazione per l'hosting di un indirizzo IP mobile. Se specifichi più selettori, la loro logica è additiva, quindi un nodo deve corrispondere a ogni etichetta per essere preso in considerazione per l'hosting di un indirizzo IP mobile. Se non ci sono molti nodi con etichette corrispondenti, un selettore di nodi può ridurre le qualità di alta disponibilità (HA) del posizionamento dell'indirizzo IP mobile.