Confronta i modelli di rete in GKE

Questo documento descrive il modello di rete utilizzato da Google Kubernetes Engine (GKE) e le differenze con i modelli di rete in altri ambienti Kubernetes. Questo documento tratta i seguenti concetti:

  • I modelli di rete più comuni utilizzati da varie implementazioni Kubernetes.
  • I meccanismi di indirizzamento 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 ai Cloud Architect, agli Operations Engineer e agli ingegneri di rete che potrebbero avere familiarità con altre implementazioni Kubernetes e hanno intenzione di utilizzare GKE. In questo documento si presuppone che tu conosca bene Kubernetes e il relativo modello di networking di base. Inoltre, dovresti avere familiarità con 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 networking GKE predefinito per soddisfare vari vincoli relativi agli indirizzi IP. Se gli indirizzi IP durante la migrazione a GKE sono insufficienti, consulta 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, ad esempio 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 di Kubernetes che soddisfano questi requisiti.

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

  • Modalità di comunicazione tra i pod e servizi non Kubernetes sulla rete aziendale.
  • Il modo in cui i pod possono comunicare con altri cluster Kubernetes nella stessa organizzazione.
  • Indica se NAT è necessario per le comunicazioni all'esterno del cluster.
  • Indica se gli indirizzi IP dei pod possono essere riutilizzati in altri cluster o altrove nella rete aziendale.

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

La tabella seguente identifica i tre tipi di modelli di uso comune e in cui vengono utilizzati l'implementazione di Kubernetes:

Nome modello di rete Utilizzato in queste implementazioni
Completamente integrata o piatta
Modalità isola o con ponte
isolati o air gap
  • Non è comunemente usato dalle implementazioni Kubernetes, ma può essere usato con qualsiasi implementazione quando viene eseguito il deployment del cluster in una rete separata o in un VPC (Virtual Private Cloud)

La descrizione di questi modelli di rete fa riferimento ai loro effetti sulle reti on-premise connesse. Tuttavia, è possibile applicare i concetti descritti per le reti on-premise connesse a reti connesse tramite una rete privata virtuale (VPN) o un'interconnessione privata, comprese le connessioni ad altri cloud provider. Per GKE, queste connessioni includono tutta la connettività tramite Cloud VPN o Cloud Interconnect.

Modello di rete completamente integrato

Il modello di rete completamente integrato (o flat) semplifica le comunicazioni con le applicazioni esterne a Kubernetes e in altri cluster Kubernetes. I principali provider di servizi cloud di solito implementano questo modello perché possono integrare strettamente la loro implementazione 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 sottostante 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. Ma questo intervallo di indirizzi preassegnato non è un requisito.

Il seguente diagramma mostra le opzioni di comunicazione dei pod nel modello di networking 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 pattern di comunicazione:

  • I pod in 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 Modello di networking di GKE più avanti in questo documento.
  • Per impostazione predefinita, Amazon EKS implementa questo modello. In questa implementazione, Amazon EKS utilizza il plug-in di Amazon VPC Container Networking Interface (CNI) per Kubernetes per assegnare 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 dei pod dedicato per nodo.
  • In Azure, AKS implementa questo modello con 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. Di conseguenza, il numero di indirizzi IP prenotati in anticipo 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 all'esterno del cluster.
  • Configurazione del firewall più semplice. Durante l'impostazione di regole firewall, la differenziazione del traffico di nodi e pod è più semplice nel modello di rete completamente integrato rispetto agli altri modelli.
  • Migliore compatibilità. I pod possono comunicare usando protocolli che non supportano NAT.
  • Debug migliore. Se consentito dal firewall, le risorse esterne al cluster possono raggiungere i pod direttamente durante il processo di debug.
  • Compatibilità con i mesh di servizi. I mesh di servizi, come Istio o Cloud Service Mesh, possono comunicare facilmente tra i cluster perché i pod possono comunicare direttamente tra loro. Alcune implementazioni di mesh di servizi supportano la connettività da pod a pod solo per mesh di servizi multi-cluster.

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

  • Utilizzo dell'indirizzo 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 per l'SDN. Un modello di rete completamente integrato richiede una profonda integrazione con la rete sottostante, poiché l'implementazione 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 implementati facilmente in ambienti on-premise autogestiti.

Modello di rete in modalità isola

Il modello di rete in modalità isolana (o bridge) è comunemente utilizzato per le implementazioni 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 risorse esterne al cluster attraverso un tipo di gateway o proxy.

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

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 in un cluster Kubernetes possono comunicare direttamente tra loro. Il diagramma mostra anche 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 tra cluster richiede due gateway. Il traffico tra due cluster passa attraverso un gateway quando esci dal primo cluster e da un altro gateway quando entri 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:

  • Utilizzo dei nodi come gateway. Questa implementazione viene utilizzata di solito quando i nodi nel cluster fanno parte della rete esistente e i loro 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 diretto verso altri cluster o verso applicazioni non Kubernetes, ad esempio per chiamare un'API on-premise sulla rete aziendale. Per il 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 esterne al 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, puoi assegnare a questi servizi un indirizzo IP virtuale con bilanciamento del 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'uso dei nodi come gateway non ha un impatto sulla comunicazione tra pod all'interno di un cluster. I pod in un cluster continuano a comunicare tra loro direttamente. Tuttavia, il diagramma mostra anche i seguenti pattern di comunicazione esterni al cluster:

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

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

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

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

    Il diagramma precedente mostra che l'uso dei proxy in modalità isola non ha un impatto sulla comunicazione all'interno di un cluster. I pod in un cluster possono comunque comunicare direttamente tra loro. 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 che alla rete di destinazione. Inoltre, anche la comunicazione che entra nel cluster dall'esterno passa 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 indirizzi IP da uno spazio logico diverso. Il modello in modalità isola utilizzato da AKS instrada anche il traffico dai pod ai pod tra i nodi, utilizzando route definite dall'utente con l'IP forwarding attivato nell'interfaccia dei nodi. Per la comunicazione dei 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 per 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 dell'indirizzo 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 è necessario comunicare tra i pod e questi servizi. Pertanto, la best practice per il networking in modalità isola è prenotare uno spazio di indirizzi IP dei pod univoco all'interno della rete e utilizzare questo spazio di indirizzi IP per tutti i cluster.
  • Impostazioni di sicurezza semplificate. 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'uso 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 complica l'identificazione dell'origine e della destinazione del traffico.
  • Eseguire il debug più difficile. Durante il debug, non puoi connetterti direttamente ai pod dall'esterno del cluster.
  • La configurazione dei firewall è più difficile. Puoi utilizzare gli indirizzi IP dei nodi solo quando configuri il firewall. Pertanto, le impostazioni del firewall risultanti consentono a tutti i pod su un nodo e al nodo stesso di raggiungere i servizi esterni o a nessuno di questi servizi esterni.

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

    Esistono ulteriori limitazioni con 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 Istio che supportano un modello di più reti, la comunicazione deve avvenire tramite i gateway Istio, il che rende i deployment mesh di servizi multi-cluster più complessi.

Modello di rete isolato

Il modello di rete isolata (o con air gap) viene comunemente utilizzato per i cluster che non hanno bisogno di accedere alla rete aziendale più grande, se non 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 sulla propria rete privata. Se un pod nel cluster deve comunicare con servizi esterni al cluster, questa comunicazione deve utilizzare indirizzi IP pubblici sia per il traffico in entrata che per quello in 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 isolato.

Il diagramma precedente di un modello di rete isolato mostra che i pod in un cluster Kubernetes possono comunicare direttamente tra loro. Il diagramma mostra inoltre che i pod non possono utilizzare gli indirizzi IP interni per comunicare con i pod in altri cluster. Inoltre, i pod possono comunicare con le applicazioni esterne al 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 di indirizzi IP per pod e nodi può essere riutilizzato tra ambienti diversi.

Il modello di rete isolato non è comunemente usato dalle implementazioni di Kubernetes. Tuttavia, potresti 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 connettività ad altri servizi o alla rete aziendale. L'implementazione conseguente presenterebbe gli stessi vantaggi e svantaggi del modello di rete isolato.

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

  • Utilizzo dell'indirizzo IP. Puoi riutilizzare tutti gli indirizzi IP interni nel cluster: indirizzi IP dei nodi, indirizzi IP del servizio 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 controllo completo sugli indirizzi IP nel cluster e non devono eseguire alcuna attività di gestione degli indirizzi IP. Ad esempio, gli amministratori possono allocare lo spazio di indirizzi 10.0.0.0/8 completo a pod e servizi nel cluster, anche se questi indirizzi sono già utilizzati nell'organizzazione.
  • Sicurezza. La comunicazione all'esterno del cluster è strettamente controllata e, se consentita, utilizza interfacce esterne ben definite e NAT.

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

  • Nessuna comunicazione privata. La comunicazione tramite indirizzi IP interni non è consentita con altri cluster o altri servizi nella rete.

Modello di networking GKE

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

Ti consigliamo di utilizzare un cluster nativo di VPC per il tuo ambiente GKE. Puoi creare il tuo cluster nativo di VPC in Standard o Autopilot. Se scegli la modalità Autopilot, la modalità nativa del VPC è sempre attiva e non può essere disattivata. I seguenti paragrafi descrivono il modello di networking di 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 ciascun nodo. A ogni nodo viene assegnata una subnet specifica di un intervallo di indirizzi IP del pod, che selezioni dallo spazio di indirizzi IP interni quando crei il cluster. Per impostazione predefinita, un cluster nativo di VPC assegna una subnet /24 a ciascun 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. Non puoi modificare questa impostazione della subnet.

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

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

Gestire la comunicazione del traffico esterno con un agente di mascheramento IP

Quando comunichi dai pod a servizi esterni al cluster, l'agente di mascheramento IP regola il modo in cui il traffico viene visualizzato per quei servizi. L'agente di mascheramento IP gestisce gli indirizzi IP privati ed esterni in modo diverso, come descritto nei punti seguenti:

Puoi anche utilizzare indirizzi IP pubblici utilizzati privatamente (PUPI) all'interno della tua rete VPC o delle reti connesse. Se utilizzi indirizzi PUPI, puoi comunque trarre vantaggio dal modello di rete completamente integrato e vedere direttamente l'indirizzo IP del pod come origine. Per raggiungere entrambi gli 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 come i pod negli ambienti GKE possono utilizzare gli indirizzi IP interni per comunicare direttamente con le seguenti risorse:

  • Altri pod nello stesso cluster.
  • in altri cluster GKE nella stessa rete VPC.
  • e le 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 lascia il nodo, il nodo in cui si trova il pod utilizza SNAT per mappare l'indirizzo IP del pod all'indirizzo IP del nodo. Quando il traffico lascia il nodo, Cloud NAT traduce l'indirizzo IP del nodo in un indirizzo IP esterno.

Per i vantaggi descritti in precedenza in questo documento, soprattutto 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 in Log di flusso VPC (inclusi i nomi dei pod nei metadati), Mirroring pacchetto, Logging delle regole firewall e nei log delle applicazioni per le destinazioni non sottoposte a mascheramento.

Passaggi successivi