Questo documento descrive come configurare un gateway NAT in uscita per GKE su Bare Metal. Questo gateway fornisce indirizzi IP SNAT permanenti e deterministici per il traffico in uscita dai cluster. Quando esegui carichi di lavoro che hanno traffico utente in uscita (all'esterno dei cluster), i tuoi clienti vogliono identificare questo traffico utilizzando alcuni indirizzi IP deterministici. Ciò consente ai tuoi clienti di stabilire misure di sicurezza basate sull'IP, come l'inserimento dei criteri nella lista consentita.
Il gateway NAT in uscita viene abilitato utilizzando due risorse personalizzate. Per un determinato spazio dei nomi, la risorsa personalizzata NetworkGatewayGroup specifica indirizzi IP mobili che possono essere configurati nell'interfaccia di rete di un Nodo che viene scelto come gateway. La risorsa personalizzata EgressNatPolicy consente di specificare 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 le regole di selezione del traffico, il traffico in uscita da un determinato pod a una destinazione all'esterno del cluster viene mascherato all'indirizzo IP del nodo su cui è in esecuzione il pod. In questo scenario, non è garantito che tutto il traffico in uscita da un determinato pod abbia lo stesso indirizzo IP di origine o venga mascherato con lo 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 intervalli di indirizzi IP di destinazione nella notazione a blocchi CIDR. Per illustrare come funziona il gateway NAT in uscita, consideriamo il flusso di un pacchetto da un pod a un consumer esterno e la risposta corrispondente. Supponiamo che la subnet del nodo abbia indirizzi IP nel blocco CIDR 192.168.1.0/24.
Il seguente diagramma mostra l'architettura di rete per il traffico in uscita attraverso un nodo gateway.
Il flusso di pacchetti attraverso il gateway NAT in uscita potrebbe avere il seguente aspetto:
Il traffico in uscita viene generato da un pod con indirizzo IP
10.10.10.1in un 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 verso il Nodo gateway, invece di mascherarlo direttamente con l'indirizzo IP del nodo.
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.100specificato nella risorsa personalizzataEgressNATPolicy.Il traffico di ritorno torna al nodo gateway con destinazione
192.168.1.100.Il nodo gateway corrisponde alla connessione del traffico di ritorno con quello del traffico in uscita originale e riscrive l'indirizzo IP di destinazione come
10.10.10.1.10.10.10.1viene trattato come traffico nel cluster, instradato al nodo originale e restituito al pod originale.
Configurare indirizzi IP mobili per il traffico dei nodi
La risorsa personalizzata Gruppo di gateway di rete è un componente in bundle di GKE su Bare Metal. La risorsa gestisce un elenco di uno o più indirizzi IP mobili da utilizzare per il traffico in uscita dai nodi nel cluster. I nodi partecipanti sono determinati dallo spazio dei nomi specificato. Il gruppo di gateway di rete rende disponibile un indirizzo IP mobile in qualsiasi momento in base al criterio del "best effort". Se un Nodo che utilizza un indirizzo IP mobile non funziona, l'operatore di rete avanzato sposta l'indirizzo IP assegnato al successivo Nodo 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 file di configurazione del cluster quando crei un nuovo cluster 1.14.11.
Crea la risorsa personalizzata NetworkGatewayGroup
Puoi abilitare il gruppo di gateway di rete impostando il campo spec.clusterNetwork.advancedNetworking su true nel file di configurazione del cluster quando crei un cluster, come mostrato nell'esempio seguente:
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 sullo spazio dei nomi del cluster e specifica 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 avanzato assegna IP mobili 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 nodi del piano di controllo quando assegnano indirizzi IP mobili.
- Se un nodo ha un indirizzo IP mobile: l'operatore dà la priorità alle assegnazioni ai nodi a cui non è già stato assegnato un IP mobile.
La mappatura di 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 mobili al successivo nodo disponibile.
Verifica la configurazione del gateway
Dopo aver applicato le modifiche alla configurazione del gateway, puoi utilizzare kubectl per verificare lo stato del gateway e recuperare gli indirizzi IP mobili specificati per il gateway.
Utilizza il seguente comando per verificare lo stato di
NetworkGatewayGroupe vedere come vengono allocati gli indirizzi IP mobili:kubectl -n kube-system get networkgatewaygroups.networking.gke.io default -o yamlLa risposta per un cluster con due nodi,
worker1eworker2, potrebbe essere simile a questa: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 per la 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 lascia il cluster.
Quando specifichi la RP, sono obbligatori egress (con almeno una regola), destinationCIDRs
e egressSourceIP.
Utilizza kubectl apply per creare la risorsa personalizzata EgressNATPolicy. Le seguenti sezioni forniscono dettagli ed esempi per la definizione della specifica.
Specifica le regole di routing in uscita
La risorsa personalizzata EgressNatPolicy consente di specificare le seguenti regole per il traffico in uscita:
Devi specificare una o più regole di selezione del traffico in uscita nella sezione
egress.- Ogni regola è composta da un
podSelectore 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 qualsiasi 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.destinationCIDRsrichiede un elenco di blocchi CIDR.- Se il traffico in uscita da un pod ha un indirizzo IP di destinazione che rientra nell'intervallo di uno qualsiasi dei blocchi CIDR specificati, viene selezionato per 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: aliceouser: 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'utilizzo delle etichette, consulta Etichette e selettori nella documentazione di Kubernetes.
Ottieni un indirizzo IP di origine per il traffico in uscita
La risorsa (criterio) personalizzata EgressNATPolicy 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 indirizzo IP di origine per il traffico in uscita. Se nel gateway corrispondente sono presenti più indirizzi IP mobili, 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. La presenza di campi o valori non validi nella sezione gatewayRef comporterà la mancata applicazione dell'oggetto criterio.
Più criteri in uscita e più oggetti gateway
Come descritto nella sezione precedente, ogni oggetto (criterio) egressNATPolicy 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.
Un limite di NetworkGatewayGroup in GKE su Bare Metal per questa release
è che solo l'oggetto "predefinito" viene riconciliato per le allocazioni di IP mobili.
Inoltre, solo il gateway predefinito segnala lo stato di allocazione per tutti gli indirizzi IP mobili.
Il gateway predefinito è definito da NetworkGatewayGroup con il nome default
nello spazio dei nomi kube-system. Di conseguenza, quando crei più oggetti gateway, devi assicurarti che gli indirizzi IP nei gateway non predefiniti siano specificati anche nel manifest del gateway predefinito. In caso contrario, non verranno allocati come IP mobili e quindi non potranno essere utilizzati dall'oggetto EgressNATPolicies.
Per configurare più criteri in uscita e più oggetti gateway:
Verifica l'oggetto gateway predefinito (
name: default) conkubectlper ottenere lo stato di allocazione degli indirizzi IP mobili:kubectl -n kube-system get NetworkGatewayGroup.networking.gke.io default -o yamlLa risposta per un cluster con due nodi,
worker1eworker2, potrebbe essere simile a questa: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: worker1Dopo aver verificato lo stato del gateway predefinito, crea oggetti gateway aggiuntivi nello spazio dei nomi
kube-systemper "monitorare" ogni IP mobile.Tieni presente che questi nuovi oggetti gateway non segnalano lo stato di allocazione, che si trova nel gateway
default.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.102Crea più criteri che fanno riferimento agli oggetti gateway "secondari", ad esempio
gateway1creati 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
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 in 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 controlleranno il pacchetto. Solo quando il criterio di rete consente il pacchetto in uscita, le regole di selezione del traffico in uscita vengono valutate per decidere come viene gestito il traffico, utilizzando il gateway NAT in uscita o mascherando direttamente l'indirizzo IP del Nodo su cui è in esecuzione il pod.
Limitazioni
Le attuali limitazioni per il 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 gli indirizzi IP del nodo.
Gli upgrade non sono supportati per i cluster che sono stati configurati per utilizzare l'anteprima del gateway NAT in uscita. Per GKE su Bare Metal versione 1.14.0 e successive, il gateway NAT in uscita è in anteprima solo su Ubuntu 18.04. Non è previsto alcun costo per usare questa funzionalità mentre è in anteprima.