Configurazione di un gateway NAT in uscita

Con Google Distributed Cloud, puoi configurare l'indirizzo di rete di origine (SNAT) in modo che il traffico in uscita dal tuo cluster utente venga a 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 nessun cluster di versione 1.8.x o 1.9.x con Anthos Gateway di rete abilitato a qualsiasi versione successiva. Ad esempio, non puoi eseguire l'upgrade di una versione 1.9.0 con il gateway di rete Anthos abilitato alla versione 1.9.x, né può esegui l'upgrade alla versione 1.10. Puoi eseguire l'upgrade solo dei cluster che hanno Anthos Gateway di rete abilitato se sono stati creati nella versione 1.10 o successive. Puoi elimina un cluster della versione 1.8.x o 1.9.x, quindi ricrealo seguendo le istruzioni in questo documento.

Introduzione

A volte hai pod in esecuzione in un cluster utente che devono inviare pacchetti ai componenti in esecuzione nella tua organizzazione, ma al di fuori del cluster. Tu potrebbe voler progettare quei componenti esterni in modo da filtrare traffico di rete in base a un insieme di indirizzi IP di origine noti.

Ecco alcuni scenari:

• Disponi di un firewall davanti a un database che consente l'accesso solo in base all'indirizzo IP. E il team che gestisce il firewall del database è diverso dal team che gestisce il cluster utente.

• I carichi di lavoro nel cluster utente devono accedere a un'API di terze parti tramite internet. Per motivi di sicurezza, il provider API autentica e autorizza il traffico usando l'indirizzo IP come identità.

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

Prezzi

Non è previsto alcun costo per l'utilizzo di questa funzionalità durante l'anteprima.

Come funziona un gateway NAT in uscita

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

Quando è attivo un gateway NAT in uscita, puoi specificare che una determinata devono essere inviati prima a un nodo gateway dedicato. L'interfaccia di rete sul nodo gateway sia configurato con due indirizzi IP: l'indirizzo IP principale e un indirizzo IP di origine in uscita.

Dopo aver selezionato un pacchetto per utilizzare il gateway NAT in uscita, lascia il cluster dal nodo gateway e viene tradotto SNAT con il traffico in uscita dall'indirizzo IP di origine configurato nell'interfaccia di rete.

Il seguente diagramma illustra il flusso dei pacchetti:

Nel diagramma precedente è visibile il flusso di un pacchetto inviato all'interno del 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 in uscita, quindi viene inoltrato al gateway nodo.

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

4. Il traffico restituito torna al nodo gateway con destinazione 192.168.1.100.

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

6. Il pacchetto viene trattato come traffico nel cluster e inoltrato all'originale dal nodo stesso e poi rispedito al pod originale.

Utenti tipo

Questo argomento fa riferimento a due utenti tipo:

• Amministratore del cluster. Questa persona crea un cluster utente e specifica indirizzi IP mobili che devono essere utilizzati dal gateway di rete Anthos.

• Sviluppatore. Questa persona esegue carichi di lavoro sul cluster utente e crea e i criteri di traffico in uscita.

Abilita 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 utente.

Specifica gli indirizzi IP mobili

Questa sezione è rivolta agli amministratori del cluster.

Scegli un insieme di indirizzi IP da utilizzare come origine in uscita indirizzi IP esterni. Questi vengono chiamati indirizzi IP mobili, poiché le reti Il gruppo di gateway li assegna, se necessario, alle interfacce di rete dei nodi a cui sceglie di essere gateway in uscita.

Gli indirizzi IP mobili devono trovarsi nella stessa subnet degli indirizzi IP dei nodi.

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

Supponiamo, ad esempio, che una subnet abbia l'intervallo di indirizzi 192.168.1.0/24. Supponiamo che hai scelto di usare i nodi da 192.168.1.1 a 192.168.1.99. Poi potrebbe utilizzare da 192.168.1.100 a 192.168.1.104 come indirizzi IP mobili.

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 manifest in un file denominato my-ngg.yaml.

Crea l'oggetto NetworkGatewayGroup:

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

Esempio di criterio NAT in uscita

Questa sezione è rivolta agli sviluppatori.

Ecco un esempio di risorsa personalizzata OutboundNatPolicy:

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 è candidato per il NAT in uscita se soddisfa uno dei seguenti requisiti:

  • 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 a il gateway NAT in uscita.

• La sezione gatewayRef determina l'indirizzo IP di origine in uscita. La risorsa personalizzata OutboundNATPolicy 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 qualsiasi altro indirizzo IP. Se nella sezione gatewayRef sono presenti campi non validi, l'applicazione dell'oggetto EgressNATPolicy non riuscirà.

crea un oggetto OutboundNATPolicy

Creare il proprio manifest OutboundNATPolicy. Imposta metadata.name su "my-policy". Salva il manifest in un file denominato my-policy.yaml.

Crea l'oggetto OutboundNatPolicy:

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

Visualizza le informazioni sul criterio 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

Il criterio NAT in uscita è compatibile con le API dei criteri di rete. Il criterio di rete è prima del criterio NAT in uscita. Se un criterio di rete deve abbandonare un pacchetto, il pacchetto viene ignorato indipendentemente dal criterio NAT in uscita.

Più criteri 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, usa gli stessi gatewayRef.name e gatewayRef.namespace per entrambi.

Nota: il gateway di rete Anthos non consente di creare nuovi oggetti gateway che contengono indirizzi IP in spec.floatingIPs che sono già utilizzati in indirizzi oggetti gateway. 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 gestirli ogni all'indirizzo IP mobile. In genere, ogni criterio in uscita dovrebbe avere un dell'oggetto gateway corrispondente per garantire che venga allocato l'indirizzo IP corretto.

   Poi 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 facciano riferimento agli oggetti gateway, ad esempio come 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 in cui posizionare gli indirizzi IP mobili

NetworkGatewayGroup risorse supportano i selettori dei nodi. Per specificare un sottoinsieme di nodi considerati per ospitare un indirizzo IP mobile, puoi aggiungere selettore di nodi all'oggetto NetworkGatewayGroup, come mostrato di seguito 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 che hanno l'etichetta specificata e solo questi vengono considerati per l'hosting di un indirizzo IP mobile. Se specifichi più selettori, con una logica additiva. Perciò un nodo deve corrispondere a ogni etichetta considerata per l'hosting di un indirizzo IP mobile. Se non ci sono molti nodi con che corrispondono alle etichette, un selettore di nodi può ridurre le qualità di alta disponibilità del posizionamento degli indirizzi IP mobili.