Google ACE: Containers, app-hosting en serverless platforms — Studiegids

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

Onderdeel van de Google Associate Cloud Engineer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Google Cloud biedt een spectrum aan platforms voor het draaien van containers en applicaties, van volledig beheerde serverless-oplossingen tot configureerbare Kubernetes-clusters. Het selecteren en beheren van het juiste platform vereist inzicht in control planes, schaalmodellen, releasemechanismen, netwerken en beveiliging. Dit gedeelte bundelt operationele richtlijnen voor Google Kubernetes Engine (GKE), Artifact Registry, Cloud Run, App Engine en Cloud Functions, naast patronen voor secrets, veilige rollouts en diagnostiek.

Kubernetes Engine: Clusters, Workloads en Netwerken

GKE-clusters bieden een beheerd Kubernetes-control plane met node pools die u zelf dimensioneert en beveiligt. Kies Autopilot voor minimale operationele overhead en voorgedefinieerde standaardinstellingen, of Standard voor granulaire controle over nodes, netwerken en add-ons. Gebruik release channels en automatische node-upgrades voor voorspelbare, veilige upgrades; schakel automatische node-reparatie in. Geef de voorkeur aan Container-Optimized OS voor versterkte (‘hardened’) nodes, tenzij specifieke pakketten Ubuntu vereisen.

• Node pools en scheduling

  • Scheid node pools per workload-klasse (bijv. algemeen, GPU, spot) en gebruik taints/tolerations om Pods te sturen.
  • Schakel de cluster autoscaler in en configureer min/max per pool. Houd er rekening mee dat PodDisruptionBudgets en resource requests een scale-in kunnen blokkeren of Pods in ‘pending’-status kunnen laten als de requests de beschikbare node-vormen overschrijden.
  • Spot/preemptible nodes verlagen de kosten maar introduceren een risico op ’eviction’; combineer ze met Deployment surge budgets en Pod-topologiebeperkingen voor veerkracht.

• Namespaces en multi-tenancy

  • Gebruik namespaces om quota’s, policies en RBAC te partitioneren. Pas NetworkPolicies toe om oost-west verkeer te beperken. Dwing Pod Security-standaarden af op namespace-niveau om geprivilegieerde workloads te vermijden.

• Workloads

  • Deployments beheren stateless Pods met rolling updates, surge/unavailable budgets en snelle rollbacks. Gebruik readiness probes om verkeer te reguleren en liveness/startup probes voor ‘autohealing’. Verkeerd geconfigureerde readiness probes kunnen verkeer ‘blackholen’; test dit vóór productie.
  • StatefulSets bieden stabiele identiteiten en geordende schaling voor databases en op quorum gebaseerde systemen. Gebruik een headless Service en een StorageClass die dynamische provisioning ondersteunt; houd rekening met de zonaliteit van PV’s.
  • DaemonSets plannen één Pod per node (bijv. voor logging/monitoring agents). Ze respecteren autoscaling en ‘drain’-events en zijn ideaal voor telemetrie over de hele node.

• Services en Ingress

  • ClusterIP stelt in-cluster DNS en load-balancing beschikbaar. NodePort is voornamelijk voor troubleshooting. LoadBalancer provisioneert een externe of interne Google Cloud TCP/UDP load balancer; gebruik de interne variant voor private services.
  • GKE Ingress configureert globale HTTP(S) load balancing met beheerde certificaten, URL maps en Cloud Armor. Voor modern verkeersbeheer, geef de voorkeur aan container-native load balancing (NEG) voor health checks per Pod en snellere convergentie. Zorg ervoor dat readiness endpoints de daadwerkelijke gezondheid van de app weerspiegelen; anders wordt de backend ongezond, wat 502-fouten veroorzaakt.

• Autoscaling

  • Horizontal Pod Autoscaler schaalt replica’s op basis van metrics zoals CPU of custom metrics via Cloud Monitoring; zorg ervoor dat de Metrics Server gezond is. Vertical Pod Autoscaler kan de ‘requests’ juist dimensioneren; vermijd conflicten met HPA door VPA in ‘recommendation’-modus te gebruiken voor door HPA beheerde workloads, of gebruik de HPA+VPA compatibele modus voorzichtig.
  • De cluster autoscaler voegt nodes toe of verwijdert ze om Pods te kunnen plaatsen. Als Pods meer resources aanvragen dan enige node-vorm biedt, zullen ze nooit worden ingepland; stem requests/limits af op de vormen van de node pool.

Korte voorbeelden:

• Een mislukte release terugdraaien:
  • kubectl rollout undo deployment/web
• Snel een andere context inspecteren:
  • kubectl config use-context CONTEXT && kubectl config view

Artefactbeheer, Supply Chain Security en Veilige Releases

Artifact Registry host container-images per regio met ondersteuning voor VPC Service Controls. Gebruik aparte repo’s (of prefixes) voor omgevingen en dwing onveranderlijke (‘immutable’) tags af; deploy op basis van de digest om dubbelzinnigheid te voorkomen. Integreer Cloud Build of uw CI om te bouwen en te pushen met herkomstmetadata (‘provenance metadata’).

• Kwetsbaarhedenbeheer

  • Schakel Artifact Analysis in om images te scannen op CVE’s in het OS en de programmeertaal. Onderbreek builds of blokkeer promotie bij bevindingen met een hoge ernstgraad. Combineer dit met Binary Authorization om handtekeningen/attestaties (bijv. ‘vulnerability policy pass’, SLSA-provenance) te vereisen voordat toelating tot GKE wordt verleend.

• Image-promotie

  • Promoot door een image digest te kopiëren van dev- naar staging/prod-repo’s of door opnieuw te taggen in een promotie-repo; vermijd de veranderlijke ’latest’-tag. Automatiseer dit met Cloud Build-triggers die afhankelijk zijn van tests en scanresultaten.

• Secrets en configuratie

  • Geef de voorkeur aan Secret Manager met ’least-privileged’ toegang. Op GKE, gebruik de Secret Manager CSI-driver met Workload Identity zodat nodes nooit langlevende secrets te zien krijgen. Voor KRM-configuraties, scheid ConfigMap (niet-geheim) van Secret (gevoelig) en mount deze als read-only.
  • Voor serverless, mount secrets via directe Secret Manager-koppelingen; vermijd het insluiten van secrets in omgevingsvariabelen, tenzij strikt noodzakelijk.

• Rollback- en releasepatronen

  • Kubernetes: gebruik rolling updates met maxUnavailable=0 voor zero-downtime en maxSurge afgestemd op de capaciteit; voer een canary-release uit met twee Deployments achter één Service of gebruik een Service mesh voor geleidelijke percentages. Bescherm kritieke workloads met PodDisruptionBudgets en minReadySeconds.
  • Cloud Run en App Engine: gebruik revisies/versies en traffic splitting voor canary- en blue/green-deployments. Houd vorige revisies ‘warm’ om de latentie bij een rollback te verminderen.
  • Foutscenario’s: ‘drift’ van veranderlijke tags, hiaten in scantijden en verkeerd gespecificeerde readiness probes zijn veelvoorkomende oorzaken van storingen. Gebruik image digests, pre-deploy controles en synthetische health probes.

Serverless Applicatieplatformen

Cloud Run biedt container-native, request-gestuurde compute met automatisch naar nul schalen en identiteitshandhaving per request.

• Cloud Run services en jobs

  • Services verwerken HTTP; concurrency regelt het aantal gelijktijdige requests per instantie (afstemmen voor latency versus efficiëntie). Jobs verwerken non-HTTP batch/cron en kunnen geparallelliseerd worden.
  • Revisies zijn onveranderlijke snapshots. Traffic splitting maakt canary-implementaties per percentage mogelijk. Stel min instances in om cold starts te verminderen; gebruik CPU-toewijzing tijdens inactiviteit als achtergrondwerk nodig is.
  • Identiteit: wijs een dedicated service account per service/revisie toe met het ’least privilege’-principe. Beperk aanroepen via IAM (Cloud Run Invoker) of maak publiek indien nodig. Gebruik voor eindgebruikersauthenticatie ondertekende IAP-tokens of de ingebouwde authenticatie van Cloud Run met Identity Platform.

• Networking

  • Gebruik Serverless VPC-connectoren om private VPC-resources te bereiken. Kies egress: al het verkeer via de connector, of alleen private RFC1918-ranges. Houd rekening met de throughput-quota’s van de connector; schaal de grootte van de connector en lijn deze regionaal uit met de service. Combineer met Cloud NAT voor uitgaand internetverkeer met resources die alleen een privaat IP-adres hebben.
  • Private Service Connect kan producer-services privaat consumeren of interne endpoints beschikbaar stellen. Gebruik voor ingest via extern HTTP(S) Cloud Load Balancing met serverless NEG’s.

App Engine biedt twee omgevingen:

• Standard
  • In een sandbox, schaalt snel, ondersteunt automatische, basis- of handmatige schaling. Automatische schaling met min_idle_instances zorgt voor vooraf opgewarmde capaciteit. Snelle cold start en een eenvoudig implementatiemodel; beperkte aanpassingen op OS-niveau en een vaste set runtimes.
• Flexible
  • Draait Docker op Compute Engine VM’s met meer controle over systeembibliotheken en netwerken. Tragere levenscyclus van instanties en hogere basiskosten; geschikt wanneer aangepaste runtimes of native bibliotheken nodig zijn.
• Services en versies
  • Splits verkeer per versie (willekeurig, op cookie of op IP). Elke service kan onafhankelijk schalen. Gebruik geleidelijke rollouts en behoud een vorige versie voor een onmiddellijke rollback.

Cloud Functions levert event-driven functies voor één specifiek doel.

• Triggers: Pub/Sub, Cloud Storage, HTTP, Eventarc voor vele bronnen. Maak handlers idempotent; sommige triggers proberen het opnieuw bij een fout, wat leidt tot dubbele verwerking.
• Runtime-configuratie: omgevingsvariabelen, koppelingen met Secret Manager, max instances, geheugen/CPU. Beheer concurrency voor HTTP-functies om een balans te vinden tussen latency en kosten.
• Veelvoorkomende valkuilen: onbegrensde concurrency of niet-idempotente neveneffecten veroorzaken dataduplicatie; zorg voor DLQ’s voor Pub/Sub; stel gepaste timeouts in.

Platformselectie, Netwerken en Operationeel Eigenaarschap

Selecteer een platform op basis van de vereiste controle, schaalkenmerken, portabiliteitsbehoeften en operationeel budget.

• Controle versus overhead

  • Hoogste controle: GKE Standard (node OS, netwerken, security add-ons) met bijbehorende operationele overhead.
  • Gebalanceerd: GKE Autopilot (geen node-beheer, een uitgesproken mening over security).
  • Laagste overhead: Cloud Run, App Engine, Cloud Functions (geen nodes, beheerde schaling), maar beperkt door runtime- en request-modellen.

• Schalen en geschiktheid voor workloads

  • Workloads met pieken in verzoeken: Cloud Run/App Engine Standard excelleren hierin; Functions voor event-driven handlers.
  • Stateful of aangepaste netwerken: GKE met StatefulSets en CNI-functionaliteiten.
  • Portabiliteit: containers op GKE/Cloud Run; Functions zijn minder portabel vanwege het FaaS-model.

• Serverless netwerken, egress en private services

  • Gebruik VPC-connectoren voor private toegang; monitor het gebruik van de connector om throttling te voorkomen. Stel egress alleen in op “all” wanneer dit noodzakelijk is; beperk het anders tot private ranges om kosten en risico’s te verminderen.
  • Voor private ingress, overweeg interne HTTP(S) load balancing met serverless NEG’s of Private Service Connect.
  • Voor controle op data-exfiltratie, combineer met VPC Service Controls waar ondersteund en beperk egress-routes via firewall en Cloud NAT.

• Diagnostiek en operationeel eigenaarschap

  • Standaardiseer op Cloud Logging met gestructureerde logs (JSON) en trace/span-ID’s over services heen voor correlatie. Gebruik Cloud Monitoring-dashboards, uptime-controles, SLO’s en alerting-beleid.
  • Voor GKE: schakel Cloud Ops for GKE in, scrape app-metrics via Prometheus of Cloud Monitoring, en gebruik DaemonSets voor telemetrie op node-niveau.
  • Voor serverless: maak gebruik van ingebouwde request-logs, Error Reporting, Trace en Profiler. Stel SLO’s en alerts per service in op latency, foutenpercentage en verzadiging (concurrency, instance-CPU).
  • Eigenaarschapmodel: definieer wie eigenaar is van runtime-parameters (schaling, concurrency), IAM en release-pipelines. Test regelmatig rollbacks en noodscenario’s.

Praktijkscenario

Acme Retail is van plan een nieuwe checkout-API beschikbaar te stellen en tegelijkertijd interne services te moderniseren. De vereisten zijn: een publieke API met lage latency en canary-rollouts, private toegang tot een interne voorraaddatabase in een VPC, handhaving van de supply chain, en een duidelijke rollback met minimale operationele overhead.

1. Kies Cloud Run voor de publieke API en GKE Autopilot voor de interne inventory-service.

• Reden: Cloud Run minimaliseert de operationele overhead voor stateless HTTP, ondersteunt revisies en traffic splitting; GKE Autopilot biedt Kubernetes-functionaliteit voor stateful/interne services zonder node-beheer.

2. Images bouwen, scannen en opslaan in Artifact Registry met herkomstinformatie (provenance).

• Reden: Cloud Build produceert container-images; Artifact Analysis scant op CVE’s. Het opslaan van digests en herkomstinformatie stelt Binary Authorization in staat om af te dwingen dat alleen gescande, ondertekende images worden uitgevoerd.

3. Admission-beleid afdwingen.

• Reden: Schakel Binary Authorization in op het GKE-cluster om handtekeningen en beleidsattesten te vereisen. Configureer voor Cloud Run de deploy-automatisering om promotie te blokkeren tenzij het kwetsbaarheidsbeleid wordt goedgekeurd.

4. Netwerk configureren met een Serverless VPC-connector en Cloud NAT.

• Reden: De Cloud Run API moet de inventory-service en Cloud SQL privaat kunnen bereiken. Een VPC-connector maakt private RFC1918-egress mogelijk; Cloud NAT biedt uitgaand internet voor het downloaden van dependencies zonder externe IP’s op private resources. Houd de connector en services in dezelfde regio en dimensionneer de doorvoercapaciteit correct.

5. Identiteiten en permissies beveiligen.

• Reden: Wijs een toegewezen serviceaccount toe aan de Cloud Run-service met het principe van ’least privilege’ (bijv. Cloud SQL Client, invoke-permissies voor interne endpoints indien nodig). Gebruik voor GKE Workload Identity zodat Pods serviceaccounts kunnen aannemen zonder credentials op node-niveau.

6. Veilige release en rollback implementeren.

• Reden: Deploy de API naar een nieuwe Cloud Run-revisie en splits 5% van het verkeer af voor een canary. Monitor latency, foutenpercentage en verzadiging; schaal vervolgens op naar 100% of draai onmiddellijk terug door het verkeer terug te zetten naar de vorige revisie. Gebruik in GKE Deployment rolling updates met readiness probes en een kleine canary-Deployment achter dezelfde Service om te valideren vóór de volledige uitrol.

7. Observeerbaarheid en SLO’s configureren.

• Reden: Stoot gestructureerde JSON-logs met trace-ID’s uit van beide platforms naar Cloud Logging. Maak SLO’s aan op p95-latency en het 5xx-foutenpercentage; koppel hier alerting-beleid aan. Gebruik Error Reporting en Trace voor root cause analysis. Deploy voor GKE een DaemonSet voor node-metrics en schakel Cloud Ops for GKE in.

8. Faalmodi en capaciteit valideren.

• Reden: Voer een loadtest uit om de doorvoercapaciteit van de VPC-connector, de concurrency van Cloud Run en het gedrag van de GKE HPA te verifiëren. Bevestig de nauwkeurigheid van de readiness probe om blackholing te voorkomen. Test de ‘deny’-paden van Binary Authorization en image-rollback op basis van digest om herstelbaarheid te garanderen onder handhaving van de supply chain.

Deze aanpak levert een veilige, publieke API met lage operationele last, gecontroleerde interne services, private netwerken, afdwingbare supply chain-beveiliging en een snelle rollback, in lijn met de operationele best practices van Google Cloud.

← Compute Engine en virtuele-machineoperaties · Alle domeinen · VPC-netwerken →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →

Blader door Google →