Google ACE: Container, hosting di app e piattaforme serverless — Guida allo studio

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Panoramica

Google Cloud offre una gamma di piattaforme per l’esecuzione di container e applicazioni, da soluzioni serverless completamente gestite a cluster Kubernetes configurabili. La selezione e la gestione della piattaforma corretta richiedono la comprensione di piani di controllo, modelli di scalabilità, meccanismi di rilascio, networking e sicurezza. Questa sezione consolida le linee guida operative per Google Kubernetes Engine (GKE), Artifact Registry, Cloud Run, App Engine e Cloud Functions, insieme a pattern per la gestione dei segreti, i rilasci sicuri e la diagnostica.

Kubernetes Engine: Cluster, Workload e Networking

I cluster GKE forniscono un piano di controllo Kubernetes gestito con pool di nodi che puoi dimensionare e proteggere. Scegli la modalità Autopilot per un overhead operativo minimo e configurazioni predefinite ottimizzate, oppure la modalità Standard per un controllo granulare di nodi, networking e add-on. Utilizza i canali di rilascio e l’auto-upgrade dei nodi per aggiornamenti prevedibili e sicuri; abilita l’auto-riparazione dei nodi. Prediligi Container-Optimized OS per nodi con hardening di sicurezza, a meno che pacchetti specifici non richiedano Ubuntu.

• Pool di nodi e scheduling

  • Separa i pool di nodi per classe di workload (es. generico, GPU, spot) e usa taints/tolerations per indirizzare i Pod.
  • Abilita il cluster autoscaler e configura min/max per ogni pool. Tieni presente che i PodDisruptionBudget e le richieste di risorse possono bloccare lo scale-in o lasciare i Pod in stato pending se le richieste superano le configurazioni di nodi disponibili.
  • I nodi Spot/preemptible riducono i costi ma introducono il rischio di eviction (rimozione forzata); combinali con i budget di surge dei Deployment e i vincoli di topologia dei Pod per la resilienza.

• Namespace e multi-tenancy

  • Usa i namespace per partizionare quote, policy e RBAC. Applica NetworkPolicy per limitare il traffico est-ovest. Applica gli standard di Pod Security a livello di namespace per evitare workload con privilegi elevati.

• Workload

  • I Deployment gestiscono Pod stateless con aggiornamenti progressivi (rolling update), budget di surge/indisponibilità e rollback rapidi. Usa i readiness probe per controllare il traffico in ingresso e i liveness/startup probe per l’auto-riparazione. Readiness probe configurati in modo errato possono causare un blackhole del traffico; effettua test prima della produzione.
  • Gli StatefulSet forniscono identità stabili e scalabilità ordinata per database e sistemi basati su quorum. Usa un Service headless e una StorageClass che supporti il provisioning dinamico; pianifica la località zonale dei PV (Persistent Volume).
  • I DaemonSet pianificano un Pod per ogni nodo (es. agenti di logging/monitoring). Rispettano gli eventi di autoscaling e drain e sono ideali per la telemetria a livello di nodo.

• Service e Ingress

  • ClusterIP espone DNS e bilanciamento del carico interni al cluster. NodePort è usato principalmente per il troubleshooting. LoadBalancer esegue il provisioning di un bilanciatore del carico TCP/UDP esterno o interno di Google Cloud; usa quello interno per i servizi privati.
  • GKE Ingress configura il bilanciamento del carico HTTP(S) globale con certificati gestiti, mappe URL e Cloud Armor. Per una gestione moderna del traffico, prediligi il bilanciamento del carico container-native (NEG) per health check per singolo Pod e una convergenza più rapida. Assicurati che gli endpoint di readiness riflettano lo stato di salute reale dell’app; altrimenti il backend diventerà non integro, causando errori 502.

• Autoscaling

  • L’Horizontal Pod Autoscaler (HPA) scala le repliche in base a metriche come la CPU o metriche personalizzate tramite Cloud Monitoring; assicurati che il Metrics Server sia integro. Il Vertical Pod Autoscaler (VPA) può dimensionare correttamente le richieste; evita conflitti con l’HPA usando il VPA in modalità “recommendation” per i workload gestiti dall’HPA o usa con cautela la modalità compatibile HPA+VPA.
  • Il Cluster autoscaler aggiunge/rimuove nodi per adattarsi ai Pod. Se i Pod richiedono più risorse di quelle offerte da qualsiasi tipo di nodo, non verranno mai schedulati; allinea le richieste/limiti con le configurazioni dei pool di nodi.

Esempi rapidi:

• Eseguire il rollback di una release fallita:
  • kubectl rollout undo deployment/web
• Ispezionare rapidamente un altro contesto:
  • kubectl config use-context CONTEXT && kubectl config view

Gestione degli Artefatti, Sicurezza della Supply Chain e Rilasci Sicuri

Artifact Registry ospita immagini container per regione con supporto per VPC Service Controls. Adotta repository (o prefissi) separati per ogni ambiente e imponi l’uso di tag immutabili; esegui il deploy tramite digest per eliminare ambiguità. Integra Cloud Build o la tua CI per creare e inviare immagini con metadati di provenienza.

• Gestione delle vulnerabilità

  • Abilita Artifact Analysis per scansionare le immagini alla ricerca di CVE del sistema operativo e dei linguaggi. Interrompi le build o blocca la promozione in caso di vulnerabilità ad alta gravità. Combina questa funzionalità con Binary Authorization per richiedere firme/attestazioni (es. superamento della policy di vulnerabilità, provenienza SLSA) prima dell’ammissione in GKE.

• Promozione delle immagini

  • Promuovi un’immagine copiando il suo digest dai repository di dev a quelli di staging/prod o riassegnando il tag in un repository di promozione; evita il tag mutabile “latest”. Automatizza il processo con i trigger di Cloud Build condizionati dai risultati dei test e delle scansioni.

• Segreti e configurazione

  • Prediligi Secret Manager con accesso con privilegi minimi (least-privileged). Su GKE, usa il driver CSI di Secret Manager con Workload Identity in modo che i nodi non vedano mai segreti a lunga durata. Per le configurazioni KRM, separa i ConfigMap (non segreti) dai Secret (sensibili) e montali in modalità di sola lettura.
  • Per le piattaforme serverless, monta i segreti tramite binding diretti di Secret Manager; evita di incorporare segreti nelle variabili d’ambiente a meno che non sia strettamente necessario.

• Pattern di rollback e rilascio

  • Kubernetes: usa rolling update con maxUnavailable=0 per non avere downtime e maxSurge ottimizzato per la capacità; implementa un canary con due Deployment dietro un unico Service o usa una Service mesh per percentuali graduali. Proteggi i workload critici con i PodDisruptionBudget e minReadySeconds.
  • Cloud Run e App Engine: usa revisioni/versioni e la suddivisione del traffico (traffic splitting) per implementare strategie canary e blue/green. Mantieni “calde” le revisioni precedenti per ridurre la latenza di rollback.
  • Modalità di fallimento: il disallineamento dei tag mutabili (tag drift), gli intervalli temporali nella scansione e i readiness probe specificati in modo errato sono cause comuni di interruzioni. Usa i digest delle immagini, controlli pre-deploy e probe di salute sintetici.

Piattaforme di applicazioni serverless

Cloud Run fornisce un ambiente di calcolo container-native, basato su richieste, con scalabilità automatica fino a zero e applicazione dell’identità per singola richiesta.

• Servizi e job di Cloud Run

  • I servizi gestiscono l’HTTP; la concorrenza controlla il numero di richieste simultanee per istanza (da regolare per bilanciare latenza ed efficienza). I job gestiscono processi batch/cron non HTTP e possono essere parallelizzati.
  • Le revisioni sono snapshot immutabili. La suddivisione del traffico (traffic splitting) abilita il canary per percentuale. Impostare un numero minimo di istanze (min instances) per ridurre i cold start; utilizzare l’allocazione della CPU durante i periodi di inattività (idle) se è richiesto lavoro in background.
  • Identità: assegnare un service account dedicato per ogni servizio/revisione con il principio del privilegio minimo (least privilege). Limitare l’invocazione tramite IAM (ruolo Cloud Run Invoker) o renderla pubblica se necessario. Per l’autenticazione degli utenti finali, utilizzare token IAP firmati o l’autenticazione integrata di Cloud Run con Identity Platform.

• Networking

  • Utilizzare i connettori VPC serverless per raggiungere risorse VPC private. Scegliere l’egress: tutto il traffico attraverso il connettore, o solo gli intervalli privati RFC1918. Tenere conto delle quote di throughput del connettore; dimensionare la dimensione del connettore e allinearlo a livello di regione con il servizio. Per il traffico in uscita verso internet con risorse che hanno solo IP privati, combinare con Cloud NAT.
  • Private Service Connect può consumare privatamente servizi producer o esporre endpoint interni. Per l’ingest tramite HTTP(S) esterno, utilizzare Cloud Load Balancing con NEG serverless.

App Engine offre due ambienti:

• Standard
  • In sandbox, scala rapidamente, supporta la scalabilità automatica, di base o manuale. La scalabilità automatica con min_idle_instances fornisce capacità pre-riscaldata (pre-warmed). Cold start rapidi e modello di deployment semplice; personalizzazioni a livello di sistema operativo limitate e un set di runtime fisso.
• Flessibile
  • Esegue Docker su VM di Compute Engine con maggiore controllo su librerie di sistema e networking. Ciclo di vita dell’istanza più lento e costo di base più elevato; adatto quando sono necessari runtime personalizzati o librerie native.
• Servizi e versioni
  • Suddividere il traffico per versione (casuale, tramite cookie o IP). Ogni servizio può scalare in modo indipendente. Utilizzare rollout graduali e mantenere una versione precedente per un rollback istantaneo.

Cloud Functions fornisce funzioni single-purpose basate su eventi.

• Trigger: Pub/Sub, Cloud Storage, HTTP, Eventarc per molteplici sorgenti. Rendere gli handler idempotenti; alcuni trigger eseguono tentativi in caso di fallimento, portando a elaborazioni duplicate.
• Configurazione del runtime: variabili d’ambiente, collegamenti a Secret Manager, numero massimo di istanze (max instances), memoria/CPU. Controllare la concorrenza per le funzioni HTTP per bilanciare latenza e costi.
• Errori comuni: concorrenza illimitata o effetti collaterali non idempotenti causano la duplicazione dei dati; assicurare la presenza di DLQ per Pub/Sub; impostare timeout appropriati.

Selezione della piattaforma, networking e responsabilità operativa

Seleziona una piattaforma in base al controllo richiesto, alle caratteristiche di scalabilità, alle esigenze di portabilità e al budget operativo.

• Controllo vs overhead

  • Massimo controllo: GKE Standard (sistema operativo dei nodi, networking, add-on di sicurezza) con il corrispondente overhead operativo.
  • Bilanciato: GKE Autopilot (nessuna gestione dei nodi, sicurezza preconfigurata).
  • Minimo overhead: Cloud Run, App Engine, Cloud Functions (nessun nodo, scalabilità gestita), ma vincolati dai modelli di runtime e di richiesta.

• Scalabilità e idoneità del carico di lavoro

  • Carichi di lavoro con picchi di richieste: Cloud Run/App Engine Standard eccellono; Functions per gestori basati su eventi.
  • Networking stateful o personalizzato: GKE con StatefulSets e funzionalità CNI.
  • Portabilità: container su GKE/Cloud Run; le Functions sono meno portabili a causa del modello FaaS.

• Networking serverless, traffico in uscita (egress) e servizi privati

  • Utilizza i connettori VPC per l’accesso privato; monitora l’utilizzo del connettore per evitare il throttling. Imposta l’egress su “all” solo quando necessario; altrimenti, limitalo agli intervalli privati per ridurre costi e rischi.
  • Per il traffico in entrata (ingress) privato, considera il bilanciamento del carico HTTP(S) interno con NEG serverless o Private Service Connect.
  • Per il controllo dell’esfiltrazione dei dati, abbina i VPC Service Controls dove supportati e limita le route di egress tramite firewall e Cloud NAT.

• Diagnostica e responsabilità operativa

  • Standardizza l’uso di Cloud Logging con log strutturati (JSON) e ID di traccia/span tra i servizi per la correlazione. Utilizza le dashboard di Cloud Monitoring, i controlli di uptime, gli SLO e le policy di avviso.
  • Per GKE: abilita Cloud Ops for GKE, raccogli le metriche delle applicazioni tramite Prometheus o Cloud Monitoring e utilizza i DaemonSets per la telemetria a livello di nodo.
  • Per il serverless: sfrutta i log delle richieste integrati, Error Reporting, Trace e Profiler. Imposta SLO per servizio e avvisi su latenza, tasso di errore e saturazione (concorrenza, CPU dell’istanza).
  • Modello di responsabilità: definisci chi è responsabile dei parametri di runtime (scalabilità, concorrenza), di IAM e delle pipeline di rilascio. Testa regolarmente i rollback e gli scenari di disastro.

Scenario pratico

Acme Retail prevede di esporre una nuova API di checkout modernizzando al contempo i servizi interni. Requisiti: API pubblica a bassa latenza con implementazioni canary, accesso privato a un database di inventario interno in un VPC, applicazione delle policy sulla supply chain e rollback chiaro con un overhead operativo minimo.

1. Scegliere Cloud Run per l’API pubblica e GKE Autopilot per il servizio di inventario interno.

• Motivazione: Cloud Run minimizza l’overhead operativo per l’HTTP stateless, supporta revisioni e suddivisione del traffico; GKE Autopilot fornisce le funzionalità di Kubernetes per servizi stateful/interni senza la gestione dei nodi.

2. Creare, scansionare e archiviare le immagini in Artifact Registry con dati di provenienza.

• Motivazione: Cloud Build produce le immagini dei container; Artifact Analysis le scansiona alla ricerca di CVE. L’archiviazione dei digest e dei dati di provenienza consente a Binary Authorization di imporre l’esecuzione solo di immagini scansionate e firmate.

3. Applicare le policy di ammissione.

• Motivazione: Abilitare Binary Authorization sul cluster GKE per richiedere firme e attestazioni di policy. Per Cloud Run, configurare l’automazione del deploy per bloccare la promozione se la policy sulle vulnerabilità non viene superata.

4. Configurare il networking con un connettore VPC Serverless e Cloud NAT.

• Motivazione: L’API di Cloud Run deve raggiungere privatamente il servizio di inventario e Cloud SQL. Un connettore VPC consente il traffico in uscita (egress) privato secondo RFC1918; Cloud NAT fornisce l’accesso a Internet in uscita per il download delle dipendenze senza IP esterni sulle risorse private. Mantenere il connettore e i servizi nella stessa regione e dimensionare correttamente il suo throughput.

5. Proteggere identità e autorizzazioni.

• Motivazione: Assegnare un account di servizio dedicato al servizio Cloud Run con il principio del privilegio minimo (es. Cloud SQL Client, autorizzazioni di richiamo per endpoint interni se necessario). Per GKE, utilizzare Workload Identity in modo che i Pod possano assumere l’identità degli account di servizio senza credenziali a livello di nodo.

6. Implementare un rilascio e un rollback sicuri.

• Motivazione: Eseguire il deploy dell’API in una nuova revisione di Cloud Run e suddividere il 5% del traffico per il canary. Monitorare latenza, tasso di errore e saturazione; quindi aumentare fino al 100% o eseguire un rollback istantaneo ripristinando il traffico sulla revisione precedente. In GKE, utilizzare aggiornamenti continui (rolling update) del Deployment con readiness probe e un piccolo Deployment canary dietro lo stesso Service per la convalida prima del rollout completo.

7. Configurare l’osservabilità e gli SLO.

• Motivazione: Emettere log JSON strutturati con ID di traccia da entrambe le piattaforme verso Cloud Logging. Creare SLO sulla latenza p95 e sul tasso di errori 5xx; associare policy di avviso. Utilizzare Error Reporting e Trace per l’analisi delle cause principali (root cause analysis). Per GKE, distribuire un DaemonSet per le metriche dei nodi e abilitare Cloud Ops for GKE.

8. Convalidare le modalità di errore e la capacità.

• Motivazione: Eseguire test di carico per verificare il throughput del connettore VPC, la concorrenza di Cloud Run e il comportamento dell’HPA di GKE. Confermare l’accuratezza dei readiness probe per prevenire il blackholing. Testare i percorsi di negazione di Binary Authorization e il rollback dell’immagine tramite digest per garantire la recuperabilità in caso di applicazione delle policy sulla supply chain.

Questo approccio offre un’API pubblica sicura a basso impatto operativo, servizi interni controllati, networking privato, sicurezza della supply chain applicabile e rollback rapido, in linea con le best practice operative di Google Cloud.

← Compute Engine e operazioni sulle macchine virtuali · Tutti i domini · Networking VPC →

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

Sfoglia Google →