Configurazione di un gateway NAT in uscita

Questo documento descrive come configurare un gateway NAT in uscita per Anthos clusters on bare metal. Questo gateway fornisce indirizzi IP SNAT deterministici persistenti per il traffico in uscita dai tuoi cluster. Quando esegui carichi di lavoro che hanno traffico di utenti in uscita (all'esterno 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 sull'IP, come i criteri relativi alla lista consentita. L'utilizzo di questa funzionalità è disponibile in anteprima senza costi aggiuntivi.

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 per il traffico in uscita sul gateway.

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 verso una destinazione esterna al tuo cluster viene mascherato dall'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 mascherato dallo 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 di spazio dei nomi, un selettore di pod e un insieme di indirizzi IP di destinazione in notazione a blocchi CIDR. Per illustrare il funzionamento del 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 dei nodi 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.

Diagramma del gateway NAT in uscita per Anthos clusters on bare metal

Il flusso dei pacchetti attraverso il gateway NAT in uscita potrebbe avere il seguente aspetto:

  1. 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 esterno al cluster.

  2. Se il traffico corrisponde a una regola in uscita, il programma eBPF lo instrada al nodo gateway, invece di mascherarlo direttamente con l'indirizzo IP del nodo.

  3. Il nodo gateway riceve il traffico in uscita.

  4. Il nodo gateway maschera l'indirizzo IP di origine del traffico di origine, 10.10.10.1, con l'indirizzo IP in uscita da 192.168.1.100, specificato nella risorsa personalizzata EgressNATPolicy.

  5. Il traffico di ritorno torna al nodo gateway con destinazione 192.168.1.100.

  6. Il nodo gateway corrisponde alla connessione del traffico di ritorno a quello del traffico in uscita originale e riscrive l'indirizzo IP di destinazione come 10.10.10.1.

  7. 10.10.10.1 viene considerato come traffico nel cluster, instradato al nodo originale e restituito al pod originale.

Configura indirizzi IP mobili per il traffico dei nodi

La risorsa personalizzata Group Gateway Group è un componente in bundle di Anthos clusters on 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 mette a disposizione il migliore indirizzo IP mobile in qualsiasi momento. Se un nodo che utilizza un indirizzo IP mobile non è disponibile, l'operatore di rete avanzato sposta l'indirizzo IP assegnato al nodo disponibile successivo. Verrà spostato anche tutto il traffico in uscita del carico di lavoro che utilizza quell'indirizzo IP.

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

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 suo 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 gli IP mobili ai nodi in base ai seguenti criteri:

  • Subnet nodo: l'indirizzo IP mobile deve corrispondere alla subnet del nodo.
  • Ruolo 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à priorità alle assegnazioni ai nodi a cui non è già assegnato un IP mobile.

La mappatura dell'indirizzo/nodo è disponibile nella sezione status quando si ottiene 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 nodo disponibile successivo.

Verifica la configurazione del gateway

Dopo aver applicato le modifiche alla configurazione gateway, puoi utilizzare kubectl per controllare lo stato del gateway e recuperare gli indirizzi IP mobili specificati per il gateway.

  1. Utilizza il seguente comando per verificare lo stato di NetworkGatewayGroup e verificare l'allocazione degli indirizzi IP mobili:

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

    La risposta di un cluster con due nodi, worker1 e worker2, potrebbe avere il seguente 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 lascia il cluster. Quando specifichi la RP, sono richieste egress (con almeno una regola), destinationCIDRs e egressSourceIP.

Usa kubectl apply per creare la risorsa personalizzata EgressNATPolicy. Le seguenti sezioni forniscono dettagli ed esempi per la definizione della specifica.

Specificare le regole di routing per il traffico in uscita

La risorsa personalizzata EgressNatPolicy consente di specificare le regole seguenti per il traffico in uscita:

  • Devi specificare una o più regole di selezione del traffico in uscita nella sezione egress.

    • Ogni regola è composta da podSelector e namespaceSelector.
    • La selezione si basa su un'etichetta dello spazio dei nomi, namespaceSelector.matchLabels.**user** e un'etichetta 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.

  • Specifica gli indirizzi di destinazione consentiti nella sezione destinationCIDRs.

    • destinationCIDRs prende 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 sono soddisfatti i seguenti criteri:

  • Il pod è etichettato con role: frontend.
  • Il pod si trova in uno spazio dei nomi con l'etichetta user: alice o user: paul.
  • Il pod comunica con gli indirizzi IP nel blocco CIDR di 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.

Richiedi 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 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à l'applicazione dell'oggetto criterio non riuscita.

Più criteri in uscita e 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 fare riferimento a ciascuno rispettivamente.

Un limite di NetworkGatewayGroup nei Anthos clusters on bare metal per questa release è che solo l'oggetto "predefinito" viene riconciliato per le allocazioni di IP mobili. Inoltre, solo il gateway predefinito indica lo stato di allocazione di tutti gli indirizzi IP mobili.

Il gateway predefinito è definito da NetworkGatewayGroup con il nome default nello spazio dei nomi kube-system. Pertanto, quando crei più oggetti gateway, devi assicurarti che anche gli indirizzi IP nei gateway non predefiniti siano specificati nel manifest del gateway predefinito. In caso contrario, non verranno assegnati come IP mobili e, pertanto, non potranno essere utilizzati dall'oggetto EgressNATPolicies.

Per configurare più criteri in uscita e più oggetti gateway:

  1. Verifica l'oggetto gateway predefinito (name: default) con kubectl per ottenere lo stato di allocazione degli indirizzi IP mobili:

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

    La risposta di un cluster con due nodi, worker1 e worker2, potrebbe avere il seguente 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:
  ...
  floatingIPs:
    192.168.1.100: worker1
    192.168.1.101: worker2
    192.168.1.102: worker1

  2. Dopo aver verificato lo stato del gateway predefinito, crea ulteriori oggetti gateway nello spazio dei nomi kube-system per "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.102

  3. Crea più criteri che fanno riferimento agli oggetti gateway "secondari", 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

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 prima 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 causa 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 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 per questa anteprima.

  • Gli upgrade non sono supportati per i cluster configurati per l'utilizzo dell'anteprima del gateway NAT in uscita.