Compute Engine: istanze, persistent disk e immagini

Per sospendere temporaneamente la spesa di calcolo usi gcloud compute instances stop e gcloud compute instances start: attenzione, a VM ferma continui comunque a pagare i persistent disk e gli IP statici riservati. Il resize del tipo di macchina richiede l’istanza spenta e si fa con gcloud compute instances set-machine-type, che cambia CPU e memoria senza ricreare la VM.

I persistent disk si ridimensionano a caldo con gcloud compute disks resize --size: puoi solo crescere, mai ridurre, e dopo devi estendere il filesystem dentro l’OS. Per il backup usi gli snapshot (gcloud compute snapshots create, oppure uno snapshot schedule via resource policy): sono incrementali, sono una risorsa globale e sono ripristinabili in qualsiasi zone o region. Da uno snapshot o da un disk crei una custom image (gcloud compute images create) da riusare come base per nuove istanze o instance template.

Managed instance group: autoscaling e rolling update

Un MIG parte da un instance template (immutabile) e aggiunge due proprietà chiave: autoscaling e self-healing. L’autoscaling si configura con gcloud compute instance-groups managed set-autoscaling su metriche come --target-cpu-utilization, load balancing utilization o metriche custom di Cloud Monitoring, entro --min-num-replicas/--max-num-replicas e con un --cool-down-period per assorbire i picchi transitori.

Il self-healing (autohealing) ricrea le VM che falliscono un application health check: è un health check distinto da quello del load balancer, e richiede un --initial-delay sufficiente al boot dell’app, altrimenti scatta il kill a catena. Per aggiornare la flotta cambi il template e lanci un rolling update: gcloud compute instance-groups managed rolling-action start-update con --max-surge (VM extra da creare) e --max-unavailable (VM da togliere). Surge alto significa deploy rapido ma più costo; unavailable a zero significa nessun calo di capacità. Per un canary imposti due version nel MIG con percentuali di target size.

GKE: scaling, node pool e upgrade

Su GKE distingui due livelli. Il numero di Pod si governa con kubectl scale deployment o, in automatico, con un HorizontalPodAutoscaler su CPU o metriche. Il numero di nodi si governa con gcloud container clusters resize oppure col cluster autoscaler (--enable-autoscaling --min-nodes --max-nodes), configurato per node pool.

Usi più node pool quando ti servono hardware o label diversi (per esempio un pool con GPU). In Autopilot non gestisci affatto i nodi: paghi per Pod e Google dimensiona l’infrastruttura. Gli upgrade seguono i release channel; aggiorni prima il control plane con gcloud container clusters upgrade e poi i node pool, che vengono sostituiti in modo graduale (surge upgrade).

Database e diagnostica operativa

Cloud SQL offre backup automatici pianificati più backup on-demand (gcloud sql backups create). Il point-in-time recovery richiede backup automatici e PITR attivi e permette il ripristino a un istante preciso. Le read replica (gcloud sql instances create ... --master-instance-name) scalano le letture ma non danno alta disponibilità: per l’HA serve la configurazione regionale con failover automatico.

Per la diagnostica, Cloud Logging e Cloud Monitoring raccolgono log e metriche, ma le metriche di memoria e spazio disco delle VM richiedono l’Ops Agent installato. Se una VM non fa boot, leggi gcloud compute instances get-serial-port-output; per problemi ricorrenti configuri uptime check e alerting policy.

Trappole tipiche d’esame

  • Ridurre i costi di una VM spenta → soluzione: stop ferma la fatturazione della CPU, ma continui a pagare i persistent disk e gli IP statici riservati; per azzerare tutto devi eliminare le risorse.
  • Ridimensionare un persistent disk verso il basso → soluzione: impossibile, i disk crescono soltanto; dopo il resize devi estendere il filesystem nell’OS.
  • VM ricreate di continuo dal MIG → soluzione: --initial-delay dell’autohealing troppo basso, l’health check uccide la VM prima che l’app sia pronta.
  • Scalare le letture vs alta disponibilità del database → soluzione: read replica per il throughput di lettura, configurazione HA regionale con failover per la resilienza; non confonderli.
  • Deploy su MIG senza cali di capacità → soluzione: rolling update con --max-unavailable=0 e --max-surge positivo, così le nuove VM nascono prima di togliere le vecchie.
  • Metriche di memoria o disco assenti in Monitoring → soluzione: installa l’Ops Agent; le metriche di sistema di default coprono solo CPU, rete e I/O di base.