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.
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 un pacchetto è stato selezionato per utilizzare il gateway NAT in uscita, il pacchetto lascia il cluster dal nodo gateway e viene tradotto con l'indirizzo IP di origine del traffico 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.
Su un nodo con indirizzo IP 192.168.1.1, un pod con indirizzo IP 10.10.10.1 genera un pacchetto in uscita.
Il pacchetto corrisponde a una regola in uscita, pertanto viene inoltrato al nodo gateway.
Il nodo gateway modifica l'indirizzo IP di origine in 192.168.1.100 e invia il pacchetto dal cluster.
Il traffico di ritorno torna al nodo gateway con la destinazione 192.168.1.100.
Il nodo gateway utilizza la funzione conntrack per modificare l'indirizzo IP di destinazione in 10.10.10.1.
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 Anthos Network Gateway
Questa sezione è rivolta agli amministratori di cluster.
Crea un nuovo cluster utente con Anthos Network Gateway abilitato.
Nel tuo file di configurazione del cluster utente, imposta enableDataplaneV2
e enableAnthosNetworkGateway
su true
enableDataplaneV2: true ... enableAnthosNetworkGateway: true
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é Anthos Network Gateway 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 AnthosNetworkGateway
Questa sezione è rivolta agli amministratori di cluster.
Di seguito è riportato un esempio di manifest per un oggetto AnthosNetworkGateway:
kind: AnthosNetworkGateway apiVersion: networking.gke.io/v1alpha1 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-ang.yaml
.
Crea l'oggetto AnthosNetworkGateway:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-ang.yaml
Esempio di criterio NAT in uscita
Questa sezione è rivolta agli sviluppatori.
Ecco un esempio di risorsa personalizzata RoamingNatPolicy:
kind: EgressNATPolicy metadata: name: alice-paul spec: egress: - namespaceSelector: matchLabels: user: alice podSelector: matchLabels: role: frontend - namespaceSelector: matchLabels: user: paul podSelector: matchLabels: role: frontend destinationCIDRs: - 8.8.8.0/24 egressSourceIP: 192.168.1.100
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'etichettauser: alice
.Il pod ha l'etichetta
role: frontend
e si trova in uno spazio dei nomi con l'etichettauser: paul
.
Il traffico da un pod candidato a un indirizzo nell'intervallo 8.8.8.0/24 viene inviato al gateway NAT in uscita.
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 anthosnetworkgateway --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.
Problemi noti
Indirizzi egressSourceIP
duplicati
Quando crei un oggetto RoamingNATGateway, puoi specificare un indirizzo egressSourceIP
già in uso per un altro oggetto EgressNATPolicy
. Questo causa conflitti di routing per il traffico in uscita. Coordina il tuo team di sviluppo per determinare quali indirizzi IP mobili sono disponibili prima di specificare l'indirizzo egressSourceIP
.
Modifiche alle risorse personalizzate
Le modifiche alle risorse personalizzate EgresNATPolicy non vengono completate nelle risorse personalizzate Cilium.