Google PCNE: GKE, container e networking delle applicazioni — Guida allo studio

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Fa parte della Google Professional Cloud Network Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Google Kubernetes Engine (GKE) si integra strettamente con il networking di Google Cloud. Progettare per l’affidabilità e la sicurezza richiede la comprensione dell’indirizzamento IP VPC-native, dei piani di controllo privati, del traffico in uscita (egress), del traffico nord-sud e est-ovest, dell’applicazione delle policy e dei costrutti multi-cluster. Questa sezione fornisce linee guida di progettazione, logica operativa e modalità di guasto comuni per il networking di container e applicazioni su Google Cloud.

Architettura IP di GKE e cluster privati

Cluster VPC-native

• Utilizzano IP alias con due intervalli secondari in una subnet VPC: uno per i Pod (PodCIDR) e uno per i Service (ServiceCIDR). Questo evita lo SNAT basato su iptables sui nodi, abilita il bilanciamento del carico container-native con i NEG e offre una scalabilità migliore rispetto ai cluster basati su route.
• Linee guida per il dimensionamento:
  • Pod: allocare PodsPerNode × MaxNodes, più un margine (headroom) del 20–30%. Ad esempio, 10 nodi attuali × 20 Pod + una crescita fino a 100 × 200 suggerisce un intervallo /17 per i Pod; i Service spesso rientrano in un /21 per oltre 2000 servizi.
  • Service: ogni ClusterIP consuma un indirizzo IP; tenere conto di un margine per le migrazioni da headless a ClusterIP e per gli add-on.
• Modalità di guasto:
  • Esaurimento degli IP dei Pod: i Pod rimangono in stato Pending o compaiono errori CNI/IPAM; scalare l’intervallo secondario dei Pod o ridurre il numero massimo di pod per nodo, quindi ricreare i nodi.
  • Esaurimento degli IP dei Service: i nuovi Service non riescono ad allocare un ClusterIP; espandere l’intervallo secondario dei Service.
  • Sovrapposizione degli intervalli alias: la creazione del cluster fallisce o si verificano blackhole di routing; verificare che non ci siano sovrapposizioni con altre subnet o VPC in peering.

Cluster privati, accesso al piano di controllo e traffico in uscita dai nodi

• I cluster privati limitano l’endpoint del piano di controllo a un indirizzo privato RFC1918, raggiungibile solo dalla tua VPC tramite peering del producer. I nodi non richiedono indirizzi IP esterni.
• Per gli operatori, le opzioni sono:
  • Solo endpoint privato: il piano di controllo è raggiungibile dalle subnet della VPC e dalle reti connesse. Utilizzare un bastion host o Cloud Shell con Private Service Connect per raggiungerlo.
  • Endpoint pubblico con Authorized Networks: espone il piano di controllo su un IP pubblico, protetto da specifici CIDR di origine. Questa opzione è comoda ma aumenta l’esposizione; utilizzarla solo con uno scoping CIDR restrittivo e solidi controlli sull’identità degli amministratori.
• Traffico in uscita (egress) dai nodi:
  • Per i nodi senza IP esterni, fornire connettività in uscita verso Internet tramite Cloud NAT. Ciò consente aggiornamenti del sistema operativo, pull di immagini container da registry esterni e accesso ad API di partner, mantenendo i nodi privati.
  • Per l’accesso alle API di Google e ad Artifact/Container Registry senza IP esterni, abilitare l’Accesso Privato Google (PGA) sulle subnet dei nodi. PGA risolve e instrada il traffico verso le API/registry di Google all’edge di Google senza indirizzi IP di origine pubblici. PGA è la scelta preferita per il pull delle immagini; combinarlo con Cloud NAT se è richiesta anche connettività in uscita non verso Google.
  • Se si invia il traffico 0.0.0.0/0 attraverso un firewall di terze parti, abilitare comunque PGA e aggiungere route statiche per gli intervalli VIP delle API di Google verso il gateway Internet predefinito per bypassare il firewall per i servizi Google.

Scalabilità e risoluzione dei problemi IP

• Monitorare il consumo di IP alias a livello di intervallo secondario della subnet. Se la pressione sugli IP aumenta:
  • Aumentare le dimensioni degli intervalli secondari (aggiungere intervalli più grandi, ricreare il cluster o migrare i carichi di lavoro dove necessario).
  • Regolare il parametro max-pods-per-node per bilanciare l’uso di IP per nodo rispetto alla frammentazione dello scheduling.
  • Eliminare i Service abbandonati; i Service headless non allocano ClusterIP, ma la loro conversione in ClusterIP consumerà indirizzi IP.
• Pianificare la crescita multi-regionale con intervalli secondari non sovrapposti per evitare di dover ri-indirizzare gli IP quando si utilizzano Shared VPC, VPC Peering o servizi multi-cluster.

Ingress, Gateway API, Services e policy

Services e load balancer

• Tipi di Service:
  • ClusterIP: accesso solo all’interno del cluster; il traffico east-west utilizza kube-proxy o dataplane v2.
  • NodePort: alloca una porta su ciascun nodo; utilizzato da molti LB come backend, ma evitare di esporlo direttamente su Internet.
  • LoadBalancer: esegue il provisioning di un load balancer cloud. I load balancer L4 esterni o interni supportano TCP/UDP; l’affinità di sessione ClientIP fornisce la stickiness tra più protocolli quando necessario.
• Il load balancing container-native utilizza i Network Endpoint Groups (NEG) in modo che il load balancer indirizzi direttamente le coppie IP:porta dei Pod, migliorando la segnalazione dello stato di salute (health signaling) e riducendo i salti (hop) tra i nodi. Per GKE, utilizzare i NEG di Pod GKE (GCE_POD). Altri tipi di NEG includono VM_IP_PORT, Internet FQDN e PSC.
• Ingress e Gateway API di GKE:
  • Ingress è stabile per il traffico HTTP(S) north-south con il load balancer HTTP(S) esterno globale di Google o il load balancer HTTP(S) interno regionale. Il controller programma automaticamente gli health check e le regole firewall per i pattern standard.
  • La Gateway API fornisce un modello più espressivo con Gateway e HTTPRoute/TCPRoute. Supporta configurazioni multi-tenant, routing avanzato e una specifica coerente tra i vari ambienti. Scegliere la Gateway API per garantire la compatibilità futura (future-proofing); utilizzare Ingress dove la semplicità e la compatibilità sono importanti.

Restrizione dei client e health check

• La restrizione dei client a specifici intervalli di origine (source range) può essere effettuata a livello L4 con regole firewall VPC che hanno come target le istanze di backend, o a livello L7 con le policy di Cloud Armor sui load balancer HTTP(S).
• Consentire sempre gli intervalli di origine dell’health checker di Google verso i target di backend o i Pod, in modo che gli health check abbiano successo. In alcune implementazioni, GKE crea automaticamente le regole k8s-fw; se si aggiungono regole restrittive, mantenere regole di autorizzazione (allow) esplicite per gli intervalli dell’health checker.
• Approccio di esempio per i backend L4: assegnare ai nodi il tag “application” e creare una regola firewall di tipo ‘allow’ per tcp:NodePort dagli intervalli CIDR dei client autorizzati e dagli intervalli dell’health check di Google, e una regola di tipo ‘deny’ con priorità più alta per tutte le altre origini, con logging attivo per osservare i pacchetti scartati (drop).

Network policy e dataplane v2

• Abilitare le NetworkPolicy di Kubernetes e utilizzare GKE Dataplane V2 per l’enforcement basato su eBPF, migliorando le prestazioni e la fedeltà rispetto ai motori basati su iptables.
• Postura di base:
  • Negare (deny) di default il traffico in uscita (egress) e in entrata (ingress) per i namespace; consentire esplicitamente i flussi da Pod a Pod e da Pod a Service.
  • Utilizzare i selettori namespaceSelector e podSelector per creare livelli di servizio (tier) (frontend, backend, data) e consentire solo le direzioni e le porte strettamente necessarie.
• Comunicazione sicura tra i servizi:
  • Per un modello zero trust all’interno del cluster, l’mTLS è implementato al meglio da una service mesh; le NetworkPolicy gestiscono i livelli L3/L4 e non possono autenticare le identità.
  • Per il traffico north-south, collegare Cloud Armor ai LB HTTP(S) per WAF, rate limiting e modalità di anteprima (preview) per testare una regola di ‘deny’ su presunti aggressori senza interrompere il servizio agli utenti.

Modalità di fallimento e compromessi

• Un numero eccessivo o policy troppo ampie di NetworkPolicy possono causare scarti di pacchetti (drop) imprevisti; validare con rollout graduali (staged rollout), logging e strumenti di analisi delle policy.
• Affidarsi a NodePort più regole firewall esterne è una soluzione fragile; preferire i load balancer gestiti e i NEG di Pod.
• La Gateway API offre funzionalità più ricche ma richiede maturità del controller e familiarità da parte del team; validare funzionalità come il routing basato su header o il passthrough mTLS per ogni canale di rilascio (release channel).

Multi-cluster, service mesh e identità

Servizi multi-cluster e networking della flotta

• Registra i cluster in una flotta per utilizzare i Multi-Cluster Services (MCS) per il service discovery e il bilanciamento del carico tra cluster. Esporta i servizi da ogni cluster; i client risolvono un unico nome DNS supportato da endpoint distribuiti tra i cluster.
• Pattern di traffico tra cluster:
  • Stessa VPC, subnet diverse: il traffico scorre su indirizzi privati RFC1918 con costo e latenza ottimali.
  • VPC diverse: connettersi con VPC Peering per una connettività privata e semplice senza transitività, oppure usare Cloud VPN/Cloud Router se le organizzazioni sono diverse o è richiesta la crittografia su internet. Per un’amministrazione centralizzata, la Shared VPC espone solo le subnet necessarie ai progetti di servizio.
• Modalità di fallimento:
  • I CIDR sovrapposti bloccano il routing; assicurarsi che non ci siano sovrapposizioni tra PodCIDR e ServiceCIDR prima di configurare il peering o la VPN.
  • Problemi di DNS split-horizon possono interrompere la risoluzione tra cluster; validare i percorsi di ricerca (search path) e gli stub domain.

Service mesh, traffico east–west e osservabilità

• Implementa una service mesh come Anthos Service Mesh per:
  • mTLS con una forte identità del workload, policy di traffico (tentativi, timeout, rilevamento di outlier) e suddivisione del traffico (traffic splitting).
  • Policy east-west coerenti tra i cluster con federazione della mesh o topologie multi-primarie.
  • Telemetria ricca: golden signal per ogni workload, tracciamento delle richieste (request traces) e audit delle policy.
• Compromessi:
  • I sidecar aumentano l’overhead di risorse; le modalità ambient o sidecarless possono ridurre i costi, ma è necessario validare la parità delle funzionalità.
  • La mesh aggiunge dipendenze dal control plane; progetta per control plane in alta disponibilità (HA) e degradazione graduale (graceful degradation).

Identità del workload, secret e principio del privilegio minimo (least privilege)

• Usa Workload Identity per mappare i Kubernetes Service Account (KSA) ai Google service account (GSA), eliminando le chiavi a lunga durata. Aggiungi un’annotazione al KSA con l’email del GSA e assegna al GSA i ruoli IAM minimi indispensabili.
• Gestione dei secret:
  • Preferisci Secret Manager con il driver CSI per montare i secret a runtime; rimuovi i Secret di Kubernetes in chiaro per i dati sensibili o crittografali at-rest con CMEK se vengono mantenuti.
  • Assegna al GSA l’accesso a secret e bucket secondo il principio del privilegio minimo. Evita ruoli a livello di progetto; limita l’ambito a ruoli a livello di risorsa come storage.objectViewer quando applicabile.

Considerazioni sulla resilienza e sulla progettazione di una piattaforma sicura

• Cluster regionali per l’alta disponibilità; distribuisci i nodi tra le zone. Per il traffico north–south, usa il bilanciamento del carico HTTP(S) globale per la latenza più bassa verso gli utenti globali.
• Connettività del control plane: scegli control plane privati; evita l’esposizione pubblica a meno che non sia strettamente necessario, utilizzando le Authorized Networks.
• Egress: nodi senza IP esterni più Cloud NAT e PGA bilanciano sicurezza e funzionalità.
• Osservabilità: abilita il logging del firewall, i VPC Flow Logs e la telemetria della mesh per diagnosticare rapidamente i pacchetti scartati dalle policy (policy drops) o i picchi di latenza.

Scenario di un Problema Pratico

Contoso Retail gestisce due cluster GKE regionali privati in us-east1 e europe-west1. Requisiti: nessun IP esterno sui nodi, ingress sicuro limitato ai CIDR aziendali, disponibilità globale per un servizio di storefront, pull delle immagini senza esposizione a internet e failover tra cluster per il livello API. In passato hanno riscontrato l’esaurimento degli IP dei Pod durante un picco di traffico.

Approccio

1. Progetta subnet VPC-native con intervalli secondari generosi.

   • Motivazione: Alloca un intervallo /17 per i Pod e un intervallo /21 per i Servizi per regione per coprire 100 nodi × 200 Pod/nodo e 1.500 servizi con un margine del 20–30%. Questo previene il ripetersi dell’esaurimento degli IP dei Pod ed evita la necessità di riassegnare gli IP (re-IP) durante la crescita.

2. Crea cluster privati con endpoint del control plane privati.

   • Motivazione: Limita l’esposizione del control plane alla VPC. Gli operatori si connettono tramite una bastion host su una subnet di gestione. Questo riduce la superficie di attacco rispetto agli endpoint pubblici con Authorized Networks.

3. Abilita Cloud NAT e Private Google Access sulle subnet dei nodi.

   • Motivazione: I nodi non hanno IP esterni ma devono comunque effettuare il pull delle immagini da Artifact Registry e raggiungere i mirror del sistema operativo/pacchetti. PGA garantisce l’accesso alle API di Google senza IP di origine pubblici; Cloud NAT gestisce il traffico in uscita (egress) non diretto a Google, secondo necessità.

4. Implementa un ingress HTTP(S) globale utilizzando la Gateway API con Pod NEG.

   • Motivazione: Un singolo VIP anycast globale riduce la latenza per gli utenti in tutto il mondo. I Pod NEG di GKE inviano gli health check direttamente ai Pod e migliorano il rilevamento dei fallimenti. La Gateway API fornisce una netta separazione tra i Gateway dell’infrastruttura e le Route gestite dalle applicazioni.

5. Limita l’accesso dei client e permetti gli health check.

   • Motivazione: Collega una policy di Cloud Armor per consentire solo i CIDR aziendali, con un ‘default deny’ e una modalità di anteprima (preview) per valutare in sicurezza nuovi blocchi. Inoltre, assicurati che le regole del firewall VPC permettano gli intervalli di origine degli health check di Google verso i NEG di backend, in modo che gli health check rimangano positivi (green).

6. Applica le NetworkPolicy con GKE Dataplane V2.

   • Motivazione: Nega di default il traffico in entrata (ingress) e in uscita (egress) per ogni namespace; consenti solo le porte da frontend a backend e da backend a database. Dataplane V2 applica le policy in modo efficiente con eBPF, riducendo il raggio d’azione (blast radius) in caso di compromissione di un Pod.

7. Abilita i Multi-Cluster Services su tutta la flotta.

   • Motivazione: Esporta il servizio API in entrambe le regioni e pubblica un unico DNS. I client eseguono automaticamente il failover verso gli endpoint sani tra i cluster. Poiché entrambi i cluster si trovano nella stessa VPC con subnet regionali, il traffico tra regioni rimane privato e comporta un overhead minimo.

8. Adotta una service mesh per la sicurezza e l’osservabilità del traffico east-west.

   • Motivazione: Applica mTLS tra i servizi, aggiungi budget per tentativi/timeout e ottieni metriche e trace per ogni rotta. Le policy a livello di mesh completano le NetworkPolicy: le NetworkPolicy controllano la raggiungibilità a livello L3/L4; la mesh autentica e autorizza le identità dei servizi a livello L7.

9. Rafforza le identità dei workload e la gestione dei secret.

   • Motivazione: Mappa i KSA a GSA con ambito ristretto tramite Workload Identity; assegna solo i ruoli necessari, come storage.objectViewer per i report fetcher. Fornisci le credenziali tramite il CSI di Secret Manager per evitare secret statici nei manifest.

10. Implementa meccanismi di controllo (guardrail) per la capacità e il logging.

    • Motivazione: Imposta max-pods-per-node in modo ponderato per bilanciare l’uso degli IP. Monitora l’utilizzo degli intervalli secondari e i VPC Flow Logs. Crea una regola firewall esplicita ‘deny-all’ ad alta priorità con logging sul tag dell’applicazione per far emergere il traffico client imprevisto, preservando al contempo i percorsi consentiti.

Questo progetto si traduce in cluster privati per impostazione predefinita con accesso north-south controllato, failover multi-cluster resiliente, identità basata sul principio del privilegio minimo e un dataplane che scala senza il ricorrente esaurimento degli IP.

← Instradamento · Tutti i domini · Osservabilità della rete →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Google →