Confronta 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 a Cloud Architect, Operations Engineer e Networking tecnici che potrebbero avere familiarità con altre implementazioni Kubernetes e sono per l'uso di GKE. In questo documento si presuppone che tu familiarità con Kubernetes e le sue funzionalità di base modello di networking. Avere anche familiarità con i concetti di networking, come l'indirizzamento IP, Network Address Translation (NAT), firewall e 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, 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 nodi senza utilizzare NAT.

Ci sono state più di 20 implementazioni diverse per il modello di rete di Kubernetes sviluppate 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 in nella rete aziendale.

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

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

Nome modello di rete Utilizzato in queste implementazioni
Completamente integrata o piatta
Modalità isola o in ponte
Isolato o con air gap
  • 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 il presente documento descrive questi modelli di rete, fa riferimento ai loro degli effetti sulle reti on-premise connesse. Tuttavia, puoi applicare i concetti descritto per le reti on-premise connesse alle 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à 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 una di indirizzi IP dei pod preassegnati e specifici. Ma questo intervallo di indirizzi preassegnato non è obbligatorio.

Il seguente diagramma mostra le opzioni di comunicazione dei pod nella modello di networking:

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 quanto segue 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é si trovano all'interno della 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 in implementazioni:

  • Per impostazione predefinita, GKE implementa questo modello. Per ulteriori 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 un intervallo di indirizzi IP del pod dedicato per nodo.
  • In Azure, AKS implementa questo modello quando si utilizza Azure CNI (networking avanzato). Questa implementazione non è 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 di 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 usando protocolli non supportano NAT.
  • Debug migliore. Se consentito dal firewall, le risorse all'esterno di un cluster può raggiungere i pod direttamente durante il processo di debug.
  • Compatibilità con i mesh di servizi. Mesh di servizi, come Istio o Cloud Service Mesh, possono comunicare facilmente tra i cluster perché i pod possono comunicare l'una con l'altra. 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 dell'indirizzo IP. Non puoi riutilizzare gli indirizzi IP dei pod all'interno e ogni indirizzo IP deve essere univoco. Questi requisiti possono generare un grande numero di indirizzi IP che devono essere riservati per i pod.
  • Requisiti per l'SDN. Un modello di rete completamente integrato richiede integrazione con la rete sottostante poiché Kubernetes l'implementazione deve programmare direttamente l'SDN. La programmazione del Lo SDN è trasparente per gli utenti e non genera video rivolti agli utenti svantaggi. Tuttavia, modelli di rete così integrati facilmente implementabili 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 di Kubernetes in cui non esiste 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 modalità a isola modello di networking:

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 inoltre mostra che i pod in un cluster devono utilizzare un gateway o un proxy per le comunicazioni 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:

  • Utilizzo dei nodi come gateway. Questa implementazione è di uso comune quando i nodi nel cluster fanno parte della rete esistente e il loro 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. Traffico in uscita da un pod all'esterno un cluster può essere diretto verso altri cluster o verso non Kubernetes, ad esempio per chiamare un'API on-premise 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 le applicazioni che si trovano all'esterno del cluster per comunicare con i servizi all'interno puoi utilizzare NodePort tipo di servizio per la maggior parte delle implementazioni. In alcune implementazioni, puoi utilizzare il LoadBalancer per esporre i servizi. Quando utilizzi il tipo di servizio LoadBalancer, fornisci a questi servizi un indirizzo IP virtuale con bilanciamento del carico nodi e instradati 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 pod-to-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 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 ancora comunicare direttamente tra loro. Tuttavia, il diagramma mostra anche comunicazione dai pod ad altri cluster o applicazioni non Kubernetes passa attraverso un proxy che ha accesso sia alla rete del cluster che 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 Networking Kubenet (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 indirizzi IP da un indirizzo spazio logico. Il modello in modalità isola utilizzato da AKS instrada anche i pod il traffico tra i nodi utilizzando route definite dall'utente con 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 del traffico in uscita esce dal nodo.
  • In Oracle Container Engine per Kubernetes (OKE), la comunicazione usa Rete overlay VXLAN. Inoltre, il traffico proveniente I pod alle applicazioni esterne al cluster utilizzano 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. Di conseguenza, per il networking in modalità isolana è la prenotazione di uno spazio di indirizzi IP dei pod univoco all'interno della rete e di utilizzare questo spazio di indirizzi IP per tutte 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. Dati di telemetria raccolti al di fuori contiene 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 di 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 solo l'IP del nodo quando configuri il firewall. Di conseguenza, il firewall risultante consentono a tutti i pod su un nodo e al nodo stesso di raggiungere servizi esterni o consentire a nessuno di raggiungere servizi esterni.

  • Compatibilità con i mesh di servizi. Con modalità isola, diretto Comunicazione tra pod tra cluster nei mesh di servizi, come Istio o Cloud Service Mesh, è impossibile.

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

Modello di rete isolato

Il modello di rete isolata (o con air gap) è più comunemente utilizzato per i cluster che non hanno bisogno di accedere alla rete aziendale più grande, se non attraverso 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 sulla propria rete privata. Se un pod è presente il cluster deve comunicare con servizi esterni al cluster, 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 una rete isolata modello:

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 all'interno di un Un cluster Kubernetes può 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 di indirizzi IP per pod e nodi può essere riutilizzato in diversi ambienti.

Il modello di rete isolato non è comunemente usato dalle implementazioni di Kubernetes. Tuttavia, potresti ottenere un modello di rete isolato in qualsiasi implementazione. Tu devi solo eseguire il deployment di un cluster Kubernetes in una rete separata VPC senza la connettività ad altri servizi o alla rete aziendale. Il risultato l'implementazione presenterebbe gli stessi vantaggi e svantaggi dell'implementazione di rete.

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

  • Utilizzo dell'indirizzo 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 controllo completo degli indirizzi IP nel cluster e non devono eseguire attività di gestione delle applicazioni. Ad esempio, gli amministratori possono allocare 10.0.0.0/8 di spazio di indirizzi a pod e servizi nel cluster, anche se questi di indirizzi IP 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. Comunicazione mediante indirizzi IP interni non è consentito ad altri cluster o altri servizi nella rete.

Modello di networking GKE

GKE utilizza un cluster 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 altri diverse applicazioni.

Ti consigliamo di utilizzare un cluster nativo di 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 di VPC, gli indirizzi IP dei pod indirizzi IP secondari su ciascun nodo. A ogni nodo è assegnata una subnet specifica dell'IP di un pod di indirizzi IP interni che selezioni dallo spazio di indirizzi IP interni per creare il cluster. Per impostazione predefinita, un cluster nativo di VPC assegna Una subnet /24 a ciascun nodo per utilizzarli 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:

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

Quando comunichi dai pod a servizi esterni al cluster, Agente di mascheramento IP e il modo in cui il traffico viene visualizzato da questi servizi. L'agente di mascheramento IP gestisce indirizzi IP privati ed esterni in modo diverso, come descritto di seguito Punti elenco:

Puoi anche utilizzare indirizzi IP pubblici utilizzati privatamente (PUPI) all'interno della tua rete VPC o di reti connesse. Se utilizzi gli indirizzi PUPI, possono comunque trarre vantaggio dal modello di rete completamente integrato e vedere l'indirizzo IP del pod direttamente come fonte. 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 Modello di networking 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 di risorse:

  • Altri pod nello stesso cluster.
  • Pod in altri cluster GKE nello stesso VPC in ogni rete.
  • 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 lascia il nodo, in cui si trova il pod usa 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, soprattutto per il vantaggio di avere gli indirizzi IP dei pod visibili in tutta la telemetria di dati, 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