Informazioni sul supporto di più reti per i pod

Questo documento descrive il supporto di più reti per i pod, inclusi i casi d'uso, i concetti pertinenti, la terminologia e i vantaggi.

Panoramica

Google Cloud supporta più interfacce di rete a livello di istanza di macchina virtuale (VM). Puoi connettere una VM a un massimo di otto reti con più interfacce di rete, tra cui la rete predefinita e altre sette reti.

Il networking di Google Kubernetes Engine (GKE) estende le funzionalità di networking multiplo ai pod eseguiti sui nodi. Con il supporto di più reti per i pod, puoi abilitare più interfacce su nodi e pod in un cluster GKE. Il supporto di più reti per i pod rimuove la limitazione della singola interfaccia per i node pool, che limitava i nodi a un singolo VPC per il networking.

Per utilizzare il supporto di più reti per i pod e i nodi, consulta Configura il supporto di più reti per i pod.

Terminologia e concetti

Questa pagina utilizza i seguenti concetti:

VPC principale: il VPC principale è un VPC preconfigurato che include un insieme di impostazioni e risorse predefinite. Il cluster GKE viene creato in questo VPC. Se hai eliminato il VPC preconfigurato, devi specificare un VPC esistente durante la creazione di un cluster GKE.

Subnet: in Google Cloud, una subnet è il modo per creare il Classless Inter-Domain Routing (CIDR) con netmask in un VPC. Una subnet ha un singolo intervallo di indirizzi IP principale assegnato ai nodi e può avere più intervalli secondari che possono appartenere a pod e servizi.

Rete di nodi: la rete di nodi si riferisce a una combinazione dedicata di una coppia VPC e subnet. All'interno di questa rete di nodi, ai nodi appartenenti al pool di nodi vengono assegnati indirizzi IP dall'intervallo di indirizzi IP principale.

Intervallo secondario: un Google Cloud intervallo secondario è un CIDR e una subnet mask appartenenti a una subnet. GKE la utilizza come rete di pod di livello 3. Un pod può connettersi a più reti pod.

Pod-network: un oggetto Network che funge da punto di connessione per i pod. La connessione può essere di tipo Layer 3 o Device. Puoi configurare reti di tipo Device in modalità netdevice o DPDK (Data Plane Development Kit).

Le reti Layer 3 corrispondono a un intervallo secondario su una subnet. La rete Device corrisponde a una subnet su un VPC. Il modello dei dati per la rete di pod nella rete multipla GKE è il seguente:

  • Per la rete Layer 3: VPC -> Nome subnet -> Nome intervallo secondario

  • Per la rete Device: VPC -> Nome subnet

Google Cloud La rete pod predefinita utilizza il VPC principale come rete nodo. La rete di pod predefinita è disponibile su tutti i nodi e i pod del cluster, per impostazione predefinita.

Pod con più interfacce: più interfacce sui pod non possono connettersi alla stessa rete di pod.

Il seguente diagramma mostra una tipica architettura dei cluster GKE con reti Layer 3:

Architettura dei cluster GKE con reti di livello 3

Per reti di tipo Device, che possono essere configurate in modalità netdevice o DPDK, la VM vNIC viene gestita come risorsa e passata al pod. In questo caso, la rete di pod è mappata direttamente alla rete di nodi. Gli intervalli secondari non sono obbligatori per le reti di tipo Device.

Reti di pod e nodi

Casi d'uso

Il supporto di più reti per i pod è utile nei seguenti casi d'uso:

  • Esegui il deployment delle funzioni di rete containerizzate: se esegui le funzioni di rete nei container, che hanno piani di dati e di gestione separati. La rete multipla per i pod isola le reti per diversi piani utente, prestazioni elevate o bassa latenza da interfacce specifiche o multi-tenancy a livello di rete. Questo è necessario per la conformità, la qualità del servizio e la sicurezza.
  • Connetti VPC all'interno della stessa organizzazione e dello stesso progetto: vuoi creare cluster GKE in un VPC e devi connetterti ai servizi in un altro VPC. Puoi utilizzare l'opzione dei nodi multi-NIC per la connettività diretta. Questo potrebbe essere dovuto a un modello hub and spoke, in cui un servizio centralizzato (logging, autenticazione) opera all'interno di un VPC hub e gli spoke richiedono una connettività privata per accedervi. Puoi utilizzare il supporto di più reti per i pod per connettere i pod in esecuzione nel cluster GKE direttamente al VPC hub.
  • Esegui applicazioni DPDK con VFIO: vuoi eseguire applicazioni DPDK che richiedono l'accesso alla NIC sul nodo tramite il driver VFIO. Puoi ottenere la frequenza di pacchetti ottimale bypassando completamente il kernel, Kubernetes e GKE Dataplane V2.
  • Abilita l'accesso diretto alla vNIC ignorando Kubernetes e GKE Dataplane V2: esegui le funzioni di rete nei container che richiedono l'accesso diretto alla scheda di interfaccia di rete (NIC) sul nodo. Ad esempio, le applicazioni di computing ad alte prestazioni (HPC) che vogliono bypassare Kubernetes e GKE Dataplane V2 per ottenere la latenza più bassa. Alcune applicazioni richiedono anche l'accesso alle informazioni sulla topologia PCIe della NIC per la collocazione con altri dispositivi come la GPU.
  • Esponi i workload su reti secondarie utilizzando i bilanciatori del carico: puoi utilizzare i bilanciatori del carico di rete passthrough esterni e interni per esporre i workload (come le funzioni di rete containerizzate) direttamente su VPC secondari. In questo modo, puoi fornire l'accesso alle tue applicazioni su interfacce di rete specifiche senza utilizzare la rete predefinita del cluster.
  • Collega reti IPv4 secondarie a cluster IPv6 a stack singolo: nei cluster IPv6 a stack singolo (anteprima), i pod eseguiti su una rete principale solo IPv6 possono collegare reti VPC di livello 3 secondarie solo IPv4. Questa configurazione consente ai workload di comunicare con le risorse IPv4 nelle subnet VPC secondarie. Tieni presente che le reti di pod IPv6 secondarie non sono supportate.

Vantaggi

Il supporto di più reti per i pod offre i seguenti vantaggi:

  • Isolamento del traffico: il supporto di più reti per i pod consente di isolare il traffico in un cluster GKE. Puoi creare pod con più interfacce di rete per separare il traffico in base alla funzionalità, ad esempio gestione e piano dati, all'interno di pod che eseguono funzioni di rete containerizzate (CNF) specifiche.
  • Dual homing: il dual homing consente a un pod di avere più interfacce e di instradare il traffico a VPC diversi, in modo che il pod possa stabilire connessioni con un VPC principale e uno secondario. Se un VPC presenta problemi, l'applicazione può eseguire il failover sul VPC secondario.
  • Segmentazione della rete: i pod possono connettersi a reti interne o esterne in base alle esigenze del workload. A seconda dei requisiti specifici dei tuoi workload, puoi scegliere quali pod o gruppi di pod si connettono a ciascuna rete. Ad esempio, puoi utilizzare una rete interna per la comunicazione est-ovest e una rete esterna per l'accesso a internet. In questo modo, puoi personalizzare la connettività di rete dei tuoi workload in base alle loro esigenze specifiche.
  • Prestazioni ottimali con DPDK: il supporto di più reti per i pod in GKE consente alle applicazioni DPDK di essere eseguite nei pod GKE, il che fornisce prestazioni ottimali di elaborazione dei pacchetti.
  • NIC host direttamente disponibile nel pod: il supporto della NIC in modalità netdevice con più reti passa la NIC della VM direttamente al pod, bypassando Kubernetes e GKE Dataplane V2. In questo modo è possibile ottenere la latenza più bassa per la collaborazione tra i dispositivi.
  • Prestazioni: per migliorare le prestazioni delle tue applicazioni, puoi connetterle alla rete più adatta alle loro esigenze.
  • Bilanciamento del carico multi-rete: il supporto multi-rete per i pod consente di eseguire il provisioning di bilanciatori del carico di rete passthrough esterni e interni Google Cloud per i servizi su reti secondarie. In questo modo puoi esporre le tue applicazioni ai client su VPC specifiche, mantenendo al contempo un isolamento di rete rigoroso tra i tuoi workload.

Passaggi successivi