Confrontare i modelli di rete in GKE

Questo documento descrive il modello di rete utilizzato da Google Kubernetes Engine (GKE) e in che modo può essere diverso dai modelli di rete in altri ambienti Kubernetes. Questo documento illustra i seguenti concetti:

  • I modelli di rete più comuni utilizzati da varie implementazioni di Kubernetes.
  • I meccanismi di assegnazione degli indirizzi IP dei modelli di rete più comuni.
  • I vantaggi e gli svantaggi di ciascun modello di rete.
  • Una descrizione dettagliata del modello di rete predefinito utilizzato da GKE.

Il documento è rivolto ad architetti cloud, ingegneri delle operazioni e ingegneri di rete che potrebbero conoscere altre implementazioni di Kubernetes e che stanno pianificando di utilizzare GKE. Questo documento presuppone che tu abbia familiarità con Kubernetes e con il suo modello di networking di base. Inoltre, devi conoscere i concetti di networking come l'indirizzamento IP, la Network Address Translation (NAT), i firewall e i proxy.

Questo documento non illustra come modificare il modello di rete GKE predefinito per soddisfare vari vincoli relativi agli indirizzi IP. Se hai una carenza di indirizzi IP durante la migrazione a GKE, consulta le strategie di gestione degli indirizzi IP durante la migrazione a GKE.

Implementazioni tipiche dei modelli di rete

Puoi implementare il modello di networking di Kubernetes in vari modi. Tuttavia, qualsiasi implementazione deve sempre soddisfare i seguenti requisiti:

  • Ogni pod ha bisogno di un indirizzo IP univoco.
  • I pod possono comunicare con altri pod su tutti i nodi senza utilizzare NAT.
  • Gli agenti su un nodo, come kubelet, possono comunicare con tutti i pod su quel nodo.
  • I pod sulla rete host di un nodo possono comunicare con tutti i pod su tutti i nodi senza utilizzare NAT.

Sono state sviluppate più di 20 implementazioni diverse per il modello di rete Kubernetes che soddisfano questi requisiti.

Queste implementazioni possono essere raggruppate in tre tipi di modelli di rete. Questi tre modelli differiscono nei seguenti modi:

  • In che modo i pod possono comunicare con servizi non Kubernetes sulla rete aziendale.
  • Come i pod possono comunicare con altri cluster Kubernetes nella stessa organizzazione.
  • Indica se è necessario NAT per la comunicazione all'esterno del cluster.
  • Indica se gli indirizzi IP dei pod possono essere riutilizzati in altri cluster o altrove nella rete aziendale.

Ogni provider cloud ha implementato uno o più di questi tipi di modelli.

La tabella seguente identifica i tre tipi di modelli più comunemente utilizzati e in quale implementazione di Kubernetes vengono utilizzati:

Nome del modello di rete Utilizzato in queste implementazioni
Completamente integrato o piatto
Modalità Isola o in bridge
Isolato o con isolamento in aria
  • Non è comunemente utilizzato dalle implementazioni di Kubernetes, ma può essere utilizzato con qualsiasi implementazione quando il cluster viene disegnato in una rete o in un virtual private cloud (VPC) separati

Quando questo documento descrive questi modelli di rete, fa riferimento ai relativi effetti sulle reti on-premise connesse. Tuttavia, puoi applicare i concetti descritti per le reti on-premise connesse alle reti connesse tramite una rete privata virtuale (VPN) o tramite un'interconnessione privata, incluse le connessioni ad altri provider cloud. Per GKE, queste connessioni includono tutta la connettività tramite Cloud VPN o Cloud Interconnect.

Modello di rete completamente integrato

Il modello di rete completamente integrata (o flat) offre facilità di comunicazione con le applicazioni esterne a Kubernetes e in altri cluster Kubernetes. I principali fornitori di servizi cloud implementano comunemente questo modello perché possono integrare strettamente la loro implementazione di Kubernetes con la loro rete software-defined (SDN).

Quando utilizzi il modello completamente integrato, gli indirizzi IP che utilizzi per i pod vengono instradati all'interno della rete in cui si trova il cluster Kubernetes. Inoltre, la rete di base sa su quale nodo si trovano gli indirizzi IP dei pod. In molte implementazioni, gli indirizzi IP dei pod sullo stesso nodo provengono da un intervallo di indirizzi IP dei pod specifico e preassegnato. Tuttavia, questo intervallo di indirizzi preassegnato non è un requisito.

Il seguente diagramma mostra le opzioni di comunicazione dei pod nel modello di rete completamente integrato:

Diagramma di rete che mostra i pattern di comunicazione nel modello di rete completamente integrato.

Il diagramma precedente di un modello di rete completamente integrato mostra i seguenti modelli di comunicazione:

  • I pod all'interno di un cluster Kubernetes possono comunicare direttamente tra loro.
  • I pod possono comunicare con altri pod in altri cluster purché questi cluster si trovino nella stessa rete.
  • I pod non hanno bisogno di NAT per comunicare con altre applicazioni esterne al cluster, indipendentemente dal fatto che queste applicazioni si trovino nella stessa rete o in reti interconnesse.

Il diagramma mostra anche che gli intervalli di indirizzi IP dei pod sono distinti tra i diversi cluster.

Il modello di rete completamente integrato è disponibile nelle seguenti implementazioni:

  • Per impostazione predefinita, GKE implementa questo modello. Per ulteriori informazioni su questa implementazione, consulta il modello di networking GKE più avanti in questo documento.
  • Per impostazione predefinita, Amazon EKS implementa questo modello. In questa implementazione, Amazon EKS utilizza il plug-in CNI (Container Networking Interface) di Amazon VPC per Kubernetes per assegnare gli indirizzi IP dei pod direttamente dallo spazio di indirizzi VPC. Il plug-in CNI assegna gli indirizzi IP dalla subnet predefinita in cui si trovano i nodi o da una subnet personalizzata. Gli indirizzi IP dei pod non provengono da un intervallo di indirizzi IP del pod dedicato per nodo.
  • In Azure, AKS implementa questo modello quando utilizza Azure CNI (networking avanzato). Questa implementazione non è la configurazione predefinita. In questa implementazione, ogni pod riceve un indirizzo IP dalla subnet. Puoi anche configurare il numero massimo di pod per nodo. Pertanto, il numero di indirizzi IP riservati in advance per i pod su quel nodo corrisponde al numero massimo di pod per nodo.

L'utilizzo di un modello di rete completamente integrato offre i seguenti vantaggi:

  • Dati di telemetria migliori. Gli indirizzi IP dei pod sono visibili in tutta la rete. Questa visibilità rende i dati di telemetria più utili rispetto ad altri modelli perché i pod possono essere identificati anche dai dati di telemetria raccolti al di fuori del cluster.
  • Configurazione del firewall più semplice. Quando imposti le regole firewall, è più facile distinguere il traffico dei nodi e dei pod nel modello di rete completamente integrato rispetto agli altri modelli.
  • Maggiore compatibilità. I pod possono comunicare utilizzando protocolli che non supportano NAT.
  • Migliore debug. Se consentito dal firewall, le risorse esterne al cluster possono raggiungere direttamente i pod durante la procedura di debug.
  • Compatibilità con i mesh di servizi. I mesh di servizi, come Istio o Cloud Service Mesh, possono comunicare facilmente tra cluster perché i pod possono comunicare direttamente tra loro. Alcune implementazioni di mesh di servizi supportano solo la connettività pod-to-pod per i mesh di servizi multi-cluster.

L'utilizzo di un modello di rete completamente integrato presenta i seguenti svantaggi:

  • Utilizzo degli indirizzi IP. Non puoi riutilizzare gli indirizzi IP dei pod all'interno della rete e ogni indirizzo IP deve essere univoco. Questi requisiti possono portare a un numero elevato di indirizzi IP che devono essere riservati per i pod.
  • Requisiti SDN. Un modello di rete completamente integrato richiede un'integrazione profonda con la rete sottostante perché l'implementazione di Kubernetes deve programmare direttamente l'SDN. La programmazione dell'SDN è trasparente per l'utente e non comporta svantaggi per l'utente. Tuttavia, questi modelli di rete profondamente integrati non possono essere facilmente implementati in ambienti on-premise autogestiti.

Modello di rete in modalità isola

Il modello di rete in modalità isola (o con bridge) viene comunemente utilizzato per le implementazioni di Kubernetes on-premise in cui non è possibile un'integrazione profonda con la rete sottostante. Quando utilizzi un modello di rete in modalità isola, i pod in un cluster Kubernetes possono comunicare con le risorse esterne al cluster tramite una sorta di gateway o proxy.

Il seguente diagramma mostra le opzioni di comunicazione dei pod in un modello di rete in modalità isolata:

Diagramma di rete che mostra i pattern di comunicazione nel modello di rete in modalità isola.

Il diagramma precedente di un modello di rete in modalità isola mostra come i pod all'interno di un cluster Kubernetes possono comunicare direttamente tra loro. Il diagramma mostra inoltre che i pod in un cluster devono utilizzare un gateway o un proxy per comunicare con applicazioni esterne al cluster o con pod in altri cluster. Mentre la comunicazione tra un cluster e un'applicazione esterna richiede un singolo gateway, la comunicazione da cluster a cluster richiede due gateway. Il traffico tra due cluster passa attraverso un gateway quando esce dal primo cluster e un altro gateway quando entra nell'altro cluster.

Esistono diversi modi per implementare i gateway o i proxy in un modello di rete isolato. Le seguenti implementazioni sono i due gateway o proxy più comuni:

  • Utilizzare i nodi come gateway. Questa implementazione viene comunemente utilizzata quando i nodi del cluster fanno parte della rete esistente e i relativi indirizzi IP sono instradabili in modo nativo all'interno di questa rete. In questo caso, i nodi stessi sono i gateway che forniscono connettività dall'interno del cluster alla rete più grande. Il traffico in uscita da un pod all'esterno del cluster può essere indirizzato verso altri cluster o verso applicazioni non Kubernetes, ad esempio per chiamare un'API on-premise sulla rete aziendale. Per questo traffico in uscita, il nodo che contiene il pod utilizza il NAT di origine (SNAT) per mappare l'indirizzo IP del pod all'indirizzo IP del nodo. Per consentire alle applicazioni al di fuori del cluster di comunicare con i servizi all'interno del cluster, puoi utilizzare il tipo di servizio NodePort per la maggior parte delle implementazioni. In alcune implementazioni, puoi utilizzare il tipo di servizio LoadBalancer per esporre i servizi. Quando utilizzi il tipo di servizio LoadBalancer, assegni a questi servizi un indirizzo IP virtuale bilanciato in base al carico tra i nodi e instradato a un pod che fa parte del servizio.

    Il seguente diagramma mostra il pattern di implementazione quando si utilizzano i nodi come gateway:

    Diagramma di rete che mostra i pattern di comunicazione nel modello di rete in modalità isola che utilizza i nodi come gateway.

    Il diagramma precedente mostra che l'utilizzo dei nodi come gateway non influisce sulla comunicazione tra pod all'interno di un cluster. I pod in un cluster comunicano ancora tra loro direttamente. Tuttavia, il diagramma mostra anche i seguenti pattern di comunicazione al di fuori del cluster:

    • In che modo i pod comunicano con altri cluster o applicazioni non Kubernetes utilizzando SNAT quando escono dal nodo.
    • In che modo il traffico proveniente da servizi esterni in altri cluster o da applicazioni non Kubernetes entra nel cluster tramite un servizio NodePort prima di essere inoltrato al pod corretto nel cluster.

  • Utilizzare macchine virtuali (VM) proxy con più interfacce di rete. Questo pattern di implementazione utilizza i proxy per accedere alla rete che contiene il cluster Kubernetes. I proxy devono avere accesso allo spazio degli indirizzi IP del pod e dei nodi. In questo pattern, ogni VM proxy ha due interfacce di rete: un'interfaccia nella rete aziendale più grande e un'altra nella rete contenente il cluster Kubernetes.

    Il seguente diagramma mostra il pattern di implementazione quando si utilizzano VM proxy:

    Diagramma di rete che mostra i pattern di comunicazione nel modello di rete in modalità isola che utilizza VM proxy.

    Il diagramma precedente mostra che l'utilizzo di proxy in modalità isola non influisce sulla comunicazione all'interno di un cluster. I pod in un cluster possono comunque comunicare tra loro direttamente. Tuttavia, il diagramma mostra anche come la comunicazione dai pod ad altri cluster o applicazioni non Kubernetes passa attraverso un proxy che ha accesso sia alla rete del cluster sia alla rete di destinazione. Inoltre, la comunicazione che entra nel cluster dall'esterno passa anche attraverso lo stesso tipo di proxy.

Il modello di rete in modalità isola è disponibile nelle seguenti implementazioni:

  • Per impostazione predefinita, Azure Kubernetes Service (AKS) utilizza il networking in modalità isola quando si utilizza il networking Kubenet (di base). Quando AKS utilizza il networking in modalità isola, la rete virtuale che contiene il cluster include solo gli indirizzi IP dei nodi. Gli indirizzi IP dei pod non fanno parte della rete virtuale. I pod ricevono invece gli indirizzi IP da uno spazio logico diverso. Il modello in modalità isola utilizzato da AKS instrada anche il traffico da pod a pod tra i nodi utilizzando route definite dall'utente con il forwarding IP attivato sull'interfaccia dei nodi. Per la comunicazione del pod con le risorse esterne al cluster, il nodo utilizza SNAT per mappare l'indirizzo IP del pod all'indirizzo IP del nodo prima che il traffico in uscita esca dal nodo.
  • In Oracle Container Engine for Kubernetes (OKE), la comunicazione tra pod utilizza una rete overlay VXLAN. Inoltre, il traffico dai pod alle applicazioni esterne al cluster utilizza SNAT per mappare l'indirizzo IP del pod all'indirizzo IP del nodo.

L'utilizzo di un modello di rete in modalità isola presenta i seguenti vantaggi:

  • Utilizzo degli indirizzi IP. Gli indirizzi IP dei pod nel cluster possono essere riutilizzati in altri cluster. Tuttavia, gli indirizzi IP già utilizzati da servizi esterni nella rete aziendale non possono essere utilizzati per i pod se è necessaria la comunicazione tra i pod e questi servizi. Pertanto, la migliore prassi per la creazione di una rete in modalità isola è prenotare uno spazio di indirizzi IP dei pod univoco all'interno della rete e utilizzarlo per tutti i cluster.
  • Impostazioni di sicurezza più semplici. Poiché i pod non sono esposti direttamente al resto della rete aziendale, non è necessario proteggerli dal traffico in entrata dal resto della rete aziendale.

L'utilizzo di un modello di rete in modalità isola presenta i seguenti svantaggi:

  • Telemetria imprecisa. I dati di telemetria raccolti al di fuori del cluster contengono solo l'indirizzo IP del nodo, non l'indirizzo IP del pod. La mancanza di indirizzi IP dei pod rende più difficile identificare la sorgente e la destinazione del traffico.
  • Difficile da eseguire il debug. Durante il debug, non puoi connetterti direttamente ai pod dall'esterno del cluster.
  • È più difficile configurare i firewall. Puoi utilizzare gli indirizzi IP dei nodi solo quando configuri il firewall. Di conseguenza, le impostazioni del firewall risultanti consentono a tutti i pod su un nodo e al nodo stesso di raggiungere i servizi esterni o non consentono a nessuno di raggiungerli.

  • Compatibilità con i mesh di servizi. Con la modalità isola, la comunicazione diretta tra pod nei cluster nei mesh di servizi, come Istio o Cloud Service Mesh, non è possibile.

    Esistono ulteriori limitazioni per alcune implementazioni di mesh di servizi. Il supporto multi-cluster di Cloud Service Mesh per i cluster GKE su Google Cloud supporta solo i cluster sulla stessa rete. Per le implementazioni di Istio che supportano un modello di più reti, la comunicazione deve avvenire tramite i gateway Istio, il che rende più complessi i deployment di mesh di servizi multi-cluster.

Modello di rete isolata

Il modello di rete isolata (o con air gap) viene utilizzato più comunemente per i cluster che non hanno bisogno di accedere alla rete aziendale più grande, tranne tramite API rivolte al pubblico. Quando utilizzi un modello di rete isolato, ogni cluster Kubernetes è isolato e non può utilizzare indirizzi IP interni per comunicare con il resto della rete. Il cluster si trova su una propria rete privata. Se un pod nel cluster deve comunicare con servizi esterni al cluster, questa comunicazione deve utilizzare indirizzi IP pubblici sia per l'ingresso che per l'uscita.

Il seguente diagramma mostra le opzioni di comunicazione dei pod in un modello di rete isolato:

Diagramma di rete che mostra i pattern di comunicazione nel modello di rete isolata.

Il diagramma precedente di un modello di rete isolato mostra che i pod all'interno di un cluster Kubernetes possono comunicare direttamente tra loro. Il diagramma mostra inoltre che i pod non possono utilizzare indirizzi IP interni per comunicare con i pod di altri cluster. Inoltre, i pod possono comunicare con le applicazioni al di fuori del cluster solo se vengono soddisfatti i seguenti criteri:

  • Esiste un gateway internet che connette il cluster all'esterno.
  • L'applicazione esterna utilizza un indirizzo IP esterno per le comunicazioni.

Infine, il diagramma mostra come lo stesso spazio degli indirizzi IP per i pod e i nodi può essere riutilizzato tra ambienti diversi.

Il modello di rete isolata non è comunemente utilizzato dalle implementazioni di Kubernetes. Tuttavia, puoi ottenere un modello di rete isolato in qualsiasi implementazione. Devi solo eseguire il deployment di un cluster Kubernetes in una rete o VPC separata senza alcuna connettività ad altri servizi o alla rete aziendale. L'implementazione risultante avrebbe gli stessi vantaggi e svantaggi del modello di rete isolato.

L'utilizzo di una modalità di rete isolata presenta i seguenti vantaggi:

  • Utilizzo degli indirizzi IP. Puoi riutilizzare tutti gli indirizzi IP interni del cluster: indirizzi IP dei nodi, indirizzi IP dei servizi e indirizzi IP dei pod. Il riutilizzo degli indirizzi IP interni è possibile perché ogni cluster ha la propria rete privata e la comunicazione con le risorse esterne al cluster avviene solo tramite indirizzi IP pubblici.
  • Controllo. Gli amministratori del cluster hanno il pieno controllo sull'indirizzamento IP nel cluster e non devono eseguire attività di gestione degli indirizzi IP. Ad esempio, gli amministratori possono allocare l'intero spazio indirizzi 10.0.0.0/8 ai pod e ai servizi nel cluster, anche se questi indirizzi sono già utilizzati nell'organizzazione.
  • Sicurezza. La comunicazione al di fuori del cluster è strettamente controllata e, se consentita, utilizza interfacce esterne e NAT ben definite.

L'utilizzo di un modello di rete isolato presenta i seguenti svantaggi:

  • Nessuna comunicazione privata. La comunicazione che utilizza indirizzi IP interni non è consentita con altri cluster o altri servizi della rete.

Modello di networking di GKE

GKE utilizza un modello di rete completamente integrato in cui i cluster vengono di cui vengono eseguiti il deployment in una rete Virtual Private Cloud (VPC) che può contenere anche altre applicazioni.

Ti consigliamo di utilizzare un cluster nativo VPC per il tuo ambiente GKE. Puoi creare il tuo cluster nativo VPC in modalità standard o Autopilot. Se scegli la modalità Autopilot, la modalità nativa VPC è sempre attiva e non può essere disattivata. I paragrafi seguenti descrivono il modello di rete GKE in Standard con note sulle differenze di Autopilot.

Gestione degli indirizzi IP nei cluster nativi di VPC

Quando utilizzi un cluster nativo di VPC, gli indirizzi IP dei pod sono indirizzi IP secondari su ogni nodo. A ogni nodo viene assegnata una subnet specifica di un intervallo di indirizzi IP del pod che selezioni dallo spazio di indirizzi IP interno quando crei il cluster. Per impostazione predefinita, un cluster nativo di VPC assegna una /24 subnet a ogni nodo da utilizzare come indirizzi IP del pod. Una subnet /24 corrisponde a 256 indirizzi IP. In Autopilot, il cluster utilizza una subnet /26 corrispondente a 64 indirizzi e non puoi modificare questa impostazione.

Il modello di networking di GKE non consente di riutilizzare gli indirizzi IP nella rete. Quando esegui la migrazione a GKE, devi pianificare l'allocazione degli indirizzi IP per ridurre l'utilizzo degli indirizzi IP interni in GKE.

Poiché gli indirizzi IP dei pod sono instradabili all'interno della rete VPC, per impostazione predefinita i pod possono ricevere traffico dalle seguenti risorse:

Gestire la comunicazione del traffico esterno con l'agente di mascheramento IP

Quando comunichi dai pod ai servizi esterni al cluster, l'agente di mascheramento IP regola la modalità di visualizzazione del traffico per questi servizi. L'agente di mascheramento IP gestisce gli indirizzi IP privati ed esterni in modo diverso, come indicato nei seguenti punti elenco:

Puoi anche utilizzare indirizzi IP pubblici utilizzati privatamente (PUPI) all'interno della tua rete VPC o delle reti collegate. Se utilizzi indirizzi PUPI, puoi comunque usufruire del modello di rete completamente integrato e visualizzare l'indirizzo IP del pod direttamente come origine. Per raggiungere entrambi questi obiettivi, devi includere gli indirizzi PUPI nell'elenco nonMasqueradeCIDRs.

Informazioni sul flusso di traffico dei pod in una rete GKE

Il seguente diagramma mostra come i pod possono comunicare nel modello di networking di GKE:

Diagramma di rete che mostra i pattern di comunicazione nel modello di rete GKE.

Il diagramma precedente mostra in che modo i pod negli ambienti GKE possono utilizzare indirizzi IP interni per comunicare direttamente con le seguenti risorse:

  • Altri pod nello stesso cluster.
  • Pod in altri cluster GKE nella stessa rete VPC.
  • Altre applicazioni Google Cloud nella stessa rete VPC.
  • Applicazioni on-premise connesse tramite Cloud VPN.

Il diagramma mostra anche cosa succede quando un pod deve utilizzare un indirizzo IP esterno per comunicare con un'applicazione. Quando il traffico esce dal nodo, il nodo in cui risiede il pod utilizza SNAT per mappare l'indirizzo IP del pod all'indirizzo IP del nodo. Una volta che il traffico esce dal nodo, Cloud NAT tradurrà l'indirizzo IP del nodo in un indirizzo IP esterno.

Per i vantaggi descritti in precedenza in questo documento, principalmente per il vantaggio di avere gli indirizzi IP dei pod visibili in tutti i dati di telemetria, Google ha scelto un modello di rete completamente integrato. In GKE, gli indirizzi IP dei pod sono esposti nei log di flusso VPC (inclusi i nomi dei pod nei metadati), nel mirroring dei pacchetti, nella registrazione delle regole firewall, e nei log delle tue applicazioni per le destinazioni non mascherate.

Passaggi successivi