Configura un gateway NAT in uscita per la comunicazione esterna

Version 1.9 (unsupported)

• Ultimi
• Versione 1.16
• Versioni precedenti (non supportate)

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Questo documento descrive come configurare un gateway NAT in uscita per Anthos clusters on bare metal. Questo gateway fornisce un routing deterministico permanente per il traffico in uscita dai tuoi cluster. Quando esegui carichi di lavoro con traffico utente in uscita (al di fuori dei tuoi cluster), i tuoi clienti vogliono identificare questo traffico utilizzando alcuni indirizzi IP deterministici. In questo modo i tuoi clienti possono stabilire misure di sicurezza basate su IP, come i criteri relativi alla lista consentita. Non è previsto alcun costo per l'utilizzo di questa funzionalità in anteprima.

Il gateway NAT in uscita viene abilitato utilizzando due risorse personalizzate. Per un determinato spazio dei nomi, la risorsa personalizzata AnthosNetworkGateway 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.

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.

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

Il controller Anthos Gateway Gateway è un componente in bundle di Anthos clusters on bare metal. Il controller 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. Gateway di rete Anthos rende disponibile un indirizzo IP mobile in qualsiasi momento in base ai migliori sforzi. Se un nodo che utilizza un indirizzo IP mobile non è disponibile, Anthos Network Gateway sposta l'indirizzo IP assegnato al successivo nodo disponibile. Verrà spostato anche tutto il traffico in uscita del carico di lavoro che utilizza quell'indirizzo IP.

Includi i dettagli di Anthos Network Gateway (annotazione e specifiche) nel file di configurazione del cluster quando crei un nuovo cluster 1.8.0.

Nota: la funzionalità del gateway NAT in uscita è solo in anteprima. Puoi abilitare Gateway di rete Anthos per un cluster, ma non supportiamo gli upgrade per i cluster che lo hanno abilitato. Per questo motivo, non è consigliabile eseguire l'upgrade dei cluster di produzione esistenti per abilitare questa funzionalità, perché potrebbe impedirti di eseguire upgrade futuri.

Crea la risorsa personalizzata AnthosNetworkGateway

Puoi abilitare il gateway Anthos di rete utilizzando l'annotazione baremetal.cluster.gke.io/enable-anthos-network-gateway nel file di configurazione del cluster quando crei un cluster. Imposta l'annotazione su true come mostrato nell'esempio seguente:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  annotations:
    baremetal.cluster.gke.io/enable-anthos-network-gateway: "true"
  name: cluster1
  namespace: cluster-cluster1

Quando crei la risorsa personalizzata AnthosNetworkGateway, 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:

Nota: l'operatore di cluster crea una copia del controller AnthosNetworkGateway nello spazio dei nomi kube-system. Questa copia del controller AnthosNetworkGateway nello spazio dei nomi kube-system è responsabile dell'allocazione degli indirizzi IP mobili ai nodi gateway.

kind: AnthosNetworkGateway
apiVersion: networking.gke.io/v1alpha1
metadata:
  namespace: cluster-cluster1
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102

Il numero di indirizzi IP mobile specificati influisce sull'affidabilità del cluster. Ad esempio, un gateway NAT in uscita funzionerà con un solo indirizzo IP mobile specificato, ma un errore del nodo potrebbe causare interruzioni del traffico. Se aggiungi altri indirizzi IP mobili, AnthosNetworkGateway li assegna e li sposta secondo necessità. Ti consigliamo di fornire almeno due indirizzi IP mobili per il dominio L2 utilizzato nel cluster.

Il controller 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 (master, worker): i nodi worker hanno la precedenza sui nodi master nell'assegnazione degli indirizzi IP mobili.
• Se un nodo ha un indirizzo IP mobile: il controller dà la 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 AnthosNetworkGateway. Tieni presente che l'oggetto AnthosNetworkGateway si trova nello spazio dei nomi kube-system. Se un nodo gateway non è attivo, il controller di AnthosNetworkGateway assegna gli indirizzi IP mobili al nodo successivo disponibile.

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 AnthosNetworkGateway e verificare l'allocazione degli indirizzi IP mobili:

   kubectl -n kube-system get anthosnetworkgateway.networking.gke.io default -oyaml

   La risposta di un cluster con due nodi, worker1 e worker2, potrebbe avere il seguente aspetto:

   kind: AnthosNetworkGateway
   apiVersion: networking.gke.io/v1alpha1
   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
   

2. Utilizza il seguente comando per recuperare lo stato AnthosNetworkGateway e l'allocazione degli indirizzi per un nodo specifico.

   kubectl -n kube-system get anthosnetworkgatewaynode.networking.gke.io NODE_NAME -oyaml

   Sostituisci NODE_NAME con il nome del nodo/macchina specifico che vuoi ispezionare.

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 compresi nell'intervallo 8.8.8.0/24.

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1alpha1
metadata:
  name: egress
spec:
  egress:
  - namespaceSelector:
      matchLabels:
        user: alice
    podSelector:
      matchLabels:
        role: frontend
  - namespaceSelector:
      matchLabels:
        user: paul
    podSelector:
      matchLabels:
        role: frontend
  destinationCIDRs:
  - 8.8.8.0/24
  egressSourceIP: 192.168.1.100

Per ulteriori informazioni sull'utilizzo delle etichette, consulta Etichette e selettori nella documentazione di Kubernetes.

Specifica un indirizzo IP di origine per il traffico in uscita

Specifica l'indirizzo IP di origine che vuoi utilizzare nel campo egressSourceIP. L'indirizzo IP di origine deve corrispondere a uno degli indirizzi IP mobili specificati nella risorsa personalizzata AnthosNetworkGateway.

Utilizzando l'esempio EgressNATPolicy della sezione precedente, se vengono soddisfatti i criteri di selezione e indirizzo IP di destinazione del pod, il traffico in uscita dal pod viene convertito in 192.168.1.100 utilizzando SNAT.

Affinché la route venga accettata, l'indirizzo egressSourceIP deve trovarsi nella stessa subnet dell'IP del nodo del gateway. Se l'indirizzo egressSourceIP è sconosciuto (non assegnato) al nodo gateway, la richiesta di route non può essere soddisfatta. In questo caso, riceverai un errore UnknownEgressIP negli eventi Kubernetes.

Utilizza il seguente comando kubectl per stampare gli eventi per l'oggetto EgressNATPolicy:

kubectl describe EgressNATPolicy egress

Se esistono più RP EgressNATPolicy, ognuna deve avere un indirizzo egressSourceIP diverso. Per evitare conflitti, coordinati con il team di sviluppo.

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.

• Per questa anteprima, gli indirizzi IP in uscita devono trovarsi nello stesso dominio L2 con gli indirizzi IP dei nodi.

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