Best practice per il networking di GKE

Questo documento descrive le best practice per la configurazione delle opzioni di networking per i cluster Google Kubernetes Engine (GKE). È pensata per essere una guida alla pianificazione dell'architettura per cloud architect e ingegneri di rete con consigli sulla configurazione dei cluster applicabili alla maggior parte dei cluster GKE. Prima di creare i cluster GKE, ti consigliamo di esaminare tutte le sezioni di questa pagina per comprendere le opzioni di networking supportate da GKE e le relative implicazioni.

Le opzioni di networking che scegli influiscono sull'architettura dei tuoi cluster GKE. Alcune di queste opzioni non possono essere modificate una volta configurate senza ricreare il cluster.

Prima di leggere questa pagina, assicurati di avere familiarità con i concetti e la terminologia di rete di Kubernetes, alcuni concetti generali di rete e la rete Kubernetes. Per maggiori informazioni, consulta la panoramica della rete GKE.

Durante la revisione di queste best practice, tieni presente quanto segue:

  • Come prevedi di esporre i workload internamente alla tua rete Virtual Private Cloud (VPC), ad altri workload nel cluster, ad altri cluster GKE o esternamente a internet.
  • Come prevedi di scalare i tuoi workload.
  • Quali tipi di servizi Google vuoi utilizzare.

Per un elenco di controllo riepilogativo di tutte le best practice, consulta il Riepilogo dell'elenco di controllo.

Per una panoramica consolidata di tutte le best practice di GKE, consulta Best practice per GKE.

Best practice per la progettazione di VPC

Quando progetti le reti VPC, segui le best practice per la progettazione di VPC.

La sezione seguente fornisce alcuni suggerimenti specifici per GKE per la progettazione di reti VPC.

Best practice:

Utilizza cluster nativi di VPC.
Utilizza reti VPC condivise.

Utilizza cluster nativi di VPC

Ti consigliamo di utilizzare i cluster nativi di VPC. I cluster nativi di VPC utilizzano intervalli di indirizzi IP alias sui nodi GKE e sono obbligatori per i cluster basati sul peering di rete VPC, per i cluster su VPC condivisi e offrono molti altri vantaggi. Per i cluster creati in modalità Autopilot, la modalità VPC nativa è sempre attiva e non può essere disattivata.

I cluster nativi di VPC scalano più facilmente rispetto ai cluster basati su route senza consumare Google Cloud route, quindi sono meno soggetti a raggiungere i limiti di routing.

I vantaggi dell'utilizzo dei cluster nativi di VPC vanno di pari passo con il supporto degli IP alias. Ad esempio, i gruppi di endpoint di rete (NEG) possono essere utilizzati solo con indirizzi IP secondari, pertanto sono supportati solo sui cluster nativi di VPC.

Utilizzare le reti VPC condivise

I cluster GKE richiedono un'attenta pianificazione degli indirizzi IP. La maggior parte delle organizzazioni ha una struttura di gestione centralizzata con un team di amministrazione di rete che può allocare lo spazio degli indirizzi IP per i cluster e un amministratore della piattaforma per il funzionamento dei cluster. Questo tipo di struttura organizzativa funziona bene con l'architettura di rete VPC condiviso di Google Cloud. Nell'architettura di rete VPC condiviso, un amministratore di rete può creare subnet e condividerle con i VPC. Puoi creare cluster GKE in un progetto di servizio e utilizzare le subnet condivise dal VPC condiviso nel progetto host. Il componente dell'indirizzo IP rimane nel progetto host, mentre gli altri componenti del cluster si trovano nel progetto di servizio.

In generale, una rete VPC condiviso è un'architettura utilizzata di frequente e adatta alla maggior parte delle organizzazioni con un team di gestione centralizzato. Ti consigliamo di utilizzare le reti VPC condiviso per creare le subnet per i tuoi cluster GKE ed evitare conflitti di indirizzi IP nella tua organizzazione. Potresti anche voler utilizzare i VPC condivisi per la governance delle funzioni operative. Ad esempio, puoi avere un team di rete che lavora solo sui componenti e sull'affidabilità della rete e un altro team che lavora su GKE.

Strategie di gestione degli indirizzi IP

Tutti i cluster Kubernetes, inclusi i cluster GKE, richiedono un indirizzo IP univoco per ogni pod. Per saperne di più, consulta il modello di networking GKE.

In GKE, tutti questi indirizzi IP sono instradabili in tutta la rete VPC. Pertanto, è necessaria una pianificazione degli indirizzi IP perché gli indirizzi non possono sovrapporsi allo spazio degli indirizzi IP interni utilizzato on-premise o in altri ambienti connessi. Le sezioni seguenti suggeriscono strategie per la gestione degli indirizzi IP con GKE.

Best practice:

Pianifica l'allocazione degli indirizzi IP richiesti.
Utilizza lo spazio non RFC 1918, se necessario.
Utilizza la modalità subnet personalizzata.
Pianifica la densità dei pod per nodo.
Evita sovrapposizioni con gli indirizzi IP utilizzati in altri ambienti.
Crea una subnet del bilanciatore del carico.
Riserva spazio di indirizzi IP sufficiente per il gestore della scalabilità automatica dei cluster.
Condividi indirizzi IP tra cluster.
Condividi gli indirizzi IP per i servizi LoadBalancer interni.

Pianifica l'assegnazione degli indirizzi IP richiesti

Ti consigliamo di utilizzare cluster nativi di VPC con Private Service Connect (PSC). I cluster che utilizzano il peering di rete VPC devono essere cluster nativi di VPC.

I cluster nativi di VPC richiedono i seguenti intervalli di indirizzi IP:

  • Intervallo di indirizzi IP del control plane: utilizza una subnet /28 all'interno degli intervalli privati di indirizzi IP inclusi in RFC 1918. Devi assicurarti che questa subnet non si sovrapponga ad altri indirizzi CIDR (Classless Inter-Domain Routing) nella rete VPC.
  • Subnet del nodo: la subnet con l'intervallo di indirizzi IP primari che vuoi allocare per tutti i nodi del cluster. I servizi di tipo LoadBalancer che utilizzano l'annotazione cloud.google.com/load-balancer-type: "Internal" utilizzano anche questa subnet per impostazione predefinita. Puoi anche utilizzare una subnet dedicata per i bilanciatori del carico interni.
  • Intervallo di indirizzi IP pod: l'intervallo IP che allochi per tutti i pod nel tuo cluster. GKE esegue il provisioning di questo intervallo come alias della subnet. Per saperne di più, consulta Intervalli di indirizzi IP per i cluster VPC nativi.
  • Intervallo di indirizzi IP di servizio: l'intervallo di indirizzi IP che allochi per tutti i servizi nel cluster. GKE esegue il provisioning di questo intervallo come alias della subnet.

Quando configuri la rete del cluster, devi definire una subnet dei nodi, un intervallo di indirizzi IP dei pod e un intervallo di indirizzi IP dei servizi.

Se vuoi utilizzare lo spazio degli indirizzi IP in modo più efficiente, consulta Ridurre l'utilizzo degli indirizzi IP interni in GKE.

L'intervallo di indirizzi IP del control plane è dedicato al control plane gestito da GKE che si trova in un progetto tenant gestito da Google in peering con il tuo VPC. Questo intervallo di indirizzi IP non deve sovrapporsi ad alcun indirizzo IP nel gruppo di peering VPC perché GKE importa questa route nel tuo progetto. Ciò significa che se hai route allo stesso CIDR nel tuo progetto, potresti riscontrare problemi di routing.

Quando crei un cluster, la subnet ha un intervallo principale per i nodi del cluster e deve esistere prima della creazione del cluster. La subnet deve ospitare il numero massimo di nodi che prevedi nel cluster e gli indirizzi IP del bilanciatore del carico interno nel cluster utilizzando la subnet.

Puoi utilizzare il gestore della scalabilità automatica dei cluster per limitare il numero massimo di nodi.

Gli intervalli di indirizzi IP di pod e servizi sono rappresentati come intervalli secondari distinti della subnet, implementati come indirizzi IP alias nei cluster nativi di VPC.

Scegli intervalli di indirizzi IP sufficientemente ampi da poter ospitare tutti i nodi, i pod e i servizi del cluster.

Tieni presente le seguenti limitazioni:

Utilizzare più di indirizzi IP RFC 1918 privati

In alcuni ambienti, lo spazio RFC 1918 in blocchi CIDR contigui di grandi dimensioni potrebbe essere già allocato in un'organizzazione. Puoi utilizzare lo spazio non RFC 1918 per CIDR aggiuntivi per i cluster GKE, se non si sovrappongono agli indirizzi IP pubblici di proprietà di Google. Ti consigliamo di utilizzare la parte 100.64.0.0/10 dello spazio di indirizzi RFC perché lo spazio di indirizzi Classe E può presentare problemi di interoperabilità con l'hardware on-premise. Puoi utilizzare IP pubblici riutilizzati privatamente (PUPI).

Quando utilizzi indirizzi IP pubblici utilizzati privatamente, fai attenzione e valuta la possibilità di controllare gli annunci di route nelle reti on-premise a internet quando scegli questa opzione.

Non devi utilizzare la Network Address Translation di origine (SNAT) in un cluster con traffico da pod a pod e da pod a servizio. Questo interrompe il modello di networking di Kubernetes.

Kubernetes presuppone che tutti gli indirizzi IP non RFC 1918 siano indirizzi IP pubblici riutilizzati privatamente e utilizza SNAT per tutto il traffico proveniente da questi indirizzi.

Se utilizzi un indirizzo IP non RFC 1918 per il tuo cluster GKE, per i cluster Standard dovrai disattivare esplicitamente SNAT o configurare l'agente di IP masquerading per escludere da SNAT gli indirizzi IP dei pod del cluster e gli intervalli di indirizzi IP secondari per i servizi. Per i cluster Autopilot, non sono necessari passaggi aggiuntivi.

Utilizzare la modalità di subnet personalizzata

Quando configuri la rete, selezioni anche la modalità subnet: auto (predefinita) o custom (consigliata). La modalità auto lascia l'allocazione della subnet a Google ed è una buona opzione per iniziare senza pianificare gli indirizzi IP. Tuttavia, ti consigliamo di selezionare la modalità custom perché ti consente di scegliere intervalli di indirizzi IP che non si sovrappongono ad altri intervalli nel tuo ambiente. Se utilizzi un VPC condiviso, un amministratore dell'organizzazione o un amministratore di rete può selezionare questa modalità.

L'esempio seguente crea una rete denominata my-net-1 con modalità subnet personalizzata:

gcloud compute networks create my-net-1 --subnet-mode custom

Pianifica la densità dei pod per nodo

Per impostazione predefinita, i cluster Standard riservano un intervallo /24 per ogni nodo dello spazio di indirizzi dei pod nella subnet e consentono fino a 110 pod per nodo. Tuttavia, puoi configurare un cluster Standard per supportare fino a 512 pod per nodo, con un intervallo /22 riservato per ogni nodo. A seconda delle dimensioni dei nodi e del profilo dell'applicazione dei pod, potresti eseguire un numero notevolmente inferiore di pod su ogni nodo.

Se non prevedi di eseguire più di 64 pod per nodo, ti consigliamo di modificare il numero massimo di pod per nodo per preservare lo spazio degli indirizzi IP nella subnet dei pod.

Se prevedi di eseguire più di 110 pod per nodo predefiniti, puoi aumentare il numero massimo di pod per nodo fino a 512, con /22 riservato per ogni nodo. Con questo tipo di configurazione ad alta densità di pod, consigliamo di utilizzare istanze con 16 o più core CPU per garantire la scalabilità e le prestazioni del cluster.

Per i cluster Autopilot, il numero massimo di pod per nodo viene impostato dinamicamente fino a 256 (riservando fino a un intervallo /23 per nodo). Non puoi configurare questa impostazione nei cluster Autopilot.

Evita sovrapposizioni con gli indirizzi IP utilizzati in altri ambienti

Puoi connettere la tua rete VPC a un ambiente on-premise o ad altri provider di servizi cloud tramite Cloud VPN o Cloud Interconnect. Questi ambienti possono condividere le route, rendendo importante lo schema di gestione degli indirizzi IP on-premise nella pianificazione degli indirizzi IP per GKE. Ti consigliamo di assicurarti che gli indirizzi IP non si sovrappongano a quelli utilizzati in altri ambienti.

Crea una subnet del bilanciatore del carico

Crea una subnet del bilanciatore del carico separata per esporre i servizi con il bilanciamento del carico TCP/UDP interno. Se non viene utilizzata una subnet del bilanciatore del carico separata, questi servizi vengono esposti utilizzando un indirizzo IP della subnet del nodo, il che può portare all'utilizzo di tutto lo spazio allocato in quella subnet prima del previsto e può impedirti di scalare il cluster GKE al numero di nodi previsto.

L'utilizzo di una subnet del bilanciatore del carico separata significa anche che puoi filtrare il traffico verso e da i nodi GKE separatamente dai servizi esposti dal bilanciamento del carico TCP/UDP interno, il che ti consente di impostare limiti di sicurezza più rigidi.

Riserva spazio di indirizzi IP sufficiente per il gestore della scalabilità automatica del cluster

Puoi utilizzare lo scalatore automatico del cluster per aggiungere e rimuovere dinamicamente i nodi nel cluster in modo da poter controllare i costi e migliorare l'utilizzo. Tuttavia, quando utilizzi il gestore della scalabilità automatica dei cluster, assicurati che la pianificazione degli indirizzi IP tenga conto della dimensione massima di tutti i node pool. Ogni nuovo nodo richiede il proprio indirizzo IP, nonché il proprio insieme allocabile di indirizzi IP dei pod in base ai pod configurati per nodo. Il numero di pod per nodo può essere configurato in modo diverso rispetto a quanto configurato a livello di cluster. Non puoi modificare il numero di pod per nodo dopo aver creato il cluster o il pool di nodi. Ti consigliamo di considerare i tipi di workload e di assegnarli a pool di nodi distinti per un'allocazione ottimale degli indirizzi IP.

Valuta la possibilità di utilizzare il provisioning automatico dei nodi con il gestore della scalabilità automatica dei cluster, in particolare se utilizzi cluster nativi di VPC. Per saperne di più, consulta Intervalli di limitazione dei nodi.

Condividi gli indirizzi IP tra i cluster

Potresti dover condividere gli indirizzi IP tra i cluster se hai un team centralizzato che gestisce l'infrastruttura per i cluster. Per condividere gli indirizzi IP tra i cluster GKE, consulta Condivisione di intervalli di indirizzi IP tra i cluster GKE. Puoi ridurre l'esaurimento degli IP creando tre intervalli per pod, servizi e nodi e riutilizzandoli o condividendoli, soprattutto in un modello VPC condiviso. Questa configurazione può anche semplificare la gestione degli indirizzi IP da parte degli amministratori di rete in quanto non richiede la creazione di subnet specifiche per ogni cluster.

Considera quanto segue:

  • Come best practice, utilizza subnet e intervalli di indirizzi IP separati per tutti i cluster.
  • Puoi condividere l'intervallo di indirizzi IP dei pod secondari, ma non è consigliabile perché un cluster potrebbe utilizzare tutti gli indirizzi IP.
  • Puoi condividere gli intervalli di indirizzi IP del servizio secondario, ma questa funzionalità non funziona con Cloud DNS con ambito VPC per GKE.

Se esaurisci gli indirizzi IP, puoi creare intervalli di indirizzi IP dei pod aggiuntivi utilizzando il CIDR multi-pod non contiguo.

Condividere indirizzi IP per i servizi LoadBalancer interni

Puoi condividere un singolo indirizzo IP con un massimo di 50 backend utilizzando porte diverse. In questo modo puoi ridurre il numero di indirizzi IP necessari per i servizi LoadBalancer interni.

Per saperne di più, consulta IP condiviso.

Best practice per la sicurezza di rete

In questa sezione sono descritte alcune raccomandazioni chiave per l'isolamento del cluster. La sicurezza di rete per i cluster GKE è una responsabilità condivisa tra Google e gli amministratori dei cluster.

Best practice:

Utilizza GKE Dataplane V2.
Ridurre al minimo l'esposizione dei nodi.
Ridurre al minimo l'esposizione del control plane del cluster.
Autorizza l'accesso al control plane.
Consenti la connettività del control plane.
Deploy proxies for control plane access from peered networks (Deployment di proxy per l'accesso al control plane dalle reti in peering).
Limita il traffico del cluster utilizzando le policy di rete.
Attiva le policy di sicurezza di Google Cloud Armor per Ingress.
Utilizza Identity-Aware Proxy per fornire l'autenticazione per le applicazioni con utenti IAM.
Utilizza i vincoli delle policy dell'organizzazione per migliorare ulteriormente la sicurezza.

Utilizza GKE Dataplane V2

GKE Dataplane V2 si basa su eBPF e offre un'esperienza integrata di sicurezza e visibilità della rete. Quando crei un cluster utilizzando GKE Dataplane V2, non devi abilitare esplicitamente i criteri di rete perché GKE Dataplane V2 gestisce il routing dei servizi, l'applicazione dei criteri di rete e la registrazione. Abilita il nuovo dataplane con l'opzione --enable-dataplane-v2 di Google Cloud CLI durante la creazione di un cluster. Una volta configurate le policy di rete, è possibile configurare un oggetto CRD NetworkLogging predefinito per registrare le connessioni di rete consentite e negate. Ti consigliamo di creare cluster con GKE Dataplane V2 per sfruttare appieno le funzionalità integrate, come il logging delle policy di rete.

Riduci al minimo l'esposizione dei nodi

In un cluster con soli nodi privati, i pod sono isolati dalle comunicazioni in entrata e in uscita (il perimetro del cluster). Puoi controllare questi flussi direzionali esponendo i servizi utilizzando il bilanciamento del carico e Cloud NAT, descritti nella sezione Connettività del cluster di questo documento. Il seguente diagramma mostra questo tipo di configurazione:

Diagramma 1: comunicazione tra nodi privati

Questo diagramma mostra come può comunicare un cluster con nodi privati. I client on-premise possono connettersi al cluster con il client kubectl. L'accesso ai servizi Google viene fornito tramite l'accesso privato Google e la comunicazione con internet è disponibile solo utilizzando Cloud NAT.

Ridurre al minimo l'esposizione del control plane del cluster

Il control plane ha due tipi di endpoint per l'accesso al cluster:

  • Endpoint basato su DNS
  • Endpoint basati su IP
Best practice:

Utilizza solo l'endpoint basato su DNS per accedere al control plane per una configurazione semplificata e un livello di sicurezza flessibile e basato su policy.

L'endpoint DNS è accessibile da qualsiasi rete raggiungibile dalle Google Cloud API, incluse le reti on-premise o di altri cloud. Per abilitare l'endpoint basato su DNS, utilizza il flag --enable-dns-access.

Il server API GKE può essere esposto anche come endpoint pubblico o privato basato su IP. Puoi decidere quale endpoint utilizzare quando crei il cluster. Puoi controllare l'accesso con le reti autorizzate, in cui gli endpoint pubblici e privati consentono per impostazione predefinita tutte le comunicazioni tra l'indirizzo IP del pod e l'indirizzo IP del nodo nel cluster. Per abilitare un endpoint privato quando crei un cluster, utilizza il flag --enable-private-endpoint.

Autorizza l'accesso al control plane

Le reti autorizzate possono aiutare a stabilire quali subnet di indirizzi IP possono accedere ai nodi del control plane GKE. Dopo aver attivato queste reti, puoi limitare l'accesso a intervalli di indirizzi IP di origine specifici. Se l'endpoint pubblico è disabilitato, questi intervalli di indirizzi IP di origine devono essere privati. Se è abilitato un endpoint pubblico, puoi consentire intervalli di indirizzi IP pubblici o interni. Configura le pubblicità di route personalizzati per consentire all'endpoint privato del control plane del cluster di essere raggiungibile da un ambiente on-premise. Puoi rendere l'endpoint API GKE privato raggiungibile a livello globale utilizzando l'opzione --enable-master-global-access quando crei un cluster.

Il seguente diagramma mostra la connettività tipica del control plane utilizzando le reti autorizzate:

Diagramma 2: connettività del control plane tramite reti autorizzate

Questo diagramma mostra gli utenti attendibili in grado di comunicare con il control plane GKE tramite l'endpoint pubblico in quanto fanno parte di reti autorizzate, mentre l'accesso da attori non attendibili è bloccato. La comunicazione con e dal cluster GKE avviene tramite l'endpoint privato del control plane.

Consenti la connettività del control plane

Alcuni pod di sistema su ogni nodo di lavoro dovranno raggiungere servizi come il server API Kubernetes (kube-apiserver), le API di Google o il server di metadati. Il kube-apiserverdeve comunicare anche con alcuni pod di sistema, ad esempio event-exporter. Questa comunicazione è consentita per impostazione predefinita. Se implementi regole firewall VPC all'interno dei progetti (maggiori dettagli nella sezione Limita il traffico del cluster), assicurati che questi pod possano continuare a comunicare con kube-apiserver e con le API di Google.

Esegui il deployment dei proxy per l'accesso al control plane dalle reti in peering

Se il tuo cluster utilizza il peering di rete VPC, non puoi accedere al control plane del cluster da un'altra rete in peering.

Se vuoi l'accesso diretto da un'altra rete in peering o on-premise quando utilizzi un'architettura hub and spoke, esegui il deployment dei proxy per il traffico del control plane.

Limitare il traffico del cluster utilizzando le policy di rete

Per i workload del cluster è possibile combinare più livelli di sicurezza di rete: regole firewall VPC, policy del firewall gerarchiche e policy di rete Kubernetes. Le regole firewall VPC e i criteri firewall gerarchici si applicano a livello di macchina virtuale (VM), ovvero ai nodi worker in cui risiedono i pod del cluster GKE. Le policy di rete Kubernetes vengono applicate a livello di pod per applicare i percorsi del traffico da pod a pod.

Se implementi i firewall VPC, puoi interrompere la comunicazione predefinita e richiesta del control plane, ad esempio la comunicazione di kubelet con il control plane. GKE crea regole firewall obbligatorie per impostazione predefinita, ma possono essere sovrascritte. Alcune implementazioni potrebbero richiedere al control plane di raggiungere il cluster sul servizio. Puoi utilizzare i firewall VPC per configurare una policy di ingresso che renda accessibile il servizio.

Le policy di rete GKE vengono configurate tramite l'API Kubernetes Network Policy per applicare la comunicazione dei pod di un cluster. Puoi attivare le policy di rete quando crei un cluster utilizzando l'opzione gcloud container clusters create --enable-network-policy. Per limitare il traffico utilizzando le policy di rete, puoi seguire la guida all'implementazione del progetto Anthos per la limitazione del traffico.

Abilita le policy di sicurezza di Google Cloud Armor per l'ingresso

Utilizzando i criteri di sicurezza di Google Cloud Armor, puoi proteggere le applicazioni che utilizzano i bilanciatori del carico delle applicazioni esterni da attacchi DDoS e altri attacchi basati sul web bloccando questo traffico all'edge della rete. In GKE, attiva le policy di sicurezza di Google Cloud Armor per le applicazioni utilizzando Ingress per i bilanciatori del carico delle applicazioni esterni e aggiungendo una policy di sicurezza a BackendConfig collegato all'oggetto Ingress.

Utilizza Identity-Aware Proxy per fornire l'autenticazione per le applicazioni con utenti IAM

Se vuoi eseguire il deployment di servizi a cui possono accedere solo gli utenti della tua organizzazione, senza richiedere che siano connessi alla rete aziendale, puoi utilizzare Identity-Aware Proxy per creare un livello di autenticazione per queste applicazioni. Per abilitare Identity-Aware Proxy per GKE, segui i passaggi di configurazione per aggiungere Identity-Aware Proxy come parte di BackendConfig per il servizio Ingress. Identity-Aware Proxy può essere combinato con Google Cloud Armor.

Utilizza i vincoli delle policy dell'organizzazione per migliorare ulteriormente la sicurezza

Utilizzando i vincoli dei criteri dell'organizzazione, puoi impostare criteri per migliorare ulteriormente la tua postura di sicurezza. Ad esempio, puoi utilizzare i vincoli per limitare la creazione di bilanciatori del carico a determinati tipi, ad esempio solo bilanciatori del carico interni.

Scalabilità della connettività del cluster

Questa sezione illustra le opzioni scalabili per la connettività DNS e in uscita dai tuoi cluster verso internet e i servizi Google.

Best practice:

Utilizza Cloud DNS per GKE.
Abilita NodeLocal DNSCache.
Utilizza Cloud NAT per l'accesso a internet dai cluster.
Utilizza l'accesso privato Google per accedere ai servizi Google.

Utilizzare Cloud DNS per GKE

Puoi utilizzare Cloud DNS per GKE per fornire la risoluzione DNS di pod e servizi con DNS gestito senza un provider DNS ospitato nel cluster. Cloud DNS elimina il sovraccarico di gestione di un server DNS ospitato nel cluster e non richiede scalabilità, monitoraggio o gestione delle istanze DNS perché è un servizio Google ospitato.

Abilita NodeLocal DNSCache

GKE utilizza kube-dns per fornire il servizio DNS locale del cluster come componente aggiuntivo del cluster predefinito. kube-dns viene replicato nel cluster in funzione del numero totale di core e nodi nel cluster.

Puoi migliorare le prestazioni del DNS con NodeLocal DNSCache. NodeLocal DNSCache è un componente aggiuntivo di cui viene eseguito il deployment come DaemonSet e non richiede modifiche alla configurazione dei pod. Le ricerche DNS nel servizio pod locale non creano connessioni aperte che devono essere monitorate sul nodo, il che consente una maggiore scalabilità. Le ricerche di nomi host esterni vengono inoltrate a Cloud DNS, mentre tutte le altre query DNS vengono inviate a kube-dns.

Abilita NodeLocal DNSCache per tempi di ricerca delle query DNS più coerenti e una migliore scalabilità del cluster. Per i cluster Autopilot, NodeLocal DNSCache è abilitato per impostazione predefinita e non può essere sostituito.

La seguente opzione Google Cloud CLI abilita NodeLocal DNSCache quando crei un cluster: --addons NodeLocalDNS.

Se hai il controllo del nome che le applicazioni cercano di risolvere, esistono modi per migliorare lo scaling DNS. Ad esempio, utilizza un FQDN (termina il nome host con un punto) o disattiva l'espansione del percorso di ricerca tramite l'opzione del manifest Pod.dnsConfig.

Utilizzare Cloud NAT per l'accesso a internet dai cluster

Per impostazione predefinita, i cluster con nodi privati abilitati non hanno accesso a internet. Per consentire ai pod di accedere a internet, attiva Cloud NAT per ogni regione. Come minimo, abilita Cloud NAT per gli intervalli principali e secondari nella subnet GKE. Assicurati di allocare un numero sufficiente di indirizzi IP per Cloud NAT e porte per VM.

Utilizza le seguenti best practice per la configurazione del gateway Cloud NAT quando utilizzi Cloud NAT per i cluster:

  • Quando crei il gateway Cloud NAT, attivalo solo per gli intervalli di subnet utilizzati dai tuoi cluster. Contando tutti i nodi in tutti i cluster, puoi determinare il numero di VM consumer NAT nel progetto.

  • Utilizza l'allocazione dinamica delle porte per allocare numeri diversi di porte per VM in base all'utilizzo della VM stessa. Inizia con un minimo di 64 porte e un massimo di 2048 porte.

  • Se devi gestire molte connessioni simultanee alla stessa tupla di destinazione, riduci il timeout TCP TIME_WAIT dal valore predefinito di 120s a 5s. Per saperne di più, consulta Modificare i timeout NAT.

  • Attiva il logging degli errori di Cloud NAT per controllare i log correlati.

  • Controlla i log del gateway Cloud NAT dopo averlo configurato. Per ridurre i problemi relativi allo stato di allocazione "Eliminato", potrebbe essere necessario aumentare il numero massimo di porte per VM.

Devi evitare il doppio SNAT per il traffico dei pod (SNAT prima sul nodo GKE e poi di nuovo con Cloud NAT). A meno che tu non abbia bisogno di SNAT per nascondere gli indirizzi IP dei pod verso le reti on-premise connesse tramite Cloud VPN o Cloud Interconnect, disable-default-snat e scarica il monitoraggio SNAT su Cloud NAT per la scalabilità. Questa soluzione funziona per tutti gli intervalli IP delle subnet primarie e secondarie. Utilizza le policy di rete per limitare il traffico esterno dopo aver attivato Cloud NAT. Cloud NAT non è necessario per accedere ai servizi Google.

Utilizza l'accesso privato Google per accedere ai servizi Google

Nei cluster con nodi privati, i pod non hanno indirizzi IP pubblici per raggiungere servizi pubblici, tra cui API di Google e servizi. L'accesso privato Google consente alle risorseGoogle Cloud private di raggiungere i servizi Google.

L'accesso privato Google è abilitato per impostazione predefinita nei cluster con nodi privati, ad eccezione dei cluster VPC condiviso.

Best practice per lo scaling delle applicazioni

Quando crei applicazioni raggiungibili esternamente o internamente alla tua organizzazione, assicurati di utilizzare il tipo e le opzioni di bilanciatore del carico corretti. Questa sezione fornisce suggerimenti sull'esposizione e sulla scalabilità delle applicazioni con Cloud Load Balancing.

Best practice:

Utilizza il bilanciamento del carico nativo del container.
Scegli la risorsa GKE corretta per esporre la tua applicazione.
Crea controlli di integrità basati su BackendConfig.
Utilizza la policy del traffico locale per conservare gli indirizzi IP originali.
Utilizza Private Service Connect.

Utilizzare il bilanciamento del carico nativo del container

Utilizza il bilanciamento del carico nativo dei container quando esponi i servizi utilizzando HTTP(S) esternamente. Il bilanciamento del carico nativo del container riduce gli hop di rete, abbassa la latenza e fornisce una distribuzione del traffico più precisa. Aumenta inoltre la visibilità del tempo di round trip e consente di utilizzare funzionalità di bilanciamento del carico come Google Cloud Armor.

Scegli la risorsa GKE corretta per esporre la tua applicazione

A seconda dell'ambito dei tuoi client (interni, esterni o anche interni al cluster), della regionalità della tua applicazione e dei protocolli che utilizzi, puoi scegliere di utilizzare diverse risorse GKE per esporre la tua applicazione. La panoramica di Service Networking spiega queste opzioni e può aiutarti a scegliere la risorsa migliore per esporre ogni parte della tua applicazione utilizzando Google Cloud le opzioni di bilanciamento del carico.

Crea controlli di integrità basati su BackendConfig

Se utilizzi un Ingress per esporre i servizi, utilizza una configurazione del controllo di integrità in un CRD BackendConfig per utilizzare la funzionalità di controllo di integrità del bilanciatore del carico delle applicazioni esterno. Puoi indirizzare il controllo di integrità all'endpoint appropriato e impostare le tue soglie. Senza una CRD BackendConfig, i controlli di integrità vengono dedotti dai parametri del probe di idoneità o utilizzano parametri predefiniti.

Utilizza il criterio di gestione del traffico locale per conservare gli indirizzi IP originali

Quando utilizzi un bilanciatore del carico di rete passthrough interno con GKE, imposta l'opzione externalTrafficPolicy su Local per conservare l'indirizzo IP di origine delle richieste. Utilizza questa opzione se la tua applicazione richiede l'indirizzo IP di origine originale. Tuttavia, l'opzione externalTrafficPolicy local può comportare una distribuzione del carico meno ottimale, quindi utilizza questa funzionalità solo quando necessario. Per i servizi HTTP(S), puoi utilizzare i controller Ingress e ottenere l'indirizzo IP originale leggendo l'intestazione X-Forwarded-For nella richiesta HTTP.

Utilizzare Private Service Connect

Puoi utilizzare Private Service Connect per condividere i servizi del bilanciatore del carico di rete passthrough interno con altre reti VPC. Ciò è utile per i servizi ospitati su cluster GKE, ma che servono clienti che operano in progetti e VPC diversi.

Puoi utilizzare Private Service Connect per ridurre il consumo di indirizzi IP fornendo connettività tra VPC con indirizzi IP sovrapposti.

Best practice operative

Best practice:

Utilizza IAM per le autorizzazioni GKE per controllare le policy nelle VPC condiviso condivise.
Utilizza i cluster a livello di regione e distribuisci i workload per l'alta affidabilità.
Utilizza Cloud Logging e Cloud Monitoring e attiva la registrazione delle policy di rete.

Le sezioni seguenti contengono best practice operative che ti aiutano a garantire opzioni di autorizzazione granulari per i tuoi workload. Per evitare di creare regole firewall manuali, segui le best practice operative riportate in questa sezione. Include anche suggerimenti per la distribuzione dei workload e per il monitoraggio e il logging in GKE.

Utilizzare IAM per le autorizzazioni GKE per controllare i criteri nelle reti VPC condiviso

Quando utilizzi le reti VPC condivise, le regole firewall per i bilanciatori del carico vengono create automaticamente nel progetto host.

Per evitare di dover creare manualmente le regole firewall, assegna un ruolo personalizzato con privilegi minimi al account di servizio GKE nel progetto host denominato service-HOST_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com.

Sostituisci HOST_PROJECT_NUMBER con il numero di progetto del progetto host per il VPC condiviso.

Il ruolo personalizzato che crei deve disporre delle seguenti autorizzazioni:

  • compute.firewalls.create
  • compute.firewalls.get
  • compute.firewalls.list
  • compute.firewalls.delete

Inoltre, le regole firewall create da GKE hanno sempre la priorità predefinita di 1000, quindi puoi impedire il flusso di traffico specifico creando regole firewall con una priorità più alta.

Se vuoi limitare la creazione di determinati tipi di bilanciatori del carico, utilizza le policy dell'organizzazione per limitare la creazione dei bilanciatori del carico.

Utilizza i cluster a livello di regione e distribuisci i workload per un'alta affidabilità

I cluster a livello di regione possono aumentare la disponibilità delle applicazioni in un cluster perché il control plane e i nodi del cluster sono distribuiti in più zone.

Tuttavia, per garantire la migliore esperienza utente possibile in caso di errore di zona, utilizza lo scaler automatico del cluster per assicurarti che il cluster possa gestire il carico richiesto in qualsiasi momento.

Puoi anche utilizzare Pod anti-affinity per assicurarti che i pod di un determinato servizio siano pianificati in più zone.

Per ulteriori informazioni su come configurare queste impostazioni per l'alta affidabilità e l'ottimizzazione dei costi, consulta Best practice per i cluster GKE ad alta affidabilità.

Utilizza Cloud Logging e Cloud Monitoring e attiva il logging delle policy di rete

Sebbene ogni organizzazione abbia requisiti diversi per la visibilità e il controllo, ti consigliamo di attivare la registrazione delle policy di rete. Questa funzionalità è disponibile solo con GKE Dataplane V2. La registrazione dei criteri di rete fornisce visibilità sull'applicazione dei criteri e sui pattern di traffico dei pod. Tieni presente che sono previsti costi per la registrazione dei log delle norme di rete.

Per i cluster GKE che utilizzano la versione 1.14 o successive, Logging e Monitoring sono entrambi abilitati per impostazione predefinita. Monitoring fornisce una dashboard per i tuoi cluster GKE. Logging abilita anche le annotazioni GKE per i log di flusso VPC. Per impostazione predefinita, Logging raccoglie i log per tutti i workload di cui è stato eseguito il deployment nel cluster, ma esiste anche un'opzione per i log solo di sistema. Utilizza la dashboard GKE per osservare e impostare gli avvisi. Per i cluster creati in modalità Autopilot, il monitoraggio e la registrazione vengono attivati automaticamente e non possono essere configurati.

Tieni presente che sono previsti costi per Google Cloud Observability.

Best practice per la distribuzione uniforme del traffico

Questa sezione fornisce pratiche consigliate per una distribuzione uniforme del traffico. Prima di implementarle, assicurati di aver implementato un monitoraggio appropriato (ad esempio utilizzando Prometheus, Cloud Monitoring o i servizi di monitoraggio del tuo provider di servizi cloud) per identificare e confermare modelli di distribuzione non uniformi.

Disattiva o configura attentamente l'affinità sessione

Per risolvere il problema, disattiva l'affinità sessione, a meno che non sia assolutamente necessario. Imposta sessionAffinity: None nel manifest del servizio. Se devi utilizzare l'affinità di sessione, valuta attentamente le implicazioni e monitora il carico dei pod. L'affinità di sessione garantisce che un utente rimanga connesso allo stesso backend per la durata di una sessione.

Utilizza il bilanciamento del carico ponderato

Per implementare questa pratica, configura il servizio in modo che utilizzi il bilanciamento del carico ponderato. Il bilanciamento del carico ponderato distribuisce il traffico in base al numero di pod integri per nodo. Il bilanciatore del carico invia nuove connessioni a un nodo GKE in proporzione al numero di pod integri in quel nodo. Per un bilanciatore del carico di rete passthrough esterno in GKE, il bilanciamento del carico ponderato consente ai nodi con più pod di gestione di ricevere una percentuale maggiore di nuove connessioni.

Per abilitare il bilanciamento del carico ponderato, devi soddisfare i seguenti requisiti e configurare il servizio con annotazioni specifiche:

  • Versione del cluster GKE: il cluster GKE deve utilizzare la versione 1.31.0-gke.1506000 o successive.
  • Componente aggiuntivo Bilanciamento del carico HTTP: il componente aggiuntivo HttpLoadBalancing deve essere abilitato per il cluster (è abilitato per impostazione predefinita). Se il tuo cluster utilizza la versione 1.36 o successive, questo componente aggiuntivo non è un prerequisito per i servizi di backend.
  • Bilanciatore del carico basato sul servizio di backend: imposta il campo spec.loadBalancerClass su networking.gke.io/l4-regional-external nel manifest del servizio per assicurarti che GKE crei un bilanciatore del carico di rete passthrough esterno basato sul servizio di backend. Questo campo richiede GKE 1.33.1-gke.1779000 o versioni successive. I bilanciatori del carico basati su pool di destinazione non supportano il bilanciamento del carico ponderato.
  • Annotazione di bilanciamento del carico ponderato: includi l'annotazione networking.gke.io/weighted-load-balancing: pods-per-node nel manifest del servizio.
  • Policy del traffico esterno: il manifest del Service deve utilizzare externalTrafficPolicy: Local. Sebbene externalTrafficPolicy: Cluster sia consentito, disabilita di fatto il bilanciamento del carico ponderato, poiché i pacchetti potrebbero essere indirizzati a un nodo diverso dopo la distribuzione iniziale del bilanciatore del carico.
  1. Salva il seguente manifest di esempio come weighted-lb-service.yaml:
apiVersion: v1
kind: Service
metadata:
  name: my-weighted-service
  annotations:
    networking.gke.io/weighted-load-balancing: pods-per-node
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-external
  externalTrafficPolicy: Local
  selector:
    app: my-app
  ports:
    -   protocol: TCP
      port: 80
      targetPort: 8080

  1. Applica il manifest al tuo cluster:

    kubectl apply -f weighted-lb-service.yaml

Questa configurazione evita di sovraccaricare le istanze di backend distribuendo le nuove connessioni in modo proporzionale al numero di pod su ciascun nodo. Inoltre, conserva l'affinità dell'indirizzo IP client e l'indirizzo IP di origine originale del client per l'applicazione grazie a externalTrafficPolicy: Local.

Garantire una distribuzione uniforme dei pod tra i nodi

Utilizza l'anti-affinità dei pod per impedire che i pod dello stesso servizio vengano pianificati sullo stesso nodo. Definisci le regole di anti-affinità dei pod nei manifest di deployment.

L'esempio seguente mostra un manifest di deployment con anti-affinità tra pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 6
  template:
    metadata:
      labels:
        app: my-app
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          -   labelSelector:
              matchExpressions:
              -   key: app
                operator: In
                values:
                -   my-app
            topologyKey: "kubernetes.io/hostname"

Esaminare le norme sul traffico esterno

Utilizza Cluster come externalTrafficPolicy per consentire al bilanciatore del carico di distribuire il traffico a qualsiasi nodo del cluster. Imposta externalTrafficPolicy: Cluster nel manifest del servizio. Utilizza questa impostazione se devi distribuire il traffico in modo uniforme su tutti i nodi.

Se utilizzi Local, assicurati di distribuire i pod in modo uniforme tra i nodi.

Disabilita l'affinità dei nodi

Rimuovi le configurazioni di affinità dai tuoi deployment se riscontri hotspot.

Utilizzare i probe di idoneità

Configura i probe di idoneità sui tuoi pod. Definisci i probe di idoneità nei manifest dei pod. In questo modo, il bilanciatore del carico invia il traffico solo ai pod pronti a gestire le richieste.

L'esempio seguente mostra un manifest di pod con un probe di idoneità:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  -   name: my-container
    image: my-image
    readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10

Utilizzare il bilanciamento del carico nativo del container

Se possibile, utilizza il bilanciamento del carico nativo del container. Il bilanciatore del carico distribuisce il traffico direttamente ai pod, anziché ai nodi. In questo modo, la distribuzione del traffico migliora e la latenza si riduce. Per ulteriori informazioni, consulta Informazioni sul bilanciamento del carico in GKE.

Prendi in considerazione il routing sensibile alla topologia

Valuta la possibilità di utilizzare il routing basato sulla topologia. Questa funzionalità mira a mantenere il traffico all'interno della zona di origine, migliorando le prestazioni e riducendo i costi. Questa funzionalità funziona meglio quando il traffico in entrata è distribuito in modo uniforme e i servizi Kubernetes hanno tre o più endpoint per zona. Per saperne di più, consulta la pagina Risoluzione dei problemi relativi alla distribuzione del traffico.

Cloud Service Mesh

Per un controllo più granulare della distribuzione del traffico, delle policy di routing avanzate e dell'osservabilità, valuta la possibilità di implementare un Cloud Service Mesh come Istio. Cloud Service Mesh opera a livello di applicazione e fornisce funzionalità avanzate di gestione del traffico.

Elenco di controllo di riepilogo

Area Esercitazioni
Progettazione VPC
Strategie di gestione degli indirizzi IP
Opzioni di sicurezza di rete
Scalabilità
Pubblicazione di applicazioni
Operazioni e amministrazione
Distribuzione uniforme del traffico

Passaggi successivi