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ò differire dai modelli di rete in altri ambienti Kubernetes. Questo documento tratta i seguenti concetti:

  • I modelli di rete più comuni utilizzati da varie implementazioni di 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 è destinato ad architetti cloud, ingegneri delle operazioni e ingegneri di rete che potrebbero avere familiarità con altre implementazioni di Kubernetes e che prevedono di utilizzare GKE. Questo documento presuppone che tu conosca Kubernetes e il suo modello di networking di base. Dovresti anche avere familiarità con i concetti di networking come l'indirizzamento IP, Network Address Translation (NAT), firewall e proxy.

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

Implementazioni tipiche del modello 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 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.
  • Se gli indirizzi IP dei pod possono essere riutilizzati in altri cluster o altrove nella rete aziendale.

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

La seguente tabella identifica i tre tipi di modelli 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 a ponte
Isolato o air-gap
  • Non comunemente utilizzato dalle implementazioni Kubernetes, ma può essere utilizzato con qualsiasi implementazione quando il cluster viene implementato in una rete separata o in un virtual private cloud (VPC)

Quando questo documento descrive questi modelli di rete, si riferisce ai loro 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 integrato (o flat) offre facilità di comunicazione con 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 definita dal software (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 del 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 pattern 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 al di fuori del 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 cluster diversi.

Disponibilità

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

  • Per impostazione predefinita, GKE implementa questo modello. Per ulteriori informazioni su questa implementazione, consulta la sezione 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 indirizzi IP ai 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 utilizza Azure CNI (networking avanzato). Questa implementazione non è la configurazione predefinita. In questa implementazione, a ogni pod viene assegnato un indirizzo IP dalla subnet. Puoi anche configurare il numero massimo di pod per nodo. Pertanto, il numero di indirizzi IP riservati in anticipo per i pod su quel nodo è uguale al numero massimo di pod per nodo.

Vantaggi

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, differenziare il traffico dei nodi e dei pod è più semplice nel modello di rete completamente integrato rispetto agli altri modelli.
  • Maggiore 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 service mesh. I service mesh, 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 solo la connettività da pod a pod per le service mesh multi-cluster.

Svantaggi

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 da riservare ai 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 la SDN. La programmazione della 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à isolata

Il modello di rete in modalità isolata (o bridged) viene 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à isolata, 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 del pod in un modello di rete in modalità isolata:

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

Il diagramma precedente di un modello di rete in modalità isolata mostra come i pod all'interno di 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 quando comunicano 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:

  • Utilizzo dei nodi come gateway. Questa implementazione viene comunemente utilizzata quando i nodi del 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 la connettività dall'interno del cluster alla rete più grande. Il traffico in uscita da un pod verso l'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 source NAT (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 tra i nodi e indirizzato 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à isolata che utilizza i nodi come gateway.

    Il diagramma precedente mostra che l'utilizzo dei nodi come gateway non ha un impatto sulla comunicazione da pod a pod all'interno di un cluster. I pod in un cluster comunicano ancora direttamente tra loro. 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.
    • Come 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.

  • Utilizzo di 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 del nodo. In questo pattern, ogni VM proxy ha due interfacce di rete: una nell'ampia rete aziendale e una nella rete contenente il cluster Kubernetes.

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

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

    Il diagramma precedente mostra che l'utilizzo di proxy in modalità isolata 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 passi 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.

Disponibilità

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

  • Per impostazione predefinita, Azure Kubernetes Service (AKS) utilizza il networking in modalità isolata quando utilizza il networking Kubenet (di base). Quando AKS utilizza il networking in modalità isolata, 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, invece, ricevono indirizzi IP da uno spazio logico diverso. Il modello in modalità isolata utilizzato da AKS instrada anche il traffico da pod a pod tra i nodi utilizzando route definite dall'utente con l'inoltro 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 che il traffico di uscita esca dal nodo.
  • In Oracle Container Engine for Kubernetes (OKE), la comunicazione pod-to-pod utilizza una rete di 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.

Vantaggi

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

  • Utilizzo dell'indirizzo IP. Gli indirizzi IP dei pod nel cluster possono essere riutilizzati in altri cluster. Tuttavia, i cluster VPC nativi predefiniti di GKE non supportano il riutilizzo degli intervalli di indirizzi IP dei pod in più cluster all'interno della stessa rete VPC. In GKE, gli indirizzi IP dei pod sono direttamente instradabili all'interno della tua rete VPC. Pertanto, gli indirizzi IP dei pod devono essere univoci in tutti i cluster e le risorse all'interno di un singolo VPC. Se hai bisogno di riutilizzare gli indirizzi IP, esegui il deployment dei cluster GKE in reti VPC separate. Indipendentemente dal modello di rete, i pod che devono comunicare con servizi esterni nella rete aziendale non possono utilizzare indirizzi IP già utilizzati da questi servizi esterni. Per il networking in modalità isolata, la best practice consiste nel riservare uno spazio di indirizzi IP dei pod univoco all'interno della rete aziendale e utilizzare questo spazio di indirizzi IP per tutti i cluster che utilizzano questa configurazione in modalità isolata.

  • Impostazioni di sicurezza più semplici. Poiché i pod non sono esposti direttamente al resto della rete aziendale, non devi proteggerli dal traffico in entrata dal resto della rete aziendale.

Svantaggi

L'utilizzo di un modello di rete in modalità isolata 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 l'origine e la destinazione del traffico.
  • Più difficili da eseguire il debug. Durante il debug, non puoi connetterti direttamente ai pod dall'esterno del cluster.
  • Firewall più difficili da configurare. Puoi utilizzare solo gli indirizzi IP dei nodi quando configuri il firewall. Pertanto, le impostazioni del firewall risultanti consentono a tutti i pod su un nodo e al nodo stesso di raggiungere servizi esterni oppure non consentono a nessuno di raggiungere servizi esterni.

  • Compatibilità con i service mesh. Con la modalità isolata, la comunicazione diretta pod-to-pod tra i cluster nei service mesh, 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 multirete, la comunicazione deve avvenire tramite Istio Gateways, il che rende più complessi i deployment di mesh di servizi multicluster.

Modello di rete isolata

Il modello di rete isolata (o air gap) viene utilizzato più comunemente per i cluster che non hanno bisogno di accedere alla rete aziendale più grande, se non tramite API pubbliche. Quando utilizzi un modello di rete isolata, 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 l'ingresso che per l'uscita.

Il seguente diagramma mostra le opzioni di comunicazione del pod in un modello di rete isolata:

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

Il diagramma precedente di un modello di rete isolata mostra che i pod all'interno di un cluster Kubernetes possono comunicare direttamente tra loro. Il diagramma mostra anche che i pod non possono utilizzare indirizzi IP interni per comunicare con i pod in 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 di indirizzi IP per pod e nodi può essere riutilizzato tra ambienti diversi.

Disponibilità

Il modello di rete isolata non è comunemente utilizzato 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 un VPC separato senza alcuna connettività ad altri servizi o alla rete aziendale. L'implementazione risultante avrebbe gli stessi vantaggi e svantaggi del modello di rete isolato.

Vantaggi

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 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 dell'indirizzamento IP nel cluster e non devono eseguire alcuna 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 al di fuori del cluster è strettamente controllata e, quando consentita, utilizza interfacce esterne e NAT ben definite.

Svantaggi

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

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

Modello di networking GKE

GKE utilizza un modello di rete completamente integrato in cui i cluster vengono implementati 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 della VPC in modalità Standard o Autopilot. Se scegli la modalità Autopilot, la modalità VPC nativa è sempre attiva e non può essere disattivata. I paragrafi seguenti descrivono il modello di networking GKE in Standard con note sulle differenze rispetto ad Autopilot.

Informazioni sulla gestione degli indirizzi IP nei cluster VPC nativi

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 interni quando crei il cluster. Per impostazione predefinita, un cluster nativo di VPC assegna una subnet /24 a ogni nodo da utilizzare 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 della subnet.

Il modello di networking 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:

Gestisci 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 determina l'aspetto del traffico per questi servizi. L'agente di mascheramento IP gestisce gli indirizzi IP privati ed esterni in modo diverso, come descritto nei seguenti punti elenco:

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 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.

Comprendere il flusso di traffico dei pod in una rete GKE

Il seguente diagramma mostra come possono comunicare i pod nel 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 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. Dopo che il traffico esce dal nodo, Cloud NAT traduce l'indirizzo IP del nodo in un indirizzo IP esterno.

Per i vantaggi descritti in precedenza in questo documento, in particolare 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), Packet Mirroring, registrazione delle regole firewall e nei log delle applicazioni per le destinazioni non mascherate.

Passaggi successivi