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 del 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 di rete per la loro organizzazione. Per ulteriori informazioni sui ruoli comuni e sulle attività di esempio all'interno di Google Cloud, consulta Ruoli e attività utente comuni di GKE Enterprise.

Prima di procedere, assicurati di avere familiarità con 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 control plane 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 funzionalità di routing integrata consente la comunicazione diretta tra i pod, anche tra 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 stabile (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.

  • Control plane: nei cluster privati, il control plane si trova 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 control plane e i nodi nella rete VPC del tuo cluster. Questa connessione in genere utilizza Private Service Connect.

  • Bilanciatori del carico: per esporre le applicazioni a internet o all'interno della rete VPC, puoi configurare GKE in modo che utilizzi i bilanciatori del caricoGoogle Cloud . 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 riepiloga come 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 principali della subnet associata al node pool 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 suo nodo.
Service (ClusterIP) GKE assegna a ogni servizio un indirizzo IP virtuale stabile (ClusterIP) da un intervallo di indirizzi IP secondari dedicato all'interno della rete VPC del cluster.
Control plane Nei cluster privati, il control plane GKE ha un 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 Kubernetes astratto 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). In questo modo si garantisce uno spazio di rete flat in cui i pod possono raggiungersi a vicenda utilizzando gli indirizzi IP assegnati.

  • Implementazione dell'indirizzamento IP GKE: GKE implementa il modello di indirizzamento IP Kubernetes su Google Cloud integrandosi con il networking nativo VPC. Quando crei un pod, GKE alloca il suo 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 risorse, come le istanze Compute Engine e i database Cloud SQL. Google Cloud Analogamente, GKE gestisce gli indirizzi IP Service di Kubernetes (ad esempio ClusterIP) all'interno della rete VPC. Quando crei servizi LoadBalancer per l'esposizione esterna, GKE esegue il provisioning dei bilanciatori del caricoGoogle Cloud . Questi bilanciatori del carico utilizzano indirizzi IP pubblici o interni della tua rete VPC. GKE utilizza Google Cloudl'infrastruttura di networking e indirizzamento IP 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 nativo VPC, che è una funzionalità Google Cloud di base.

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 chiave:

  • Instradabilità nativa VPC:gli indirizzi IP dei pod sono direttamente instradabili all'interno della tua rete VPC. Ciò semplifica la progettazione della rete e consente una comunicazione diretta e a bassa latenza tra i pod e altre risorse, come le istanze Compute Engine e le istanze Cloud SQL. Google Cloud
  • Conserva la quota di route:utilizzando indirizzi IP alias per i pod, GKE non crea route statiche personalizzate per ogni nodo. In questo modo viene conservata la quota di route VPC, un miglioramento significativo rispetto ai cluster basati su route legacy, ed è importante per le implementazioni su larga scala.
  • Migliora la sicurezza: la funzionalità di routing nativo VPC consente di applicare regole firewall native VPC 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 lo scalabilità del cluster senza richiedere una riarchitettura di rete distruttiva.
  • Garantisci l'affidabilità: evita intervalli di indirizzi IP sovrapposti tra il tuo cluster GKE e altre reti, ad esempio 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 rete, tra cui IPv4, doppio stack (IPv4 e IPv6) e le prossime opzioni solo IPv6.

Solo IPv4 (stack singolo)

Si tratta della 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 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 intervalli di indirizzi IP pubblici per l'uso interno all'interno della tua 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 va a buon fine. L'agente di mascheramento IP lo impedisce modificando l'indirizzo IP di origine dei pacchetti in uscita da PUPI del pod all'indirizzo IP interno del nodo. In questo modo, il traffico di ritorno viene indirizzato correttamente al nodo e poi inoltrato al pod originale.

Stack doppio (IPv4 e IPv6)

Un cluster a doppio stack utilizza sia il protocollo IPv4 che IPv6. GKE assegna un indirizzo IPv4 e 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 workload pronti per 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