Questo documento descrive come configurare un gateway NAT in uscita Google Distributed Cloud. Questo gateway fornisce un indirizzo IP SNAT permanente e deterministico per il traffico in uscita dai cluster. Quando esegui carichi di lavoro che utenti in uscita (al di fuori dei cluster), i tuoi clienti vogliono identificare questo traffico usando alcuni indirizzi IP deterministici. In questo modo, i tuoi clienti possono stabilire misure di sicurezza basate su IP, come i criteri di lista consentita.
Questa pagina è rivolta agli esperti di networking che progettano e progettano la rete per la propria organizzazione, nonché installano, configurano e supportano le apparecchiature di rete. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività utente comuni di GKE Enterprise.
Il gateway NAT in uscita viene abilitato utilizzando due risorse personalizzate. Per un determinato
suo spazio dei nomi, la risorsa personalizzata NetworkGatewayGroup
specifica gli indirizzi IP dinamici
che possono essere configurati sull'interfaccia di rete di un Nodo scelto per fungere da gateway. La risorsa personalizzata EgressNatPolicy
consente di
specificare i criteri di routing in uscita per controllare il traffico sul gateway in uscita.
Se non configuri un gateway NAT in uscita o se il traffico in uscita non soddisfa regole di selezione del traffico, traffico in uscita da un determinato pod a una destinazione all'esterno del cluster è mascherato dall'indirizzo IP del nodo in cui il pod in esecuzione. In questo scenario, non è garantito che tutto il traffico in uscita da un determinato pod abbia lo stesso indirizzo IP di origine o che venga mascherato nello stesso indirizzo IP del nodo.
Il gateway NAT in uscita è un'offerta di networking avanzata basata su Dataplane V2.
Come funziona il gateway NAT in uscita
La logica di selezione del traffico in uscita si basa su un selettore dello spazio dei nomi, un selettore di pod e un set di indirizzi IP di destinazione nella notazione a blocchi CIDR. Per illustrare il funzionamento del gateway NAT in uscita, consideriamo il flusso di un pacchetto da un pod a un consumatore esterno e la risposta corrispondente. Supponiamo che la subnet del nodo abbia indirizzi IP 192.168.1.0/24.
Il seguente diagramma mostra l'architettura di rete per il traffico in uscita tramite un nodo gateway.
Il flusso di pacchetti attraverso il gateway NAT in uscita potrebbe essere simile al seguente:
Il traffico in uscita viene generato da un pod con indirizzo IP
10.10.10.1
in una Nodo con indirizzo IP192.168.1.1
.L'indirizzo di destinazione del traffico è un endpoint esterno al cluster.
Se il traffico corrisponde a una regola in uscita, il programma eBPF instrada il traffico in uscita il traffico verso il nodo gateway, invece di effettuare direttamente il mascheramento con il nodo Indirizzo IP.
Il Nodo gateway riceve il traffico in uscita.
Il nodo gateway maschera l'indirizzo IP di origine del traffico di origine,
10.10.10.1
, con l'indirizzo IP in uscita di origine,192.168.1.100
specificato nella risorsa personalizzataEgressNATPolicy
.Il traffico restituito torna al nodo gateway con destinazione
192.168.1.100
.Il nodo gateway corrisponde al collegamento del traffico di ritorno a quello di il traffico in uscita originale e riscrive l'indirizzo IP di destinazione come
10.10.10.1
.10.10.10.1
viene trattato come traffico all'interno del cluster, indirizzato al nodo originale e re-inserito nel pod originale.
Configura indirizzi IP mobili per il traffico dei nodi
La risorsa personalizzata Gruppo di gateway di rete è un componente in bundle di Google Distributed Cloud. La risorsa gestisce un elenco di uno o più indirizzi IP variabili da utilizzare per il traffico in uscita dai nodi del tuo cluster. I Nodi partecipanti sono determinati dallo spazio dei nomi specificato. Il gruppo Network Gateway rende disponibile un indirizzo IP dinamico in qualsiasi momento su una base di miglior sforzo. Se un nodo che utilizza un indirizzo IP dinamico si arresta in modo anomalo, l'operatore di rete avanzato sposta l'indirizzo IP assegnato al nodo successivo disponibile. Verrà spostato anche tutto il traffico in uscita dei carichi di lavoro che utilizza quell'indirizzo IP.
Includi i dettagli del gruppo di gateway di rete (annotazione e specifica) nel cluster di configurazione quando si crea un nuovo cluster 1.30.100-gke.96.
Crea la risorsa personalizzata NetworkGatewayGroup
Puoi abilitare il gruppo di gateway di rete impostando il parametro
Campo spec.clusterNetwork.advancedNetworking
a true
nel file di configurazione del cluster quando crei un cluster come
mostrato nell'esempio che segue:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: cluster1
namespace: cluster-cluster1
spec:
clusterNetwork:
...
advancedNetworking: true
...
Quando crei la risorsa personalizzata NetworkGatewayGroup
, imposta il relativo spazio dei nomi su
lo spazio dei nomi del cluster e specificare un elenco di indirizzi IP mobili, 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
L'operatore di rete avanzata assegna gli IP flottanti ai nodi in base ai seguenti criteri:
- Subnet del nodo: l'indirizzo IP mobile deve corrispondere alla subnet del nodo.
- Ruolo del nodo (piano di controllo, worker): i nodi worker hanno la precedenza sui i nodi del piano di controllo durante l'assegnazione di indirizzi IP mobili.
- Se un nodo ha un indirizzo IP mobile: l'operatore assegna la priorità a nodi a cui non è già stato assegnato un IP mobile.
La mappatura indirizzo/nodo è disponibile nella sezione status
quando ottieni l'oggetto
NetworkGatewayGroup
. Tieni presente che l'oggetto NetworkGatewayGroup
si trova
nello spazio dei nomi kube-system
. Se un nodo gateway non è attivo, l'operatore di rete avanzato assegna gli indirizzi IP flottanti al nodo successivo disponibile.
Verifica la configurazione del gateway
Dopo aver applicato le modifiche alla configurazione del gateway, puoi utilizzare kubectl
per controllare lo stato del gateway e recuperare gli indirizzi IP dinamici
specificati per il gateway.
Utilizza il seguente comando per controllare lo stato di
NetworkGatewayGroup
e vedere come vengono allocati gli indirizzi IP flottanti:kubectl -n kube-system get networkgatewaygroups.networking.gke.io default -o yaml
La risposta per un cluster con due nodi,
worker1
eworker2
, potrebbe ha questo 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: nodes: worker1: Up worker2: Up // Or Down floatingIPs: 192.168.1.100: worker1 192.168.1.101: worker2 192.168.1.102: worker1
Impostare le regole di selezione del traffico
La risorsa personalizzata EgressNATPolicy
specifica le regole di selezione del traffico e assegna un indirizzo IP deterministico per il traffico in uscita che esce dal cluster.
Quando specifichi la risorsa personalizzata egress
(con almeno una regola),
destinationCIDRs
e egressSourceIP
sono tutti obbligatori.
Utilizza kubectl apply
per creare la risorsa personalizzata EgressNATPolicy
. La
le seguenti sezioni forniscono dettagli ed esempi per definire la specifica.
Specifica le regole di routing in uscita
La risorsa personalizzata EgressNatPolicy
ti consente di specificare le seguenti regole per
per il traffico in uscita:
Devi specificare una o più regole di selezione del traffico in uscita nella
egress
sezione.- Ogni regola è composta da un
podSelector
e da unnamespaceSelector
. - La selezione si basa su un'etichetta dello spazio dei nomi,
namespaceSelector.matchLabels.user
, e un'etichetta del pod,podSelector.matchLabels.role
. - Se un pod corrisponde a una delle regole (la corrispondenza utilizza una relazione OR), viene selezionato per il traffico in uscita.
- Ogni regola è composta da un
Specifica gli indirizzi di destinazione consentiti nella sezione
destinationCIDRs
.destinationCIDRs
richiede un elenco di blocchi CIDR.- Se il traffico in uscita da un pod ha un indirizzo IP di destinazione che nell'intervallo di uno qualsiasi dei blocchi CIDR specificati, viene selezionata e il traffico in uscita.
Nell'esempio seguente, il traffico in uscita da un pod è consentito quando vengono soddisfatti i seguenti criteri:
- Il pod è etichettato con
role: frontend
. - Il pod si trova in uno spazio dei nomi etichettato come
user: alice
ouser: paul
. - Il pod comunica con gli indirizzi IP nel blocco CIDR
8.8.8.0/24
.
kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
name: egress
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
Per ulteriori informazioni sull'uso delle etichette, consulta Etichette e selettori nella documentazione di Kubernetes.
Ottieni un indirizzo IP di origine per il traffico in uscita
La risorsa personalizzata EgressNATPolicy
(criterio) utilizza i valori gatewayRef.name
e
gatewayRef.namespace
per trovare un oggetto NetworkGatewayGroup
(gateway).
Il criterio utilizza uno degli indirizzi IP mobili del gateway come IP di origine
per il traffico in uscita. Se nell'elenco sono presenti più indirizzi IP mobili
gateway corrispondente, il criterio utilizza il primo indirizzo IP nell'elenco floatingIPs
e ignora qualsiasi altro indirizzo IP. Per il
gateway di esempio, il primo
indirizzo nell'elenco floatingIPs
è 192.168.1.100
. Con campi non validi o
valori nella sezione gatewayRef
comporterà l'impossibilità di applicare il criterio
.
Più criteri di uscita e più oggetti gateway
Come descritto nella sezione precedente, ogni oggetto egressNATPolicy
(criterio)
utilizza il primo indirizzo IP nell'elenco floatingIPs
dell'oggetto gateway che
corrisponde a gatewayRef.name
e gatewayRef.namespace
. Puoi creare più criteri e, se intendi utilizzare indirizzi IP diversi, devi creare più oggetti NetworkGatewayGroup
e farvi riferimento rispettivamente.
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 ogni indirizzo IP dinamico. In genere, ogni criterio di uscita deve avere un oggetto gateway corrispondente per garantire l'allocazione dell'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 facciano riferimento agli oggetti gateway, ad esempio come
gateway1
creato nel passaggio precedente:kind: EgressNATPolicy apiVersion: networking.gke.io/v1 metadata: name: egress1 spec: ... gatewayRef: name: gateway1 namespace: kube-system --- kind: EgressNATPolicy apiVersion: networking.gke.io/v1 metadata: name: egress2 spec: ... gatewayRef: name: gateway2 namespace: kube-system --- kind: EgressNATPolicy apiVersion: networking.gke.io/v1 metadata: name: egress3 spec: ... gatewayRef: name: gateway3 namespace: kube-system
(Facoltativo) Specifica i nodi su cui posizionare gli indirizzi IP mobili
Le risorse NetworkGatewayGroup
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 dei nodi corrisponde ai nodi con l'etichetta specificata e solo questi nodi vengono presi in considerazione per l'hosting di un indirizzo IP dinamico. Se specifichi più selezionatori, la loro logica è additiva, quindi un nodo deve corrispondere a ogni etichetta per essere preso in considerazione per l'hosting di un indirizzo IP dinamico. 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.
Regole di selezione del traffico in uscita e criteri di rete
Il gateway NAT in uscita è compatibile con le API dei criteri di rete. I criteri di rete vengono valutati per primi e hanno la precedenza sulle regole di selezione del traffico del gateway NAT di uscita. Ad esempio, se il traffico in uscita attiva un criterio di rete che comporta l'eliminazione del pacchetto, le regole del gateway in uscita non lo controlleranno. Solo quando il criterio di rete consente l'uscita del pacchetto, le regole di selezione del traffico in uscita vengono valutate per decidere come gestire il traffico, utilizzando il gateway NAT in uscita o mascherando direttamente l'indirizzo IP del nodo in cui è in esecuzione il pod.
Limitazioni
Le limitazioni attuali del gateway NAT in uscita includono:
Il gateway NAT in uscita è abilitato solo per la modalità IPv4.
Gli indirizzi IP in uscita devono trovarsi nello stesso dominio di livello 2 con IP nodo indirizzi IP esterni.
Gli upgrade non sono supportati per i cluster configurati per utilizzare la versione di anteprima del gateway NAT in uscita. Per Google Distributed Cloud release 1.30.0 e successive, Il gateway NAT è in modalità Anteprima solo su Ubuntu 18.04. L'utilizzo di questa funzionalità non prevede alcun costo durante l'anteprima.