Routing statico e dinamico

In una VPC ogni subnet genera automaticamente subnet route, che hanno la precedenza per i propri range e non sono sovrascrivibili. Il resto del routing si divide fra static route e dynamic route. Le static route hanno una priorità (valore più basso = preferita) e possono essere ristrette con un network tag, così valgono solo per le VM taggate: utile per instradare selettivamente il traffico di alcune istanze verso un’appliance senza toccare le altre.

Il routing dinamico è gestito da Cloud Router, che stabilisce sessioni BGP con i peer on-prem via HA VPN o Cloud Interconnect e annuncia/apprende prefissi. La scelta chiave è la dynamic routing mode della VPC: regional applica le route apprese solo alla region del Cloud Router; global le propaga a tutte le region (e annuncia ai peer le subnet di tutte le region). Global è la scelta tipica per topologie multi-region con on-prem unico, al costo di percorsi potenzialmente subottimali; regional mantiene il traffico locale ma richiede un Cloud Router per region per la raggiungibilità completa.

ILB come next hop e policy-based routing

Un internal passthrough Network Load Balancer può essere impostato come next hop di una static route: il traffico verso un prefisso viene consegnato al load balancer, che lo distribuisce su un backend di firewall/NVA garantendo HA (se un’appliance cade, l’ILB reindirizza). È il pattern standard per inserire firewall di terze parti nel data path; la route supporta anche i network tag. Il passthrough preserva l’IP client e non termina TLS.

Quando la sola destination-based route non basta, le policy-based route (PBR) forzano l’instradamento in base a protocollo, source e destination range, valutate prima delle route normali: per esempio spingere solo il traffico HTTP di certe subnet verso l’ILB dell’appliance, lasciando passare il resto.

Peering, import/export e Network Connectivity Center

Il VPC Network Peering scambia di default solo le subnet route ed è non transitivo: se A ↔ B e B ↔ C, A non raggiunge C. Le route custom (static e dynamic) non passano se non abiliti esplicitamente export custom routes su un lato e import custom routes sull’altro — tipico per propagare al peer la route on-prem appresa via Cloud Router.

Per superare i limiti del peering c’è Network Connectivity Center: un modello hub-and-spoke dove il hub collega VPC spoke, hybrid spoke (HA VPN, VLAN attachment, Router appliance) e producer spoke (managed services). I VPC spoke offrono la transitività che il peering non dà; la topologia mesh permette comunicazione fra tutti gli spoke, mentre la star isola gli spoke edge lasciandoli parlare solo con il gruppo center. NCC abilita anche il site-to-site data transfer fra sedi on-prem passando per il backbone Google.

Networking GKE

I cluster GKE moderni sono VPC-native: usano alias IP con due secondary range della subnet, uno per il Pod range e uno per il Service range. Vanno dimensionati in anticipo perché condizionano il numero massimo di Pod, Service e node. In un private cluster i node hanno solo IP interni (egress via Cloud NAT); il control plane vive in una VPC gestita da Google collegata via peering ed espone un private endpoint. Con private control plane disabiliti l’endpoint pubblico, e le authorized networks restringono i CIDR ammessi a raggiungere l’API server. Dataplane V2 (basato su eBPF) fornisce enforcement nativo delle network policy Pod-to-Pod e observability, senza add-on Calico separato.

Trappole tipiche d’esame

  • Full mesh fra tre o più VPC → NCC, non peering: il VPC Peering è non transitivo; per la transitività usa Network Connectivity Center con VPC spoke.
  • Route on-prem non visibile in altre region → global dynamic routing mode: in regional le route BGP restano confinate alla region del Cloud Router.
  • Firewall inline con alta disponibilità → ILB come next hop: puntare la route a una singola VM crea un single point of failure; usa l’internal passthrough NLB davanti ai backend NVA.
  • Route custom non propagata sul peering → abilita import/export custom routes: di default passano solo le subnet route, non le static/dynamic apprese.
  • Control plane GKE esposto → private endpoint + authorized networks: disabilita l’endpoint pubblico e limita i CIDR; non basta il private cluster sui node.
  • Pod IP esauriti o cluster non scalabile → dimensiona i secondary range VPC-native: Pod range e Service range vanno pianificati prima, non si allargano facilmente dopo.