Con GKE su VMware, puoi configurare la traduzione degli indirizzi di rete (SNAT) di origine in modo che al 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.
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. Potrebbe essere opportuno progettare questi componenti esterni in modo che filtrano il traffico di rete in entrata in base a un insieme di indirizzi IP di origine noti.
Ecco alcuni scenari:
È presente un firewall davanti a un database che consente l'accesso solo tramite indirizzo IP. Il team che gestisce il firewall del database è diverso da quello che gestisce il cluster utente.
I carichi di lavoro nel tuo cluster utente devono accedere a un'API di terze parti tramite internet. Per motivi di sicurezza, il provider di 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
Normalmente, quando un pod invia un pacchetto dal cluster, viene tradotto con l'indirizzo SNAT con l'indirizzo IP del nodo su cui è in esecuzione il pod.
Quando è attivo 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 è stato selezionato un pacchetto per utilizzare il gateway NAT in uscita, lascia il cluster dal nodo gateway e viene tradotto con l'indirizzo IP di origine in uscita configurato nell'interfaccia di rete.
Il seguente diagramma illustra il flusso dei pacchetti:
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, quindi viene inoltrato al nodo del gateway.
Il nodo gateway modifica l'indirizzo IP di origine in 192.168.1.100 e invia il pacchetto fuori dal cluster.
Il traffico di ritorno torna al nodo gateway con la destinazione 192.168.1.100.
Il nodo gateway utilizza conntrack per modificare l'indirizzo IP di destinazione in 10.10.10.1.
Il pacchetto viene trattato come traffico nel cluster, inoltrato al nodo originale e 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 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
Specifica gli indirizzi IP mobili
Questa sezione è rivolta agli amministratori del 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 di gateway di rete li assegna, se necessario, alle interfacce di rete dei nodi che sceglie come gateway in uscita.
Gli indirizzi IP mobili devono trovarsi nella stessa subnet degli indirizzi IP dei nodi.
Il set di indirizzi IP mobili non deve sovrapporsi all'insieme di indirizzi IP che hai specificato per i nodi.
Ad esempio, supponiamo che l'intervallo di indirizzi di una subnet sia 192.168.1.0/24. Supponiamo che tu abbia scelto di utilizzare da 192.168.1.1 a 192.168.1.99 per i nodi. Quindi puoi 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 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 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 file manifest precedente vediamo:
Un pod è un candidato per il NAT in uscita se soddisfa uno dei seguenti requisiti:
Il pod ha l'etichetta
role: frontend
e il pod si trova in uno spazio dei nomi con l'etichettauser: alice
.Il pod ha l'etichetta
role: frontend
e il pod 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.
La sezione
gatewayRef
determina l'indirizzo IP di origine del traffico in uscita. La risorsa personalizzata OutboundNATPolicy utilizza i valorigatewayRef.name
egatewayRef.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 sono presenti più indirizzi IP mobili nel NetworkGatewayGroup corrispondente, il criterio utilizza il primo indirizzo IP nell'elencofloatingIPs
e ignora eventuali altri indirizzi IP. Se sono presenti campi non validi nella sezionegatewayRef
, l'applicazione dell'oggetto OutboundNATPolicy non sarà riuscita.
Crea un oggetto OutboundNATPolicy
Crea il tuo 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 viene valutato prima del criterio NAT in uscita. Se un criterio di rete indica di rilasciare un pacchetto, questo viene ignorato indipendentemente dal criterio NAT in uscita.
Più criteri in uscita
Come descritto in precedenza, ogni criterio OutboundNATPolicy utilizza il primo indirizzo IP nell'elenco floatingIPs
di 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.
Per configurare più criteri in uscita e più oggetti gateway:
Crea oggetti gateway nello spazio dei nomi
kube-system
per gestire ciascun indirizzo IP mobile. In genere, ogni criterio in uscita deve avere un 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
Crea più criteri che fanno riferimento agli oggetti gateway, ad esempio
gateway1
creati 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 l'hosting di un indirizzo IP mobile, 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 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 degli indirizzi IP mobili.