Anthos clusters on bare metal è ora Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Configurazione di un gateway NAT in uscita

Questo documento descrive come configurare un gateway NAT in uscita Google Distributed Cloud. Questo gateway fornisce un indirizzo IP SNAT permanente e deterministico per il traffico in uscita dai cluster. Quando esegui carichi di lavoro che utenti in uscita (al di fuori dei cluster), i tuoi clienti vogliono identificare questo traffico usando alcuni indirizzi IP deterministici. Ciò consente ai tuoi clienti di implementare misure di sicurezza basate sull'IP, come l'inserimento nella lista consentita criteri.

Il gateway NAT in uscita viene abilitato utilizzando due risorse personalizzate. Per un dato nello spazio dei nomi, la risorsa personalizzata NetworkGatewayGroup specifica l'IP mobile indirizzi che possono essere configurati sull'interfaccia di rete di un Nodo che scelto per fungere da gateway. La risorsa personalizzata EgressNatPolicy ti 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 regole di selezione del traffico, traffico in uscita da un determinato pod a una destinazione all'esterno del cluster è mascherato dall'indirizzo IP del nodo in cui il pod in esecuzione. In questo scenario, non vi è alcuna garanzia che tutto il traffico in uscita un particolare pod avrà lo stesso indirizzo IP di origine oppure verrà mascherato allo 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 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 risposta corrispondente. Supponiamo che la subnet del nodo abbia indirizzi IP 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 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 una Nodo con indirizzo IP 192.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 il traffico verso il nodo gateway, invece di effettuare direttamente il mascheramento con il nodo Indirizzo IP.
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 restituito torna al nodo gateway con destinazione 192.168.1.100.
Il nodo gateway corrisponde al collegamento del traffico di ritorno a quello di il traffico in uscita originale e riscrive l'indirizzo IP di destinazione come 10.10.10.1.
10.10.10.1 viene considerato traffico nel cluster, instradato al nodo originale, e rispedito al pod originale.

Configura indirizzi IP mobili per il traffico dei nodi

La risorsa personalizzata Gruppo di gateway di rete è un componente in bundle di Google Distributed Cloud. La risorsa gestisce un elenco di o più indirizzi IP mobili da utilizzare per il traffico in uscita dai nodi nel tuo in un cluster Kubernetes. I nodi partecipanti sono determinati dallo spazio dei nomi specificato. La Il gruppo di gateway di rete rende disponibile un indirizzo IP mobile in qualsiasi momento su un secondo il criterio del "best effort". Se un Nodo che utilizza un indirizzo IP mobile smette di funzionare, 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 cluster di configurazione quando si crea un nuovo cluster 1.29.300--gke.185.

Crea la risorsa personalizzata `NetworkGatewayGroup`

Puoi abilitare il gruppo di gateway di rete impostando il parametro Campo spec.clusterNetwork.advancedNetworking a true nel file di configurazione del cluster quando crei un cluster come mostrato nell'esempio che segue:

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 su lo spazio dei nomi del cluster e specificare 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 i 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 i nodi del piano di controllo durante l'assegnazione degli indirizzi IP mobili.
Se un nodo ha un indirizzo IP mobile: l'operatore assegna la priorità a nodi a cui non è già stato assegnato un IP mobile.

La mappatura indirizzo/nodo è disponibile nella sezione status quando ottieni il Oggetto NetworkGatewayGroup. Tieni presente che l'oggetto NetworkGatewayGroup si trova lo spazio dei nomi kube-system. Se un nodo gateway non è attivo, viene utilizzata la rete 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 controllare lo stato del gateway e recuperare gli indirizzi IP mobili specificato per il gateway.

Usa il seguente comando per controllare lo stato dell'evento NetworkGatewayGroup per 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 ha questo 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 risorsa personalizzata egress (con almeno una regola), destinationCIDRs e egressSourceIP sono tutti obbligatori.

Usa kubectl apply per creare la risorsa personalizzata EgressNATPolicy. La le seguenti sezioni forniscono dettagli ed esempi per definire la specifica.

Specifica le regole di routing in uscita

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

Devi specificare una o più regole per la selezione del traffico in uscita nel campo egress .
- Ogni regola è composta da un podSelector e da un 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 soddisfa una qualsiasi delle regole (la corrispondenza utilizza una relazione OR), per il traffico in uscita.
Specifica gli indirizzi di destinazione consentiti nella sezione destinationCIDRs.
- destinationCIDRs richiede un elenco di blocchi CIDR.
- Se il traffico in uscita da un pod ha un indirizzo IP di destinazione che nell'intervallo di uno qualsiasi dei blocchi CIDR specificati, viene selezionata 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 ulteriori informazioni sull'uso 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 gatewayRef.name e gatewayRef.namespace per trovare un oggetto NetworkGatewayGroup (gateway). Il criterio utilizza uno degli indirizzi IP mobili del gateway come IP di origine per il traffico in uscita. Se nell'elenco sono presenti più indirizzi IP mobili gateway corrispondente, il criterio utilizza il primo indirizzo IP nell'elenco floatingIPs e ignora qualsiasi altro indirizzo IP. Per gateway di esempio, il primo nell'elenco floatingIPs è 192.168.1.100. Con campi non validi o valori nella sezione gatewayRef comporterà l'impossibilità di applicare il criterio .

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ù istanze e, se intendi utilizzare indirizzi IP diversi, devi creare più oggetti NetworkGatewayGroup e fare riferimento rispettivamente.

Ogni risorsa NetworkGatewayGroup deve contenere indirizzi IP mobili univoci. Per configurare più oggetti EgressNATPolicy in modo che utilizzino lo stesso indirizzo IP, usa gli stessi 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 gestirli ogni all'indirizzo IP mobile. In genere, ogni criterio in uscita dovrebbe avere un dell'oggetto gateway corrispondente per garantire che venga allocato l'indirizzo IP corretto.

Poi 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 facciano riferimento agli oggetti gateway, ad esempio come 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) Specifica i nodi in cui posizionare gli indirizzi IP mobili

NetworkGatewayGroup risorse supportano i selettori dei nodi. Per specificare un sottoinsieme di nodi considerati per ospitare un indirizzo IP mobile, puoi aggiungere selettore di nodi all'oggetto NetworkGatewayGroup, come mostrato di seguito esempio:

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 che hanno l'etichetta specificata e solo questi vengono considerati per l'hosting di un indirizzo IP mobile. Se specifichi più selettori, con una logica additiva. Perciò un nodo deve corrispondere a ogni etichetta considerata per l'hosting di un indirizzo IP mobile. Se non ci sono molti nodi con che corrispondono alle etichette, un selettore di nodi può ridurre le qualità di alta disponibilità del posizionamento degli indirizzi IP mobili.

Regole di selezione del traffico in uscita e criteri di rete

Il gateway NAT in uscita è compatibile con le API dei criteri di rete. Criteri di rete vengono valutati per primi e hanno la precedenza sulle regole di selezione del traffico il gateway NAT in uscita. Ad esempio, se il traffico in uscita attiva un criterio di rete. con conseguente eliminazione del pacchetto, le regole del gateway in uscita non controlleranno un pacchetto. Solo quando il criterio di rete consente al pacchetto di essere in uscita, le regole di selezione del traffico vengono valutate per decidere come viene gestito il traffico, utilizzando il gateway NAT in uscita oppure 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 IP nodo indirizzi IP esterni.
Gli upgrade non sono supportati per i cluster che sono stati configurati per utilizzare Anteprima del gateway NAT in uscita. Per Google Distributed Cloud release 1.29.0 e successive, Il gateway NAT è in modalità Anteprima solo su Ubuntu 18.04. L'utilizzo è senza costi questa funzionalità mentre è in anteprima.