Configurazione di un gateway NAT in uscita

Version 1.12 

• Versione più recente
• Versione 1.16
• Versioni precedenti (non supportate)

Con i cluster Anthos su VMware (GKE On-Prem), puoi configurare la traduzione dell'indirizzo di rete (SNAT) di origine in modo che determinati traffico in uscita dal cluster utente ricevano 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 della versione 1.8.x o 1.9.x con Anthos Network Gateway abilitato a qualsiasi versione successiva. Ad esempio, non puoi eseguire l'upgrade di un cluster di versione 1.9.0 in cui Anthos Network Gateway è abilitato alla versione 1.9.x, né puoi eseguire l'upgrade alla versione 1.10. Puoi eseguire l'upgrade dei cluster per cui è abilitato Anthos Gateway di rete solo se sono stati creati nella versione 1.10 o successiva. Puoi eliminare un cluster della versione 1.8.x o 1.9.x e quindi ricrearlo seguendo le istruzioni riportate 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 all'esterno del cluster. Ti consigliamo di progettare tali componenti esterni in modo che filtrino il traffico di rete in entrata in base a un set di indirizzi IP di origine noti.

Ecco alcuni scenari:

• Hai un firewall di fronte a un database che consente l'accesso solo tramite indirizzo IP. 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 su Internet. Per motivi di sicurezza, il provider 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 lascia 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, il pacchetto viene SNAT tradotto con l'indirizzo IP del nodo in cui è in esecuzione il pod.

Quando è attivo un gateway NAT in uscita, puoi specificare che alcuni pacchetti in uscita debbano essere 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 viene selezionato un pacchetto per l'utilizzo del gateway NAT in uscita, il pacchetto lascia il cluster dal nodo gateway e viene tradotto tramite SNAT con l'indirizzo IP dell'origine in uscita configurato nell'interfaccia di rete.

Il seguente diagramma illustra il flusso del pacchetto:

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 in uscita, pertanto viene inoltrato al nodo gateway.

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

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

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

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

Utenti tipo

Questo argomento si riferisce a due utenti tipo:

• Amministratore del cluster. Questa persona crea un cluster utente e specifica gli indirizzi IP mobili che devono essere utilizzati da Anthos Network Gateway.

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

Abilita gateway NAT in uscita

Questa sezione è rivolta agli amministratori di 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 indirizzi IP mobili

Questa sezione è rivolta agli amministratori di cluster.

Scegli un insieme di indirizzi IP che vuoi utilizzare come indirizzi di origine in uscita. Questi sono chiamati indirizzi IP mobili, perché il gruppo gateway di rete li assegna, se necessario, alle interfacce di rete dei nodi che sceglie di essere gateway in uscita.

Gli indirizzi IP mobili devono trovarsi nella stessa subnet degli indirizzi IP del nodo.

Il set di indirizzi IP mobili non deve sovrapporsi al set di indirizzi IP specificato per i nodi.

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

Crea un oggetto NetworkGatewayGroup

Questa sezione è rivolta agli amministratori di cluster.

Di seguito è riportato 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 gli indirizzi IP mobili e salva il file 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 RoamingNatPolicy:

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 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 dell'origine in uscita. La risorsa personalizzata RoamingNATPolicy 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 nell'oggetto NetworkGatewayGroup corrispondente sono presenti più indirizzi IP mobili, il criterio utilizza il primo indirizzo IP dell'elenco floatingIPs e ignora gli altri indirizzi IP. Se nella sezione gatewayRef sono presenti campi non validi, l'applicazione dell'oggetto outNATPolicy non riuscirà.

Crea un oggetto outNATPolicy

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

Crea l'oggetto RoamingNatPolicy:

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

Visualizza informazioni sul tuo 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 viene valutato prima del criterio NAT in uscita. Se un criterio di rete indica di eliminare un pacchetto, il pacchetto viene eliminato indipendentemente dal criterio NAT in uscita.

Più criteri in uscita

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

Un limite nei cluster Anthos su VMware per questa release è che solo il NetworkGatewayGroup con il nome default nello spazio dei nomi kube-system viene riconciliato per le allocazioni IP mobili. Inoltre, solo NetworkNetworkGroup predefinito indica lo stato di allocazione di tutti gli indirizzi IP mobili.

Pertanto, quando crei più oggetti NetworkGatewayGroup, devi assicurarti che anche gli indirizzi IP negli oggetti non predefiniti vengano specificati nel manifest NetworkNetworkGroup predefinito. In caso contrario, non verranno assegnati come IP mobili e quindi non potranno essere utilizzati dall'oggetto outNATPolicies.

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

1. Verifica l'oggetto NetworkGatewayGroup (name: default) predefinito con kubectl per ottenere lo stato di allocazione degli indirizzi IP mobili:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkgatewaygroup --name default --output yaml
   

   La risposta per un cluster con due nodi, worker1 e worker2, potrebbe avere il seguente aspetto:

   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:
     ...
     floatingIPs:
       192.168.1.100: worker1
       192.168.1.101: worker2
       192.168.1.102: worker1
   

2. Dopo aver verificato lo stato del NetworkGatewayGroup predefinito, crea ulteriori oggetti NetworkGatewayGroup nello spazio dei nomi kube-system per "tracciare" ogni IP mobile.

   Tieni presente che questi nuovi oggetti non segnalano lo stato di allocazione, che si trova nel default NetworkGatewayGroup.

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

3. Crea più criteri che fanno riferimento agli oggetti "secondary" NetworkGatewayGroup, 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