Confrontare i modelli di rete in GKE

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

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

Il documento è per Cloud Architect, Operations Engineer e Network Engineer che potrebbero conoscere altre implementazioni Kubernetes e hanno intenzione di utilizzare GKE. Questo documento presuppone che tu conosca Kubernetes e il suo modello di rete di base. Dovresti anche avere familiarità con concetti di networking come gli indirizzi IP, il NAT (Network Address Translation), i firewall e i proxy.

Questo documento non spiega come modificare il modello di rete GKE predefinito per soddisfare vari vincoli degli indirizzi IP. Se hai una carenza di indirizzi IP quando esegui la migrazione a GKE, 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 Kubernetes che soddisfano questi requisiti.

Queste implementazioni possono essere raggruppate in tre tipi di modelli di rete. Questi tre modelli si differenziano per i seguenti aspetti:

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

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

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

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

La descrizione di questi modelli di rete in questo documento fa riferimento ai loro effetti sulle reti on-premise connesse. Tuttavia, puoi applicare i concetti descritti per le reti on-premise connesse a reti connesse tramite una rete privata virtuale (VPN) o un'interconnessione privata, incluse 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 (o flat) completamente integrato offre facilità di comunicazione con le applicazioni esterne a Kubernetes e in altri cluster Kubernetes. I principali provider 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 utilizzati 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 uno specifico intervallo di indirizzi IP dei pod preassegnati. Tuttavia, questo intervallo di indirizzi preassegnati non è obbligatorio.

Il seguente diagramma mostra le opzioni di comunicazione per i 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 schemi 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 della tecnologia NAT per comunicare con altre applicazioni all'esterno del cluster, a prescindere dal fatto che queste applicazioni si trovino nella stessa rete o 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 gli indirizzi IP dei pod direttamente dallo spazio di indirizzi VPC. Il plug-in CNI assegna 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 quando si utilizza Azure CNI (networking avanzato). Questa implementazione non è la configurazione predefinita. In questa implementazione, ogni pod ottiene 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 è uguale 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. Quando imposti le regole firewall, la differenziazione del traffico di nodi e pod è più facile 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 Anthos Service Mesh, possono comunicare facilmente tra i cluster perché i pod possono comunicare direttamente tra loro. Alcune implementazioni di mesh di servizi supportano solo la connettività pod-pod per 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, poiché l'implementazione di Kubernetes richiede di programmare direttamente l'SDN. La programmazione dell'SDN è trasparente per l'utente e non produce 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à a isola

Il modello di rete in modalità isola (o 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 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 inoltre che i pod in un cluster devono utilizzare un gateway o un proxy per comunicare con le applicazioni esterne al cluster o con i pod in altri cluster. Mentre la comunicazione tra un cluster e un'applicazione esterna richiede un unico gateway, la comunicazione cluster-to-cluster richiede due gateway. Il traffico tra due cluster passa attraverso un gateway quando si esce dal primo cluster e un altro gateway quando si entra nell'altro cluster.

Esistono diversi modi per implementare gateway o 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 comunemente utilizzata 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ù ampia. Il traffico in uscita da un pod all'esterno del cluster può essere indirizzato verso altri cluster o 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 NAT di origine 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, assegni a tali 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'utilizzo 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 direttamente tra loro. Tuttavia, il diagramma mostra anche i seguenti pattern di comunicazione all'esterno del cluster:

    • In che modo i pod comunicano con altri cluster o applicazioni non Kubernetes utilizzando SNAT quando escono dal 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 di indirizzi IP dei pod e dei nodi. In questo pattern, ciascuna VM proxy presenta 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 le VM proxy.

    Il diagramma precedente mostra che l'utilizzo 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 verso 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 le comunicazioni che entrano nel cluster dall'esterno passano 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 di 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. ma ricevono indirizzi IP da uno spazio logico diverso. Il modello in modalità isola utilizzato da AKS instrada anche il traffico tra i pod tra i nodi utilizzando route definite dall'utente con l'inoltro IP attivato nell'interfaccia dei nodi. Per la comunicazione tra pod con 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 offre 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 è necessario che la comunicazione avvenga tra i pod e questi servizi. Di conseguenza, la best practice per il networking in modalità isola è prenotare uno spazio di indirizzi IP del 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'utilizzo di un modello di rete in modalità isola presenta i seguenti svantaggi:

  • Telemetria imprecisa. I dati di telemetria raccolti all'esterno 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 l'origine e la destinazione del traffico.
  • È più 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. Pertanto, le impostazioni firewall risultanti consentono a tutti i pod su un nodo e al nodo stesso di raggiungere i servizi esterni o a nessuno di essi di raggiungere servizi esterni.

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

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

Modello di rete isolato

Il modello di rete isolato (o con air gap) viene comunemente utilizzato per i cluster che non hanno bisogno di accedere alla più grande rete aziendale, se non tramite API rivolte al pubblico. Se 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 in entrata che 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 indirizzi IP interni per comunicare con i pod in altri cluster. Inoltre, i pod possono comunicare con applicazioni all'esterno 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 è possibile riutilizzare lo stesso spazio di indirizzi IP per pod e nodi in ambienti diversi.

Il modello di rete isolato non è comunemente utilizzato dalle implementazioni Kubernetes. Tuttavia, potresti ottenere un modello di rete isolato in qualsiasi implementazione. Devi solo eseguire il deployment di un cluster Kubernetes in una rete separata o VPC 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 nel cluster: indirizzi IP dei nodi, indirizzi IP di 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 attività di gestione degli indirizzi IP. Ad esempio, gli amministratori possono allocare l'intero spazio di indirizzi 10.0.0.0/8 a pod e servizi nel cluster, anche se questi indirizzi sono già utilizzati nell'organizzazione.
  • Sicurezza. La comunicazione all'esterno del cluster è controllata rigorosamente e, se consentita, utilizza interfacce esterne 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 verso 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 VPC è sempre attiva e non può essere disattivata. I seguenti paragrafi descrivono il modello di networking 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 per utilizzarlo come indirizzi IP dei pod. Una subnet /24 corrisponde a 256 indirizzi IP. In Autopilot, il cluster utilizza una subnet /26 che corrisponde a 64 indirizzi e non puoi modificare questa impostazione per la subnet.

Il modello di networking di GKE non consente il riutilizzo degli 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, i pod possono ricevere traffico, per impostazione predefinita, dalle seguenti risorse:

Gestire le comunicazioni relative al traffico esterno con l'agente di mascheramento IP

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

Puoi anche utilizzare indirizzi IP pubblici utilizzati privatamente (PUPI) all'interno della tua rete VPC o delle reti connesse. Se usi indirizzi PUPI, puoi comunque trarre vantaggio dal modello di rete completamente integrato e visualizzare l'indirizzo IP del pod direttamente 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 in che modo 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 gli indirizzi IP interni per comunicare direttamente con le seguenti risorse:

  • Altri pod nello stesso cluster.
  • 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. 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 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 pacchetto, nel logging delle regole firewall e nei log delle applicazioni per le destinazioni non mascherate.

Passaggi successivi