Confrontare i modelli di rete in GKE

Questo documento descrive il modello di rete utilizzato Google Kubernetes Engine (GKE) e come può differire dai modelli di rete in altri Kubernetes ambienti cloud-native. 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 utilizzate da GKE.

Il documento è rivolto ad architetti cloud, ingegneri delle operazioni e ingegneri di rete che potrebbero avere familiarità con 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 spiega come modificare il modello GKE predefinito di rete per soddisfare vari vincoli relativi agli indirizzi IP. In caso di carenza di indirizzi IP durante 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, 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 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 nei seguenti modi:

  • In che modo i pod possono comunicare con i servizi non Kubernetes nell'azienda in ogni rete.
  • In che modo i pod possono comunicare con altri cluster Kubernetes nella stessa dell'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 più comunemente utilizzati e in quale implementazione di Kubernetes vengono utilizzati:

Nome del modello di rete Utilizzato in queste implementazioni
Completamente integrata o piatta
Island-mode o in ponte
Isolato o con isolamento in aria
  • Non è comunemente usato dalle implementazioni Kubernetes, ma può essere usato con qualsiasi implementazione se il cluster viene distribuito in una rete separata VPC (Virtual Private Cloud)

Quando questo documento descrive questi modelli di rete, fa riferimento ai relativi effetti sulle reti on-premise collegate. 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à Cloud VPN o Cloud Interconnect.

Modello di rete completamente integrato

Il modello di rete completamente integrata (o flat) offre facilità di comunicazione con applicazioni esterne a Kubernetes e in altri cluster Kubernetes. Maggiore i provider di servizi cloud di solito implementano questo modello integrare saldamente la propria implementazione Kubernetes rete software-defined (SDN).

Quando utilizzi il modello completamente integrato, gli indirizzi IP che utilizzi per i pod vengono indirizzate all'interno della rete in cui si trova il cluster Kubernetes. Inoltre, la rete sottostante sa su quale nodo vengono individuarlo. 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 è obbligatorio.

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 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 al di fuori indipendentemente dal fatto che le applicazioni si trovino nella stessa rete o reti interconnesse.

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

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

  • Per impostazione predefinita, GKE implementa questo modello. Per maggiori informazioni 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 Amazon VPC Container Networking Interface (CNI) per Kubernetes di 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 i nodi si trovano in 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 utilizzi Azure CNI (networking avanzato). Questa implementazione non è 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 in ogni rete. Questa visibilità rende i dati di telemetria più utili che in altre perché i pod possono essere identificati anche dai dati di telemetria raccolte all'esterno del cluster.
  • Configurazione del firewall più semplice. Quando imposti le regole firewall, differenziare il traffico di nodi e pod è più facile rispetto agli altri modelli di rete.
  • Migliore compatibilità. I pod possono comunicare utilizzando protocolli che non supportano NAT.
  • Debug migliore. 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 Connettività tra 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 integrazione con la rete sottostante poiché Kubernetes l'implementazione 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 bridge) viene comunemente utilizzato per le reti on-premise Implementazioni Kubernetes in cui non è presente un'integrazione profonda con la rete sottostante è possibile. Quando utilizzi un modello di rete in modalità isola, i pod in un ambiente un cluster può comunicare con 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 Un cluster Kubernetes può 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 la comunicazione tra cluster richiede due gateway. Traffico tra due cluster passano attraverso un gateway quando lascia il primo cluster e un altro quando si accede all'altro cluster.

Esistono diversi modi per implementare i gateway o i proxy in un ambiente di rete. Le seguenti implementazioni sono i due gateway o proxy:

  • 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 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 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 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. Pod in un cluster comunicare tra loro direttamente. Tuttavia, il diagramma mostra anche i seguenti pattern di comunicazione esterni al cluster:

    • In che modo i pod comunicano con altri cluster o con ambienti non Kubernetes le applicazioni utilizzando SNAT quando si lascia il nodo.
    • In che modo il traffico proveniente da servizi esterni in altri cluster le applicazioni non Kubernetes entrano nel cluster tramite un servizio NodePort prima di essere inoltrati al pod corretto nel cluster.

  • Utilizzo di macchine virtuali (VM) proxy con più reti interfacce. Questo pattern di implementazione utilizza i proxy per accedere che contiene il cluster Kubernetes. I proxy devono avere accesso allo spazio di 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 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 ancora 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 sia alla rete di destinazione. Inoltre, le comunicazioni che entrano 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 include solo gli indirizzi IP dei nodi. Gli indirizzi IP dei pod non fanno parte nella 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 definiti dall'utente con il forwarding IP attivato sull'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 del traffico in uscita esce 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 dell'indirizzo IP. Gli indirizzi IP dei pod nel cluster possono essere riutilizzati in altri cluster. Tuttavia, gli indirizzi IP già utilizzati da server nella rete aziendale non possono essere utilizzati per i pod se 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 semplificate. Poiché i pod non sono esposti direttamente del resto della rete aziendale, non devi proteggere i pod contro il 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, rende più difficile l'identificazione dell'origine e della destinazione una maggiore quantità di 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 modalità isola, accesso diretto Comunicazione tra pod tra cluster nei mesh di servizi, come Istio o Cloud Service Mesh, è impossibile.

    Esistono ulteriori limitazioni per alcune implementazioni di service mesh. 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 gli indirizzi IP interni per comunicare 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 inoltre mostra che i pod non possono utilizzare gli indirizzi IP interni per comunicare con i pod in cluster. Inoltre, i pod possono comunicare con le applicazioni al di fuori 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 isolato non è comunemente usato 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. Il risultato l'implementazione presenterebbe gli stessi vantaggi e svantaggi dell'applicazione di rete.

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

  • Utilizzo degli indirizzi IP. Puoi riutilizzare tutti gli indirizzi IP interni cluster: indirizzi IP dei nodi, indirizzi IP dei servizi e indirizzi IP dei pod. È possibile riutilizzare gli indirizzi IP interni perché ogni cluster ha il proprio solo rete privata e comunicazione con risorse esterne al cluster avviene attraverso indirizzi IP pubblici.
  • Controllo. Gli amministratori del cluster hanno il pieno controllo sull'assegnazione degli indirizzi 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 all'esterno del cluster è controllata rigorosamente e, se consentito, utilizza interfacce esterne ben definite e NAT.

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 cluster completamente integrato in cui viene eseguito il deployment dei cluster in una rete Virtual Private Cloud (VPC) che può contenere anche altri diverse applicazioni.

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

Gestione degli indirizzi IP nei cluster nativi di VPC

Quando utilizzi un cluster nativo 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 VPC assegna una /24 subnet a ogni nodo da utilizzare come indirizzi IP dei pod. Una subnet /24 corrisponde all'IP 256 indirizzi IP esterni. In Autopilot, il cluster utilizza una subnet /26 corrisponde a 64 indirizzi e questa impostazione non può essere modificata.

Il modello di networking GKE non consente il riutilizzo degli indirizzi IP in tutta la rete. Quando esegui la migrazione a GKE, devi pianificare 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:

Gestisci la comunicazione del traffico esterno con un 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 gli obiettivi, è necessario Includono 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 nello stesso VPC in ogni rete.
  • 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 converte 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 Log di flusso VPC (inclusi i nomi dei pod nei metadati), Mirroring pacchetto, Logging delle regole firewall, e nei log della tua applicazione per le destinazioni non sottoposte a mascheramento.

Passaggi successivi