Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Configurazione di un gateway NAT in uscita

Questo documento descrive come configurare un gateway NAT in uscita per Google Distributed Cloud. Questo gateway fornisce indirizzi IP SNAT deterministici e persistenti per il traffico in uscita dai cluster. Quando esegui workload con traffico utente in uscita (al di fuori dei cluster), i tuoi clienti vogliono identificare questo traffico utilizzando alcuni indirizzi IP deterministici. In questo modo, i clienti possono stabilire misure di sicurezza basate su IP, come i criteri di lista consentita.

Questa pagina è rivolta agli specialisti di Networking che progettano e realizzano l'architettura di rete per la loro organizzazione e che installano, configurano e supportano le apparecchiature di rete. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività utente GKE comuni.

Il gateway NAT in uscita viene abilitato utilizzando due risorse personalizzate. Per un determinato spazio dei nomi, la risorsa personalizzata NetworkGatewayGroup specifica gli indirizzi IP mobili 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 le regole di selezione del traffico, il traffico in uscita da un determinato pod a una destinazione al di fuori del cluster viene mascherato con l'indirizzo IP del nodo in 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 che venga mascherato con lo stesso indirizzo IP del nodo.

Il gateway NAT in uscita è un'offerta di rete 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 insieme di intervalli di indirizzi IP di destinazione nella notazione a blocchi CIDR. Per illustrare il funzionamento del gateway NAT in uscita, considera il flusso di un pacchetto da un pod a un consumer esterno e la risposta corrispondente. Supponi 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 tramite un nodo gateway.

Diagramma del gateway NAT in uscita per Google Distributed Cloud

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 un nodo con indirizzo IP 192.168.1.1.

L'indirizzo di destinazione del traffico è un endpoint al di fuori del cluster.
Se il traffico corrisponde a una regola in uscita, il programma eBPF instrada il traffico in uscita al nodo gateway, anziché 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.100, specificato nella risorsa personalizzata EgressNATPolicy.
Il traffico di ritorno torna al nodo gateway con destinazione 192.168.1.100.
Il nodo gateway associa il conntrack del traffico di ritorno a quello del traffico in uscita originale e riscrive l'indirizzo IP di destinazione come 10.10.10.1.
10.10.10.1 viene trattato come traffico in-cluster, instradato al nodo originale e restituito al pod originale.

Configurare gli indirizzi IP mobili per il traffico dei nodi

La risorsa personalizzata Network Gateway Group è un componente in bundle di Google Distributed Cloud. La risorsa gestisce un elenco di uno o più indirizzi IP mobili da utilizzare per il traffico in uscita dai nodi del cluster. I nodi partecipanti sono determinati dallo spazio dei nomi specificato. Il gruppo di gateway di rete rende disponibile un indirizzo IP mobile in ogni momento, in base al principio del best-effort. Se un nodo che utilizza un indirizzo IP mobile non è attivo, l'operatore di rete avanzata sposta l'indirizzo IP assegnato al nodo successivo disponibile. Anche tutto il traffico in uscita del workload che utilizza questo indirizzo IP verrà spostato.

Includi i dettagli del gruppo di gateway di rete (annotazione e specifica) nel file di configurazione del cluster quando crei un nuovo cluster 1.35.100.

Creare la risorsa personalizzata `NetworkGatewayGroup`

Per abilitare il gruppo di gateway di rete, imposta 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 lo 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 avanzata assegna gli 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 (control plane, worker): i nodi worker hanno la precedenza sui nodi del control plane quando vengono assegnati indirizzi IP mobili.
Se un nodo ha un indirizzo IP mobile: l'operatore assegna la priorità ai nodi a cui non è già stato assegnato un indirizzo IP mobile.

Il mapping da indirizzo a nodo è disponibile nella sezione status quando recuperi 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 avanzata assegna gli indirizzi IP mobili al nodo successivo disponibile.

Verificare 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 mobili specificati per il gateway.

Utilizza il seguente comando per controllare lo stato di NetworkGatewayGroup e vedere come vengono allocati gli indirizzi IP mobili:

kubectl -n kube-system get networkgatewaygroups.networking.gke.io default -o yaml

La risposta per un cluster con due nodi, worker1 e worker2, potrebbe essere simile alla seguente:

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 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. Le sezioni seguenti forniscono dettagli ed esempi per la definizione della specifica.

Specificare 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 è costituita da un podSelector e un namespaceSelector.
- 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.
Specifica gli indirizzi di destinazione consentiti nella sezione destinationCIDRs.
- destinationCIDRs accetta 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 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: alice o user: 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 saperne di più sull'utilizzo delle etichette, consulta Etichette e selettori nella documentazione di Kubernetes.

Ottenere 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 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 tutti gli altri indirizzi IP. Per il gateway di esempio, il primo indirizzo nell'elenco floatingIPs è 192.168.1.100. Se nella sezione gatewayRef sono presenti campi o valori non validi, l'applicazione dell'oggetto criterio non riuscirà.

Più criteri in 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, utilizza lo stesso 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 mobile. In genere, ogni criterio in uscita deve avere un oggetto gateway corrispondente per garantire l'allocazione dell'indirizzo IP corretto.

Quindi, 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 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) Specificare i nodi su cui inserire gli indirizzi IP mobili

Le risorse NetworkGatewayGroup supportano i selettori di nodi. Per specificare un sottoinsieme di nodi da considerare 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 di 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 considerato per l'hosting di un indirizzo IP mobile. Se non sono presenti molti nodi con etichette corrispondenti, un selettore di nodi può ridurre le qualità di alta affidabilità (HA) del posizionamento degli indirizzi IP mobili.

Failover rapido per un gateway NAT in uscita ad alta affidabilità

Per i cluster versione 1.34 e successive, puoi configurare il gateway NAT in uscita con il failover rapido. Se hai più indirizzi IP mobili e configuri il failover rapido, ottieni un'uscita ad alta affidabilità. Questa funzionalità offre una migliore distribuzione del carico per il traffico in uscita e un failover più rapido per ridurre al minimo i tempi di inattività. Anziché fare affidamento su un singolo nodo gateway alla volta (attivo-standby), il cluster distribuisce il traffico in uscita su più nodi gateway e su tutti gli indirizzi IP mobili configurati in una risorsa NetworkGatewayGroup.

Questo modello attivo-attivo presenta i seguenti vantaggi principali:

Distribuzione del carico: il traffico in uscita da diversi endpoint di origine, come i pod, si distribuisce su tutti i nodi gateway disponibili, il che riduce il carico su un singolo nodo e aumenta la larghezza di banda in uscita totale disponibile.
Failover rapido: se un nodo gateway in uscita non funziona, il traffico viene reindirizzato automaticamente ai nodi integri rimanenti. L'obiettivo è che il failover del traffico sia rapido. Mentre le connessioni esistenti sul nodo non funzionante vengono interrotte, le nuove connessioni vengono stabilite immediatamente tramite altri gateway, riducendo al minimo i tempi di inattività.

Differenze principali

La configurazione del gateway NAT in uscita per il failover rapido modifica il funzionamento del gateway NAT in uscita:

Capacità	Attivo-standby (impostazione predefinita)	Attivo-attivo (failover rapido)
Utilizzo dell'IP mobile	Il `EgressNATPolicy` utilizza solo il primo indirizzo IP mobile in `NetworkGatewayGroup`.	Tutti gli indirizzi IP mobili elencati in the `NetworkGatewayGroup` distribuiscono attivamente il traffico in uscita.
Failover	Se il nodo gateway non funziona, lo stesso indirizzo IP mobile viene spostato su un altro nodo, il che può causare l'interruzione del traffico.	Se un nodo gateway non funziona, il traffico viene reindirizzato a un indirizzo IP integro diverso su un altro nodo. Le nuove connessioni vengono instradate immediatamente tramite i gateway integri, mentre le connessioni stateful esistenti sul nodo non funzionante vengono terminate.
Traffico	Tutto il traffico per un determinato criterio passa attraverso un singolo nodo gateway.	Il traffico viene distribuito su più nodi gateway in base a un hashing coerente dell'endpoint di origine, ad esempio un pod.

Configurare il failover rapido

La configurazione della funzionalità prevede due passaggi principali:

Specifica più indirizzi IP mobili.

Configura NetworkGatewayGroup con un pool di almeno due indirizzi IP mobili per sfruttare i vantaggi dell'alta affidabilità e della distribuzione del carico. L'utilizzo di più indirizzi IP mobili migliora l'affidabilità e la velocità effettiva in uscita.

Ecco una configurazione di esempio:

apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: egress-gateways
  namespace: cluster-admin
spec:
  nodeSelector:
    # Selects nodes that are designated as egress gateways
    node-role.kubernetes.io/egress: ""
  floatingIPs:
  - "192.168.1.100"
  - "192.168.1.101"
  - "192.168.1.102"

Per abilitare il failover rapido, aggiungi l'annotazione networking.gke.io/egressnat-ha: "enable" alla risorsa personalizzata EgressNATPolicy:

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress
  annotations:
    networking.gke.io/egressnat-ha: "enable"
spec:
  ...

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 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 mascherandolo direttamente con l'indirizzo IP del nodo in cui è in esecuzione il pod.

Limitazioni

Le limitazioni attuali 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 dei nodi.
Se configuri il bilanciamento del carico BGP standard insieme a Egress NAT e utilizzi l'API GKE On-Prem per gestire i cluster (con Terraform, la Google Cloud console o l'interfaccia a riga di comando gcloud), i selettori peer BGP non sono supportati. Questa mancanza di supporto può causare l'utilizzo casuale di IP locali errati per il peering da parte delle sessioni BGP, il che comporta un errore di peering BGP. Per una soluzione alternativa, consulta Configurare i bilanciatori del carico in bundle con BGP: limitazione del selettore BGP.