Informazioni sull'indirizzamento IP in GKE

Per creare cluster Google Kubernetes Engine (GKE) scalabili e sicuri, devi gestire in modo efficace l'indirizzamento IP. Questo documento fornisce una panoramica completa di come GKE utilizza gli indirizzi IP per la comunicazione dei cluster, dei modelli di networking supportati e delle best practice per una gestione efficace degli indirizzi IP.

Questo documento è destinato agli architetti cloud e agli specialisti di networking che progettano e realizzano l'architettura della rete per la loro organizzazione. Per ulteriori informazioni sui ruoli comuni e sulle attività di esempio Google Cloud, consulta Ruoli e attività utente comuni di GKE Enterprise.

Prima di procedere, assicurati di conoscere i seguenti concetti:

In che modo gli indirizzi IP connettono i componenti GKE

GKE si basa sul modello di networking di Kubernetes, che richiede che ogni componente abbia un indirizzo IP distinto per la comunicazione. Le sezioni seguenti descrivono come GKE assegna e utilizza gli indirizzi IP per i componenti principali del cluster:

  • Nodi: GKE assegna a ogni nodo, che è un'istanza VM di Compute Engine, un indirizzo IP interno dall'intervallo di indirizzi IP principale della subnet associata al relativo pool di nodi. Questo indirizzo IP consente la comunicazione tra il nodo e il piano di controllo Kubernetes. I nodi possono anche avere un indirizzo IP esterno per l'accesso a internet in uscita.

  • Pod: seguendo il modello "IP per pod" di Kubernetes, GKE assegna a ogni pod un indirizzo IP univoco da un intervallo CIDR pod allocato al nodo. In GKE, la rete VPC instrada in modo nativo gli indirizzi IP dei pod. Questa instradabilità integrata consente la comunicazione diretta tra i pod, anche su nodi diversi, senza richiedere la Network Address Translation (NAT). Tutti i container all'interno di un singolo pod condividono lo stesso indirizzo IP e possono comunicare tramite localhost.

  • Servizi: GKE assegna a ogni servizio Kubernetes un indirizzo IP virtuale statico (ClusterIP) da un intervallo di indirizzi IP secondari dedicato. Questo ClusterIP fornisce un endpoint singolo e affidabile per un gruppo di pod. Quando invii traffico a ClusterIP, GKE lo bilancia automaticamente su un pod integro all'interno di quel servizio.

  • Piano di controllo: nei cluster privati, il piano di controllo risiede all'interno di un progetto tenant gestito da Google e utilizza il proprio intervallo di indirizzi IP interni. Questo progetto tenant si connette alla tua rete VPC, consentendo una comunicazione sicura tra il piano di controllo e i nodi nella rete VPC del cluster. In genere, questa connessione utilizza Private Service Connect.

  • Bilanciatori del carico: per esporre le applicazioni a internet o all'interno della tua rete VPC, puoi configurare GKE in modo che utilizzi i Google Cloud bilanciatori del carico. I bilanciatori del carico esterni utilizzano indirizzi IP pubblici. I bilanciatori del carico interni utilizzano indirizzi IP interni dall'intervallo di subnet principale della rete VPC.

La tabella seguente riassume in che modo GKE assegna gli indirizzi IP ai componenti del cluster:

Componente Come vengono assegnati gli indirizzi IP
Nodo GKE assegna un indirizzo IP interno a ogni nodo. GKE alloca questo indirizzo IP dall'intervallo di indirizzi IP principale della subnet associata al pool di nodi del nodo. Questa subnet può essere la subnet predefinita del cluster o una subnet aggiuntiva.
Pod GKE assegna a ogni pod un indirizzo IP univoco dall'intervallo CIDR pod allocato al relativo nodo.
Servizio (ClusterIP) GKE assegna a ogni servizio un indirizzo IP virtuale statico (ClusterIP) da un intervallo di indirizzi IP secondari dedicato all'interno della rete VPC del cluster.
Control plane Nei cluster privati, il piano di controllo GKE ha il proprio intervallo di indirizzi IP interni all'interno di un progetto tenant gestito da Google. Questo progetto tenant si connette alla tua rete VPC, in genere utilizzando Private Service Connect.
Bilanciatore del carico I bilanciatori del carico esterni utilizzano indirizzi IP pubblici. I bilanciatori del carico interni utilizzano indirizzi IP interni dall'intervallo di indirizzi IP principale della subnet del cluster.

Indirizzamento IP di Kubernetes e implementazione GKE

Per utilizzare GKE in modo efficace, devi comprendere le differenze tra il modello di networking astratto di Kubernetes e il modo in cui GKE implementa questo modello su Google Cloud.

  • Modello di indirizzamento IP di Kubernetes: il progetto open source Kubernetes specifica che ogni pod riceve un indirizzo IP univoco. Tutti gli indirizzi IP dei pod possono comunicare direttamente senza Network Address Translation (NAT). Questo approccio contribuisce a garantire uno spazio di rete flat in cui i pod possono raggiungersi a vicenda utilizzando gli indirizzi IP assegnati.

  • Implementazione dell'indirizzamento IP di GKE: GKE implementa il modello di indirizzamento IP di Kubernetes su Google Cloud integrandosi con il networking VPC nativo. Quando crei un pod, GKE alloca il relativo indirizzo IP da un intervallo di indirizzi IP alias VPC. In questo modo, l'indirizzo IP di ogni pod è instradabile in modo nativo all'interno dell'intera rete VPC. Ciò consente la comunicazione diretta non solo tra i pod, ma anche con altre Google Cloud risorse, come le istanze Compute Engine e i database Cloud SQL. Allo stesso modo, GKE gestisce gli indirizzi IP dei Service Kubernetes (come i ClusterIP) all'interno della rete VPC. Quando crei LoadBalancer servizi per l'esposizione esterna, GKE esegue il provisioning Google Cloud dei bilanciatori del carico. Questi bilanciatori del carico utilizzano indirizzi IP pubblici o interni della rete VPC. GKE utilizza Google Cloud' l'infrastruttura di indirizzamento IP e di networking robusta per implementare i concetti di networking basati su IP di Kubernetes in modo scalabile e sicuro

Modello di networking GKE: cluster VPC nativi

GKE implementa il modello di networking di Kubernetes utilizzando il networking VPC nativo, che è una funzionalità di base Google Cloud .

Questo modello utilizza intervalli di indirizzi IP alias. In un cluster VPC nativo, Kubernetes configura gli indirizzi IP dei pod come intervalli di indirizzi IP alias sull'interfaccia di rete virtuale del nodo.

Questa implementazione offre diversi vantaggi principali:

  • Instradabilità VPC nativa:gli indirizzi IP dei pod sono instradabili direttamente all'interno della rete VPC. Ciò semplifica la progettazione della rete e consente una comunicazione diretta a bassa latenza tra i pod e altre Google Cloud risorse, come le istanze Compute Engine e le istanze Cloud SQL.
  • Conserva la quota di route:utilizzando gli indirizzi IP alias per i pod, GKE non crea route statiche personalizzate per ogni nodo. Ciò consente di conservare la quota di route VPC, un miglioramento significativo rispetto ai cluster legacy basati su route, ed è importante per i deployment su larga scala.
  • Migliora la sicurezza:l'instradabilità VPC nativa ti consente di applicare le regole firewall VPC native direttamente al traffico dei pod, migliorando la sicurezza a livello di rete.

VPC nativo è la modalità di networking predefinita e consigliata per tutti i cluster GKE.

Perché una gestione efficace degli indirizzi IP è fondamentale

Per garantire che il cluster possa scalare e mantenere l'integrità dell'applicazione, devi pianificare in modo efficace lo spazio degli indirizzi IP:

  • Garantisci la scalabilità: pianifica in modo efficace gli intervalli di indirizzi IP di nodi, pod e servizi per evitare l'esaurimento degli indirizzi IP e consentire al cluster di scalare senza richiedere una riprogettazione della rete che possa causare interruzioni.
  • Garantisci l'affidabilità: evita di sovrapporre gli intervalli di indirizzi IP tra il tuo cluster GKE e altre reti, come gli ambienti on-premise connessi tramite Cloud VPN. Gli intervalli sovrapposti possono causare conflitti di routing, comportamenti imprevedibili e interruzioni del servizio.
  • Rafforza la sicurezza: gestisci gli indirizzi IP in modo efficace per rafforzare la sicurezza della rete. Definisci i criteri di rete di Kubernetes per controllare il flusso di traffico tra i pod e configura le regole firewall per l'isolamento dei carichi di lavoro a livello di rete.

Scegli un modello di indirizzamento IP per il cluster

GKE supporta diverse configurazioni dello stack di rete per soddisfare i tuoi requisiti di networking, tra cui le opzioni solo IPv4, dual-stack (IPv4 e IPv6) e le opzioni solo IPv6 in arrivo.

Solo IPv4 (stack singolo)

Questa è la configurazione standard e più comune, in cui tutti i componenti del cluster utilizzano indirizzi IPv4. Anche all'interno di un modello solo IPv4, GKE offre flessibilità:

  • Indirizzi IP privati RFC 1918: utilizza gli intervalli di indirizzi IP privati RFC 1918 (ad esempio, 10.0.0.0/8) per il cluster.
  • Indirizzi IP pubblici utilizzati privatamente (PUPI): se la tua organizzazione non dispone di spazio di indirizzi IP privati sufficiente, puoi utilizzare gli intervalli di indirizzi IP pubblici per l'uso interno all'interno della rete VPC. Quando utilizzi i PUPI, devi configurare l'agente di mascheramento IP. Questo agente esegue la Network Address Translation dell'origine (SNAT) sul traffico in uscita dai pod. Senza SNAT, il traffico di ritorno a un pod che utilizza un PUPI viene instradato sulla rete internet pubblica e non riesce. L'agente di mascheramento IP impedisce questo comportamento modificando l'indirizzo IP di origine dei pacchetti in uscita dal PUPI del pod all'indirizzo IP interno del nodo. Questo approccio contribuisce a garantire che il traffico di ritorno venga instradato correttamente al nodo e poi inoltrato al pod originale.

Dual-stack (IPv4 e IPv6)

Un cluster dual-stack utilizza sia il protocollo IPv4 che IPv6. GKE assegna sia un indirizzo IPv4 che un indirizzo IPv6 a nodi, pod e servizi in un cluster dual-stack. Questo modello è ideale per:

  • Facilitare una transizione graduale a IPv6.
  • Garantire la compatibilità sia con i carichi di lavoro compatibili con IPv6 sia con i client e i servizi esistenti solo IPv4.

Puoi abilitare il networking dual-stack quando crei un cluster oppure puoi aggiornare un cluster single-stack esistente a dual-stack.

Passaggi successivi