Google Kubernetes Engine (GKE)

Il problema che risolve

Kubernetes è composto da due componenti: il control plane, cioè l'API server, lo scheduler, i controller e il database etcd che conserva lo stato del cluster, e i nodi, le macchine su cui girano i container. La gestione di un cluster in alta affidabilità è un progetto complesso: vanno considerati ridondanza, backup, certificati e aggiornamenti di versione. Kubernetes è nato in Google, dall'esperienza interna con Borg, e GKE è stato il primo servizio gestito a offrirlo, nel 2015. GKE esegue il control plane per conto vostro, lo replica, lo aggiorna e lo copre con uno SLA; con la modalità Autopilot gestisce anche i nodi.

Responsabilità condivise

In Autopilot il nodo viene gestito in automatico: si paga per i vCPU, la memoria e lo storage effimero che i pod richiedono, al secondo, e Google si fa carico di impacchettarli su macchine effimere. Un pod che non dichiara richieste riceve per default 0,5 vCPU e 2 GiB di RAM, e le richieste sotto i minimi consentiti vengono alzate in automatico. I carichi che richiedono hardware specifico, GPU, TPU o una famiglia di macchine, seguono invece la fatturazione per nodo, con un sovrapprezzo di gestione.

Standard resta per i casi che Autopilot non copre: nodi Windows, agenti che richiedono privilegi di sistema, kernel personalizzato, o quando si vuole un controllo più preciso sul ciclo di vita dei nodi, visto che Autopilot tende a consolidare i nodi in maniera aggressiva, causando parecchie eviction dei pod se non si prendono precauzioni. Dal settembre 2025 le due modalità non sono più alternative secche: un cluster Standard può eseguire carichi in modalità Autopilot scegliendo una compute class apposita, e il confine si sposta pod per pod.

Come funziona

I cluster sono VPC-native: pod e Service ricevono indirizzi da intervalli secondari della subnet, e gli intervalli vanno preferibilmente progettati in partenza. Per esporre i servizi, GKE ha un proprio controller che supporta la Gateway API e crea i load balancer di Google Cloud.

Il cluster accetta direttamente le identità IAM di Google Cloud. Chi amministra entra con il proprio account, e i pod che devono chiamare le API di Google usano Workload Identity Federation, che lega un service account Kubernetes a un'identità IAM. L'accesso all'API server può essere limitato alla rete privata, e dal 2025 esiste un endpoint DNS per cluster protetto da IAM, che evita bastion e VPN.

I cluster Standard possono essere zonali, con un solo control plane, o regionali, con il control plane replicato su più zone. Lo SLA è 99,5% per i primi e 99,95% per i secondi, e durante un aggiornamento il control plane zonale è irraggiungibile. Autopilot è sempre regionale.

Aggiornamenti di versione

Qui GKE si distingue dagli altri. Il control plane si aggiorna da solo, sempre. I nodi si aggiornano da soli in Autopilot e per default in Standard. Il ritmo lo decide il canale di rilascio: Rapid segue Kubernetes a una o due settimane, Regular, il canale di default, a circa due mesi, Stable tre o quattro mesi dopo Regular. Il canale Extended permette di restare su una versione fino a 24 mesi, ma oltre i 14 mesi di supporto standard il canone per il control plane aumenta.

Il controllo che resta al cliente è sul quando: finestre di manutenzione, ed esclusioni che sospendono gli aggiornamenti. L'esclusione totale dura al massimo 90 giorni; quella che blocca solo i salti di minor version può durare di più.

Google Cloud in Italia

Google Cloud ha due region in Italia: Milano, europe-west8, e Torino, europe-west12. GKE c'è in entrambe. Vale la stessa avvertenza di tutte le region piccole: GPU e famiglie di macchine recenti arrivano prima altrove, e conviene controllare la disponibilità prima di adottare una regione.

Da dove si comincia

Nei progetti su GKE seguo di solito questi passi:

1. Progetto e rete prima del cluster. Organizzazione dei progetti Google Cloud, progettazione della rete con VPC dimensionate opportunamente, accesso privato al control plane.
2. Tutto in Terraform (o in un'altra tecnologia di Infrastructure as Code), cluster e node pool compresi.
3. Gateway API al posto di Ingress per i cluster nuovi.
4. Rilasci in GitOps e observability dal primo giorno.
5. Finestre di manutenzione decise insieme a chi gestisce il sistema, così che gli aggiornamenti automatici non siano inaspettati.

Maturità

Lavoro su Google Cloud e su GKE da anni. Il servizio è stabile e maturo. Se state valutando Kubernetes su Google Cloud, o volete rivedere un cluster che avete già, le pagine sulla consulenza Kubernetes e sulla consulenza cloud spiegano come lavoro.