Configura un gateway NAT in uscita per la comunicazione esterna

Version 1.8 (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 i cluster Anthos su Bare Metal. Questo gateway fornisce il routing deterministico permanente per il traffico in uscita dai 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 clienti possono stabilire misure di sicurezza basate sull'IP, come i criteri della lista consentita. Non è previsto alcun costo per utilizzare questa funzionalità mentre è in anteprima.

Nota: questa funzionalità non funziona con i cluster Anthos su Bare Metal versioni 1.8.3.

Il gateway NAT in uscita viene abilitato utilizzando due risorse personalizzate. Per un determinato spazio dei nomi, la risorsa personalizzata AnthosNetworkGateway specifica indirizzi IP mobili che possono essere configurati nell'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 esterna al cluster viene nascosto all'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 si attenga allo 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 set 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 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 essere simile al seguente:

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 al di fuori del cluster.

2. Se il traffico corrisponde a una regola in uscita, il programma eBPF lo instrada al nodo gateway, invece di eseguire l'accesso diretto all'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 del codice sorgente, 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 con quella 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 in-cluster, instradato al nodo originale e restituito al pod originale.

Configurazione degli indirizzi IP mobili per il traffico dei nodi

Il controller Anthos Network Gateway è un componente integrato in cluster Anthos su 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. Il gateway Anthos Network mette a disposizione un indirizzo IP mobile sempre disponibile in base al criterio migliore. Se un nodo che utilizza un indirizzo IP mobile non funziona, il gateway di rete Anthos sposta l'indirizzo IP assegnato al nodo successivo 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 può essere utilizzata solo in anteprima. Puoi abilitare il gateway di rete Anthos per un cluster, ma non supportiamo gli upgrade per i cluster in cui è abilitato. Per questo motivo sconsigliamo di eseguire l'upgrade dei cluster di produzione esistenti per abilitare questa funzionalità, poiché potrebbe impedirti di eseguire upgrade futuri.

Creazione della risorsa personalizzata AnthosNetworkGateway in corso...

Puoi abilitare il gateway di rete Anthos 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, impostane lo 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 del 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 mobili specificati influisce sull'affidabilità del cluster. Ad esempio, un gateway NAT in uscita funziona con un solo indirizzo IP mobile specificato, ma un errore del nodo può causare interruzioni del traffico. Se aggiungi altri indirizzi IP mobili, AnthosNetworkGateway li assegna e li sposta in base alle esigenze. 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 durante l'assegnazione degli indirizzi IP mobili.
• Se un nodo ha un indirizzo IP mobile, il controller dà priorità alle assegnazioni ai nodi a cui non è già assegnato un IP floating.

L'indirizzo/mappatura dei nodi è disponibile nella sezione status quando ottieni l'oggetto AnthosNetworkGateway. Nota 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 della 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.

1. Utilizza il comando seguente per verificare lo stato di AnthosNetworkGateway e vedere come vengono assegnati gli indirizzi IP mobili:

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

   La risposta per 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 comando seguente per recuperare lo stato e l'allocazione degli indirizzi AnthosNetworkGateway 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 controllare.

Impostazione delle 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 si specifica la RP, egress (con almeno una regola), destinationCIDRs e egressSourceIP sono tutte obbligatorie.

Usa kubectl apply per creare la risorsa personalizzata EgressNATPolicy. Le seguenti sezioni forniscono dettagli ed esempi per definire la 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 è composta da podSelector e namespaceSelector.
  • La selezione si basa sull'etichetta dello spazio dei nomi namespaceSelector.matchLabels.**user** e sull'etichetta di un 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 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 qualsiasi blocco CIDR specificato, 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 ha un'etichetta role: frontend.
• Il pod si trova in uno spazio dei nomi con l'etichetta user: alice o user: paul.
• Il pod sta comunicando agli indirizzi IP 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.

Specificare 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 dei pod e di indirizzi IP di destinazione, il traffico in uscita dal pod viene convertito in 192.168.1.100 tramite SNAT.

Per poter accettare la route, l'indirizzo egressSourceIP deve trovarsi nella stessa subnet dell'IP del nodo gateway. Se l'indirizzo egressSourceIP è sconosciuto (non assegnato) al nodo gateway, la richiesta di route non può essere soddisfatta. In questo caso, verrà visualizzato un errore UnknownEgressIP negli eventi Kubernetes.

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

kubectl describe EgressNATPolicy egress

Se sono presenti 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 la perdita del pacchetto, le regole del gateway in uscita non vengono controllate dal pacchetto. Solo quando il criterio di rete consente il pacchetto in uscita, le regole di selezione del traffico in uscita verranno 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 essere nello stesso dominio L2 con indirizzi IP del nodo.

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