Google PCD: Compute, Containers en Serverless runtime-platformen — Studiegids

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Overzicht

Google Cloud biedt meerdere runtime-platformen, variërend van serverless, containers tot virtuele machines. De keuze voor het juiste platform hangt af van de kenmerken van de workload, zoals verzoekpatronen, statusbeheer, build- en release-discipline, operationeel model en netwerkbeperkingen. Dit gedeelte behandelt ontwerpprincipes, faalmodi en afwegingen voor Cloud Run, App Engine, Cloud Functions, Google Kubernetes Engine (GKE) en Compute Engine, samen met ondersteunende services voor images, identiteit, netwerken, configuratie en operations.

Serverless Runtimes: Cloud Run, App Engine, Cloud Functions

Cloud Run

Model: Volledig beheerde containers met HTTP-verzoekafhandeling of gecontaineriseerde Jobs die tot voltooiing worden uitgevoerd.
Revisies en verkeer: Elke implementatie creëert een onveranderlijke (immutable) revisie. Het verdelen van verkeer op basis van percentages over revisies maakt canary- en blue-green-patronen mogelijk met onmiddellijke rollback. Voorbeeld:

  gcloud run services update-traffic my-svc --to-revisions rev-green=90,rev-blue=10

Concurrency en schaling: Standaard concurrency is 80; stel deze in op 1 voor CPU-gebonden of niet-thread-safe code. Hogere concurrency vermindert de versterking van cold-starts en de kosten, maar kan de tail latency verhogen als de CPU/het geheugen per verzoek onvoldoende is. Cloud Run schaalt naar nul en op basis van de inkomende verzoeksnelheid; beheer dit met min/max-instanties om cold-starts te verminderen en kosten te beperken.
CPU-toewijzing: Kies ‘CPU always allocated’ voor achtergrondwerk tussen verzoeken, tegen extra factureringskosten; anders wordt de CPU alleen toegewezen tijdens het afhandelen van verzoeken.
Jobs: Cloud Run Jobs voeren N parallelle taken uit tot voltooiing, met maximale nieuwe pogingen (retries) per taak en algemene timeouts; geschikt voor ETL-, batch- en fan-out-verwerking. Faalmodi omvatten hot-spotting van backends wanneer veel taken dezelfde afhankelijkheid targeten; voeg rate limiting en retries met backoff toe.
Netwerken: Openbaar, geauthenticeerd via IAM, of privé achter een VPC via Serverless VPC Access en Private Service Connect.

App Engine

Omgevingen:
- Standard: Gesandboxed, snelle schaalvergroting, vaste runtimes per taal; lage cold-start-latentie met automatische schaling; beperkt bestandssysteem, time-outs voor verzoeken en limieten voor de grootte van inkomende verzoeken. Gebruik Cloud Storage signed URL’s voor grote uploads.
- Flexible: Gebaseerd op Docker, VM-achtige mogelijkheden, aangepaste runtimes, langzamere opschaling dan Standard, ondersteunt achtergrondthreads en schrijven naar de lokale schijf.
Services en versies: Een service (microservice) kan meerdere versies hosten; routeer verkeer op basis van percentages over versies, vergelijkbaar met Cloud Run. Gebruik dispatch.yaml om specifieke paden of hosts naar services te routeren voor eenvoudige, gecentraliseerde routering zonder een externe load balancer.
Schaling: Handmatig, basis of automatisch in Standard; schaling op basis van het aantal VM’s in Flexible. Afweging: agressieve autoscaling verbetert de responsiviteit, maar kan de kosten en de contentie op de backend verhogen.
Veelvoorkomende valkuilen: Onbegrensde schaalvergroting van instanties zonder quota’s kan downstream-systemen overweldigen; dwing quota’s en circuit breakers af.

Cloud Functions

Event-driven handlers: Getriggerd door HTTP-, Pub/Sub-, Cloud Storage- of Eventarc-events. Gebruik 2nd gen om het uitvoeringsmodel van Cloud Run, VPC egress control en concurrency te benutten; 1st gen verwerkt één verzoek tegelijk.
Retries en idempotent: Achtergrondfuncties kunnen opnieuw worden geprobeerd bij een fout; ontwerp idempotente handlers en gebruik ontdubbelingssleutels om dubbele verwerking te voorkomen. HTTP-triggers worden niet opnieuw geprobeerd door het platform; implementeer client-side retries met exponential backoff.
Runtime-configuratie: Omgevingsvariabelen, Secret Manager-integratie en concurrency/max-instanties per functie. Stel timeouts in om uit de hand lopende kosten te beperken. Pas op voor lange cold-starts met grote afhankelijkheden; houd packages slank.

Containers op Google Kubernetes Engine

Workloads

Deployments: Stateless pods met rolling updates. Zorg voor veilige rollouts met surge/unavailable-limieten:

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

StatefulSets: Geordende, stabiele netwerk-ID’s en persistente volumes voor stateful services.
DaemonSets, Jobs, CronJobs: Agents op node-niveau en batch-workloads.

Services en Ingress

Service types:
- ClusterIP voor alleen intern gebruik.
- NodePort voor eenvoudige externe toegang (operationeel beperkt).
- LoadBalancer voor regionale externe/interne load balancing.
Ingress: HTTP(S)-routering en TLS-terminatie; geef de voorkeur aan Gateway API of Ingress met beheerde controllers voor L7-beleid. Faalmodus: health checks mislukken door de firewall; sta de IP-bereiken van de load balancer toe naar de backend-nodes.

Autoscaling en Node Pools

Horizontal Pod Autoscaler (HPA): Schaalt pods op basis van CPU, geheugen of aangepaste metrics; combineer met Pod Disruption Budgets om de beschikbaarheid te beschermen.
Vertical Pod Autoscaler (VPA): Bepaalt de juiste grootte voor pod requests/limits; vermijd gelijktijdige HPA+VPA op dezelfde dimensie om feedback-loops te voorkomen.
Cluster Autoscaler: Voegt nodes toe of verwijdert ze om te voldoen aan de resource-aanvragen van wachtende pods.
Node pools: Scheid pools per workload-klasse. Gebruik taints/tolerations en labels voor scheduling. Mix spot/preemptible voor kostengevoelige workloads met tolerantie voor onderbrekingen. Kies machinetypes met voldoende geheugenbandbreedte/CPU voor per-pod-limieten om throttling te voorkomen.

Health en rollouts

Liveness-, readiness- en startup-probes voorkomen dat verkeer naar niet-gereede pods wordt gestuurd en herstarten vastgelopen containers. Strakke liveness probes kunnen trapsgewijze herstarts veroorzaken; stem de initiële vertragingen en faaldrempels af.
Rollback met kubectl rollout undo. Gebruik voor canary meerdere Deployments en verkeerssplitsing op Service-niveau via Ingress/Gateway.

Compute Engine voor Applicatieworkloads

VM-ontwerp

Instance templates definiëren machinetype, image, disks, service account-scopes, opstartscripts en metadata. Houd images minimaal; gebruik opstartscripts of images die met Packer zijn voorbereid (‘baked’) voor een deterministische opstart.
Disks: Gebruik balanced of SSD persistent disks voor latency-gevoelige apps. Deel grote read-only datasets over een managed instance group via een read-only persistent disk die aan meerdere instances is gekoppeld voor lage latency en een snelle opstart.
Networking: Maak firewall-regels aan voor health checkers wanneer je load balancers gebruikt. Voorbeeld:

  gcloud compute firewall-rules create allow-lb \
    --network my-net --allow tcp \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 --direction INGRESS

Managed Instance Groups (MIGs)

Autoscaling op basis van CPU, load balancer requests per seconde, custom metrics of schema’s. Stel cool-downs in om instabiliteit (thrashing) te voorkomen.
Autohealing met health checks herstart ongezonde VM’s; zorg ervoor dat het health check-pad de gereedheid van de applicatie test, en niet alleen de bereikbaarheid van de poort, om te voorkomen dat 500-fouten worden geserveerd.
Rolling updates en blue-green: Maak een nieuw instance template aan en start een canary update naar een subset van de instances. Als het aantal fouten toeneemt, voer dan een rollback uit naar het vorige template. Uptime-controles en op SLO gebaseerde alarmering detecteren verslechteringen snel.

Logging en monitoring

Installeer agents om app-logs te verzamelen zonder codewijzigingen; stuur deze naar Cloud Logging en alarmeer via Cloud Monitoring. Gebruik Debug Logpoints voor live diagnostiek met minimale verstoring.

Build, Identiteit, Netwerken, Secrets en Operations

Artifact Registry en images

Gebruik Artifact Registry voor container-images en taal-artefacten. Schakel vulnerability scanning en provenance-generatie in. Houd images klein:
- Multi-stage builds om de build- en runtime-fase te scheiden.
- Vermijd dev-tools in de uiteindelijke image; pin de OS- en package-versies. Voorbeeld:

  FROM golang:1.22 AS build
  WORKDIR /src
  COPY . .
  RUN CGO_ENABLED=0 go build -o app

  FROM gcr.io/distroless/base-debian12
  COPY --from=build /src/app /app
  ENTRYPOINT ["/app"]

Promotie: Tag images onveranderlijk (bijv. app:1.3.7, app:prod-20240901) en promoot door ze opnieuw te taggen in Artifact Registry; vermijd het veranderlijke ’latest’ in productie. Controleer promoties op basis van de resultaten van integratie- en canary-tests.

Runtime-identiteit en ’least privilege’

Wijs een dedicated service account toe per workload met de minimaal vereiste IAM-rollen. Vermijd brede rollen zoals Editor. In GKE, map Kubernetes ServiceAccounts naar Google service accounts via Workload Identity. Voor serverless, stel het runtime service account expliciet in en verwijder de default-token scopes.

VPC-connectors en service-netwerken

Serverless VPC Access-connectors routeren egress-verkeer van Cloud Run, Cloud Functions en App Engine naar een VPC. Kies de egress-modus:
- Alleen private ranges om RFC1918 en met VPC verbonden services te bereiken, terwijl publiek egress-verkeer direct gaat.
- Al het verkeer via de connector plus Cloud NAT voor deterministische egress-IP’s en beperkte uitgaande policies.
Private afhankelijkheden: Geef de voorkeur aan Private IP voor Cloud SQL en Private Service Connect voor Google API’s of partner-services. Zorg ervoor dat connectors qua regio overeenkomen en gedimensioneerd zijn voor de benodigde doorvoer; monitor de CPU van de connector om ’throttling’ te voorkomen.

Configuratie, secrets en health checks

Gebruik omgevingsvariabelen voor niet-gevoelige configuratie. Sla secrets op in Secret Manager en mount of injecteer ze tijdens runtime; roteer sleutels regelmatig. Gebruik in GKE Secrets en de CSI-driver voor Secret Manager. Geef in App Engine en Cloud Run het service account toegang tot specifieke secrets.
Health checks:
- Cloud Run: instance herstart bij een crash; gebruik checks op request-niveau en latency-SLI’s.
- App Engine: ingebouwde health checks; pas liveness/readiness aan voor Flexible.
- GKE: configureer liveness/readiness/startup probes.
- Compute Engine achter LB’s: gebruik HTTP(S) health checks met applicatie-specifieke endpoints.

Troubleshooting, rollback en release-patronen

Blue-green en canary met traffic splitting op Cloud Run en App Engine; gebruik in GKE parallelle Deployments of progressive delivery controllers; gebruik in MIG’s canary-subsets van instances. Definieer altijd afbreekcriteria op basis van het SLO error budget en de latency.
Veelvoorkomende faalscenario’s:
- ‘Thundering herds’ na ‘scale-to-zero’ of grote rollouts; beperk dit met ‘min instances’, ‘warmups’ en ‘rate limiting’.
- Overschreden backend-quota’s of verbindingslimieten; pas ’exponential backoff’ en ‘circuit breakers’ toe.
- ‘Cold starts’ door grote images of afhankelijkheden; maak images slanker en pre-initialiseer clients.

Praktijkscenario

Acme Retail is van plan een image-resize API te migreren van zelfbeheerde VM’s naar een schaalbaar, kosteneffectief platform met low-latency responses, private toegang tot een regionale Cloud Storage-bucket en veilige canary releases.

Aanpak

Package de service als een kleine container-image en publiceer deze naar Artifact Registry.

Rationale: Een slanke, multi-stage Docker-build minimaliseert ‘cold starts’ en netwerkoverdracht. Artifact Registry centraliseert scans en promotie-workflows.

Deploy de API naar Cloud Run met ‘min instances’ op 2, ‘concurrency’ op 40 en ‘CPU always allocated’ uitgeschakeld.

Rationale: Cloud Run biedt onmiddellijke horizontale schaalbaarheid en beheerde HTTPS. Een kleine ‘min instance’-pool vermindert de ‘cold start’-latency tijdens dagelijkse pieken. Een ‘concurrency’ van 40 balanceert kosten en ’tail latency’ voor I/O-gebonden imagetransformaties. Het uitschakelen van ‘always-on CPU’ voorkomt dat er betaald wordt voor ongebruikte compute tussen requests.

Maak een Serverless VPC Access-connector en stel egress in op ‘private ranges only’; schakel Private Google Access in op het subnet en configureer indien nodig een VPC-SC of Private Service Connect-endpoint voor Cloud Storage.

Rationale: De API moet images privaat ophalen en wegschrijven zonder publiek egress-verkeer. De ‘private ranges’-modus zorgt ervoor dat alleen VPC-verkeer via de connector loopt, waardoor publieke calls direct en efficiënt blijven. Private Google Access of Private Service Connect biedt private toegang tot Google API’s vanuit de VPC.

Geef een dedicated runtime service account ’least-privilege’-toegang tot de betreffende Cloud Storage-bucket en de vereiste secrets.

Rationale: Het ‘principle of least privilege’ beperkt de ‘blast radius’. De runtime-identiteit krijgt ‘storage.objectViewer’ en ‘storage.objectAdmin’ op de specifieke bucket, en ‘accessor’ op de benodigde Secret Manager-secrets.

Sla API-sleutels en per-omgeving-configuratie op in Secret Manager en omgevingsvariabelen; injecteer secrets tijdens runtime.

Rationale: Gecentraliseerde rotatie van secrets en auditeerbare toegang. Niet-gevoelige configuratie via omgevingsvariabelen ondersteunt ‘12-factor’-praktijken.

Implementeer ’exponential backoff’ en idempotente schrijfacties om 429/5xx-fouten van Cloud Storage af te handelen.

Rationale: Tijdens pieken of regionale gebeurtenissen kunnen tijdelijke fouten optreden. ‘Backoff with jitter’ beschermt zowel de API als Cloud Storage tegen ‘retry storms’.

Configureer een canary-revisie en splits 10% van het verkeer hiernaartoe; monitor de error rate, P95-latency en saturatie.

Rationale: Traffic splitting op Cloud Run maakt een veilige, progressieve rollout mogelijk. Op SLO gebaseerde monitors zorgen voor automatische rollback-triggers als error budgets te snel opraken.

Voeg een HTTP-health-endpoint toe dat downstream-afhankelijkheden test; stel alerts in op Cloud Monitoring uptime checks en op logs gebaseerde metrics.

Rationale: End-to-end health detecteert vroegtijdig storingen in afhankelijkheden. Uptime checks bieden een extern perspectief; op logs gebaseerde metrics vangen applicatie-specifieke faalpatronen op.

Stel autoscaling-limieten en budgetten vast; stel ‘max instances’ in om de uitgaven te beperken en definieer de afhandeling van 429-fouten bij overbelasting.

Rationale: Het begrenzen van de schaal voorkomt uit de hand lopende kosten en uitputting van de backend. Correct gedrag bij overbelasting (‘graceful overload’) handhaaft de stabiliteit van de service.