Google PCD: Compute, Container und Serverless-Laufzeitplattformen — Lernleitfaden

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

Teil des Google Professional Cloud Developer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Google Cloud bietet mehrere Laufzeitplattformen, die Serverless, Container und virtuelle Maschinen umfassen. Die Auswahl der richtigen Plattform hängt von den Eigenschaften der Workloads ab, wie z. B. Anfragemuster, Zustandsverwaltung, Build- und Release-Disziplin, Betriebsmodell und Netzwerkeinschränkungen. Dieser Abschnitt behandelt Designprinzipien, Fehlermodi und Kompromisse für Cloud Run, App Engine, Cloud Functions, Google Kubernetes Engine (GKE) und Compute Engine sowie unterstützende Dienste für Images, Identität, Netzwerk, Konfiguration und Betrieb.

Serverless Runtimes: Cloud Run, App Engine, Cloud Functions

Cloud Run

• Modell: Vollständig verwaltete Container mit HTTP-Anfrageverarbeitung oder containerisierte Jobs, die bis zum Abschluss ausgeführt werden.
• Revisionen und Traffic: Jedes Deployment erstellt eine unveränderliche Revision. Die prozentuale Aufteilung des Traffics auf die Revisionen ermöglicht Canary- und Blue-Green-Muster mit sofortigem Rollback. Beispiel:

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

• Gleichzeitigkeit und Skalierung: Die Standard-Gleichzeitigkeit (Concurrency) beträgt 80; für CPU-gebundenen oder nicht threadsicheren Code auf 1 setzen. Eine höhere Gleichzeitigkeit reduziert die Verstärkung von Kaltstarts und die Kosten, kann aber die Tail-Latenz erhöhen, wenn die CPU/der Speicher pro Anfrage nicht ausreicht. Cloud Run skaliert auf null und je nach eingehender Anfragerate nach oben; steuern Sie dies mit min/max-Instanzen, um Kaltstarts zu reduzieren und die Kosten zu begrenzen.
• CPU-Zuweisung: Wählen Sie „CPU immer zugewiesen“ für Hintergrundarbeiten zwischen Anfragen, was zu zusätzlichen Kosten führt; andernfalls wird die CPU nur während der Bearbeitung von Anfragen zugewiesen.
• Jobs: Cloud Run Jobs führen N parallele Tasks bis zum Abschluss aus, mit maximalen Wiederholungsversuchen pro Task und Gesamt-Timeouts; geeignet für ETL-, Batch- und Fan-Out-Verarbeitung. Zu den Fehlermodi gehört das Hot-Spotting von Backends, wenn viele Tasks auf dieselbe Abhängigkeit abzielen; fügen Sie Ratenbegrenzung und Wiederholungsversuche mit Backoff hinzu.
• Netzwerk: Öffentlich, über IAM authentifiziert oder privat hinter einer VPC über Serverless VPC Access und Private Service Connect.

App Engine

• Umgebungen:
  • Standard: Gesandboxed, schnelle Skalierung, sprachspezifische feste Runtimes; geringe Kaltstart-Latenz mit automatischer Skalierung; eingeschränktes Dateisystem, Anfrage-Timeouts und Größenbeschränkungen für eingehende Anfragen. Verwenden Sie für große Uploads signierte URLs von Cloud Storage.
  • Flexibel: Docker-basiert, VM-ähnliche Funktionen, benutzerdefinierte Runtimes, langsamere Skalierung als Standard, unterstützt Hintergrund-Threads und das Schreiben auf lokale Datenträger.
• Dienste und Versionen: Ein Dienst (Microservice) kann mehrere Versionen hosten; leiten Sie den Traffic prozentual auf die Versionen um, ähnlich wie bei Cloud Run. Verwenden Sie dispatch.yaml, um bestimmte Pfade oder Hosts zu Diensten zu leiten, für ein einfaches, zentralisiertes Routing ohne externen Load Balancer.
• Skalierung: Manuell, Basic oder automatisch in Standard; VM-anzahlbasierte Skalierung in Flexibel. Kompromiss: Aggressives Autoscaling verbessert die Reaktionsfähigkeit, kann aber die Kosten und die Backend-Konkurrenz (Contention) erhöhen.
• Häufige Fallstricke: Unbegrenzte Instanzskalierung ohne Quotas kann nachgelagerte Systeme überlasten; erzwingen Sie Quotas und Circuit Breaker.

Cloud Functions

• Ereignisgesteuerte Handler: Ausgelöst durch HTTP-, Pub/Sub-, Cloud Storage- oder Eventarc-Ereignisse. Verwenden Sie die 2. Generation, um das Ausführungsmodell von Cloud Run, die VPC-Egress-Kontrolle und die Gleichzeitigkeit zu nutzen; die 1. Generation verarbeitet eine Anfrage nach der anderen.
• Wiederholungsversuche und Idempotenz: Hintergrundfunktionen können bei einem Fehler wiederholt werden; entwerfen Sie idempotente Handler und verwenden Sie Deduplizierungsschlüssel, um eine doppelte Verarbeitung zu vermeiden. HTTP-Trigger werden von der Plattform nicht wiederholt; implementieren Sie clientseitige Wiederholungsversuche mit exponentiellem Backoff.
• Laufzeitkonfiguration: Umgebungsvariablen, Integration von Secret Manager und funktionsspezifische Gleichzeitigkeit/max-Instanzen. Setzen Sie Timeouts, um ausufernde Kosten zu begrenzen. Vorsicht vor langen Kaltstarts bei großen Abhängigkeiten; halten Sie die Pakete schlank.

Container auf Google Kubernetes Engine

Workloads

• Deployments: Zustandslose Pods mit Rolling Updates. Stellen Sie sichere Rollouts mit Surge/Unavailable-Limits sicher:

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

• StatefulSets: Geordnete, stabile Netzwerk-IDs und persistente Volumes für zustandsbehaftete Dienste.
• DaemonSets, Jobs, CronJobs: Agenten auf Knotenebene und Batch-Workloads.

Services und Ingress

• Service-Typen:
  • ClusterIP nur für intern.
  • NodePort für einfachen externen Zugriff (operativ eingeschränkt).
  • LoadBalancer für regionales externes/internes Load Balancing.
• Ingress: HTTP(S)-Routing und TLS-Terminierung; bevorzugen Sie die Gateway API oder Ingress mit verwalteten Controllern für L7-Richtlinien. Fehlermodus: Health Checks schlagen aufgrund der Firewall fehl; erlauben Sie die IP-Bereiche des Load Balancers zu den Backend-Knoten.

Autoscaling und Node Pools

• Horizontal Pod Autoscaler (HPA): Skaliert Pods basierend auf CPU, Speicher oder benutzerdefinierten Metriken; kombinieren Sie ihn mit Pod Disruption Budgets, um die Verfügbarkeit zu schützen.
• Vertical Pod Autoscaler (VPA): Passt die Anfragen/Limits von Pods an (Right-Sizing); vermeiden Sie die gleichzeitige Verwendung von HPA+VPA auf derselben Dimension, um Rückkopplungsschleifen zu verhindern.
• Cluster Autoscaler: Fügt Knoten hinzu oder entfernt sie, um die Ressourcenanforderungen ausstehender Pods zu erfüllen.
• Node Pools: Trennen Sie Pools nach Workload-Klasse. Verwenden Sie Taints/Tolerations und Labels für das Scheduling. Mischen Sie Spot-/Preemptible-Instanzen für kostensensitive Workloads mit Störungstoleranz. Wählen Sie Maschinentypen mit genügend Speicherbandbreite/CPU für die Pod-Limits, um Drosselung (Throttling) zu vermeiden.

Health und Rollouts

• Liveness-, Readiness- und Startup-Probes verhindern, dass Traffic an nicht bereite Pods gesendet wird, und starten festgefahrene Container neu. Zu eng gesetzte Liveness-Probes können kaskadierende Neustarts verursachen; passen Sie die anfänglichen Verzögerungen und Fehlerschwellen an.
• Rollback mit kubectl rollout undo. Für Canary-Deployments verwenden Sie mehrere Deployments und eine Traffic-Aufteilung auf Service-Ebene über Ingress/Gateway.

Compute Engine für Anwendungsworkloads

VM-Design

• Instanzvorlagen definieren Maschinentyp, Image, Festplatten, Service-Account-Bereiche, Startskripte und Metadaten. Halten Sie Images minimal; verwenden Sie Startskripte oder mit Packer erstellte Images für einen deterministischen Start.
• Festplatten: Verwenden Sie ausbalancierte oder SSD-Persistent-Disks für latenzempfindliche Anwendungen. Teilen Sie große schreibgeschützte Datensätze über eine verwaltete Instanzgruppe hinweg, indem Sie eine schreibgeschützte Persistent Disk an mehrere Instanzen anhängen, um eine niedrige Latenz und einen schnellen Start zu erreichen.
• Netzwerk: Erstellen Sie Firewall-Regeln für Systemdiagnosen (Health Checker), wenn Sie Load Balancer verwenden. Beispiel:

  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

Verwaltete Instanzgruppen (MIGs)

• Autoscaling nach CPU, Anfragen pro Sekunde am Load Balancer, benutzerdefinierten Metriken oder Zeitplänen. Legen Sie Cool-down-Perioden fest, um Oszillationen (Thrashing) zu vermeiden.
• Autohealing mit Systemdiagnosen startet fehlerhafte VMs neu; stellen Sie sicher, dass der Pfad der Systemdiagnose die Anwendungsbereitschaft testet und nicht nur die Erreichbarkeit des Ports, um die Auslieferung von 500-Fehlern zu vermeiden.
• Rolling Updates und Blue-Green: Erstellen Sie eine neue Instanzvorlage und starten Sie ein Canary-Update für eine Teilmenge der Instanzen. Bei steigender Fehlerrate führen Sie ein Rollback auf die vorherige Vorlage durch. Uptime-Prüfungen und SLO-basiertes Alerting erkennen Verschlechterungen schnell.

Logging und Monitoring

• Installieren Sie Agents, um Anwendungs-Logs ohne Code-Änderungen zu sammeln; leiten Sie diese an Cloud Logging weiter und lassen Sie sich über Cloud Monitoring benachrichtigen. Verwenden Sie Debug Logpoints für Live-Diagnosen mit minimaler Unterbrechung.

Build, Identität, Netzwerk, Secrets und Betrieb

Artifact Registry und Images

• Verwenden Sie Artifact Registry für Container-Images und Sprachartefakte. Aktivieren Sie Schwachstellenscans und die Generierung von Provenienz. Halten Sie Images klein:
  • Multi-Stage-Builds zur Trennung von Build- und Laufzeitumgebung.
  • Vermeiden Sie Entwickler-Tools im finalen Image; pinnen Sie Betriebssystem- und Paketversionen. Beispiel:

  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"]

• Promotion: Taggen Sie Images unveränderlich (z. B. app:1.3.7, app:prod-20240901) und führen Sie die Promotion durch erneutes Taggen in Artifact Registry durch; vermeiden Sie das veränderliche latest-Tag in der Produktion. Steuern Sie Promotions durch die Ergebnisse von Integrations- und Canary-Tests.

Laufzeitidentität und geringste Rechte (Least Privilege)

• Weisen Sie pro Workload ein dediziertes Servicekonto mit den minimal erforderlichen IAM-Rollen zu. Vermeiden Sie weitreichende Rollen wie „Bearbeiter“ (Editor). In GKE mappen Sie Kubernetes ServiceAccounts über Workload Identity auf Google-Dienstkonten. Bei Serverless-Diensten setzen Sie das Laufzeit-Dienstkonto explizit und entfernen Sie die default-token-Scopes.

VPC-Connectors und Service-Netzwerk

• Serverless VPC Access Connectors leiten ausgehenden Traffic (Egress) von Cloud Run, Cloud Functions und App Engine in eine VPC. Wählen Sie den Egress-Modus:
  • Nur private Bereiche, um RFC1918- und VPC-verbundene Dienste zu erreichen, während öffentlicher Egress direkt erfolgt.
  • Gesamter Traffic über den Connector plus Cloud NAT für deterministische Egress-IPs und eingeschränkte ausgehende Richtlinien.
• Private Abhängigkeiten: Bevorzugen Sie Private IP für Cloud SQL und Private Service Connect für Google APIs oder Partnerdienste. Stellen Sie sicher, dass die Connectors zur Region passen und für den erforderlichen Durchsatz dimensioniert sind; überwachen Sie die CPU-Auslastung des Connectors, um Drosselung zu vermeiden.

Konfiguration, Secrets und Systemdiagnosen (Health Checks)

• Verwenden Sie Umgebungsvariablen für nicht-vertrauliche Konfigurationen. Speichern Sie Secrets im Secret Manager und mounten oder injizieren Sie sie zur Laufzeit; rotieren Sie die Schlüssel regelmäßig. In GKE verwenden Sie Secrets und den CSI-Treiber für Secret Manager. In App Engine und Cloud Run gewähren Sie dem Dienstkonto Zugriff auf bestimmte Secrets.
• Systemdiagnosen (Health Checks):
  • Cloud Run: Instanzneustarts bei Abstürzen; verwenden Sie Prüfungen auf Anfrageebene und Latenz-SLIs.
  • App Engine: integrierte Systemdiagnosen; passen Sie Liveness/Readiness für die Flexible Environment an.
  • GKE: Konfigurieren Sie Liveness/Readiness/Startup Probes.
  • Compute Engine hinter LBs: Verwenden Sie HTTP(S)-Systemdiagnosen mit anwendungsspezifischen Endpunkten.

Fehlerbehebung, Rollback und Release-Muster

• Blue-Green und Canary mit Traffic-Splitting bei Cloud Run und App Engine; in GKE verwenden Sie parallele Deployments oder Progressive-Delivery-Controller; in MIGs verwenden Sie Canary-Subsets von Instanzen. Definieren Sie immer Abbruchkriterien basierend auf dem SLO-Fehlerbudget und der Latenz.
• Häufige Fehlermodi:
  • „Thundering Herds“ nach dem Skalieren auf Null oder bei großen Rollouts; mildern Sie dies durch Mindestanzahl an Instanzen, Warmups und Ratenbegrenzung (Rate Limiting).
  • Überschrittene Backend-Kontingente oder Verbindungslimits; wenden Sie exponentielles Backoff und Circuit Breaker an.
  • Kaltstarts aufgrund großer Images oder Abhängigkeiten; verschlanken Sie Images und initialisieren Sie Clients vorab.

Praktisches Problemszenario

Acme Retail plant die Migration einer API zur Bildgrößenänderung von selbstverwalteten VMs auf eine skalierbare, kosteneffiziente Plattform mit geringer Latenz, privatem Zugriff auf einen regionalen Cloud Storage Bucket und sicheren Canary-Releases.

Vorgehensweise

1. Verpacken Sie den Dienst als kleines Container-Image und veröffentlichen Sie es in Artifact Registry.

• Begründung: Ein schlanker, mehrstufiger Docker-Build minimiert Kaltstarts und Netzwerkübertragungen. Artifact Registry zentralisiert Scans und Promotion-Workflows.

2. Stellen Sie die API auf Cloud Run bereit, mit einer Mindestanzahl von 2 Instanzen (min instances), einer Gleichzeitigkeit (concurrency) von 40 und deaktivierter Option „CPU immer zugewiesen“ (CPU always allocated).

• Begründung: Cloud Run bietet sofortige horizontale Skalierung und verwaltetes HTTPS. Ein kleiner Pool an Mindestinstanzen reduziert die Kaltstartlatenz während täglicher Lastspitzen. Eine Gleichzeitigkeit von 40 schafft einen Ausgleich zwischen Kosten und Tail-Latenz für I/O-gebundene Bildtransformationen. Die Deaktivierung der permanenten CPU-Zuweisung vermeidet Kosten für ungenutzte Rechenleistung zwischen den Anfragen.

3. Erstellen Sie einen Serverless VPC Access Connector und stellen Sie den Egress auf „Nur private Bereiche“ (private ranges only) ein; aktivieren Sie den privaten Google-Zugriff (Private Google Access) im Subnetz und konfigurieren Sie bei Bedarf einen VPC-SC- oder Private Service Connect-Endpunkt für Cloud Storage.

• Begründung: Die API muss Bilder privat abrufen und schreiben, ohne öffentlichen Egress-Traffic zu erzeugen. Der Modus für private Bereiche stellt sicher, dass nur VPC-Traffic durch den Connector geleitet wird, während öffentliche Aufrufe direkt und effizient bleiben. Private Google Access oder Private Service Connect ermöglichen den privaten Zugriff auf Google APIs aus der VPC.

4. Gewähren Sie einem dedizierten Laufzeit-Dienstkonto den Zugriff mit den geringsten Rechten (Least Privilege) auf den Ziel-Cloud-Storage-Bucket und die erforderlichen Secrets.

• Begründung: Das Prinzip der geringsten Rechte (Principle of Least Privilege) begrenzt den potenziellen Schaden (Blast Radius). Die Laufzeitidentität erhält die Rollen storage.objectViewer und storage.objectAdmin für den spezifischen Bucket und die accessor-Rolle für die benötigten Secrets im Secret Manager.

5. Speichern Sie API-Schlüssel und umgebungsspezifische Konfigurationen im Secret Manager und in Umgebungsvariablen; injizieren Sie die Secrets zur Laufzeit.

• Begründung: Zentralisierte Rotation von Secrets und auditierbarer Zugriff. Nicht-vertrauliche Konfigurationen über Umgebungsvariablen unterstützen die 12-Factor-App-Methodik.

6. Implementieren Sie exponentielles Backoff und idempotente Schreibvorgänge, um 429/5xx-Fehler von Cloud Storage zu behandeln.

• Begründung: Bei Lastspitzen oder regionalen Ereignissen können vorübergehende Fehler auftreten. Backoff mit Jitter schützt sowohl die API als auch Cloud Storage vor Wiederholungsstürmen (Retry Storms).

7. Konfigurieren Sie eine Canary-Revision und leiten Sie 10 % des Traffics dorthin; überwachen Sie Fehlerrate, P95-Latenz und Sättigung.

• Begründung: Das Traffic-Splitting in Cloud Run ermöglicht ein sicheres, schrittweises Rollout. SLO-basierte Überwachungen bieten automatische Rollback-Trigger, falls Fehlerbudgets zu schnell aufgebraucht werden.

8. Fügen Sie einen HTTP-Systemdiagnose-Endpunkt hinzu, der nachgelagerte Abhängigkeiten prüft; richten Sie Benachrichtigungen für Cloud Monitoring Uptime Checks und logbasierte Messwerte ein.

• Begründung: End-to-End-Systemdiagnosen erkennen Ausfälle von Abhängigkeiten frühzeitig. Uptime Checks bieten eine externe Perspektive; logbasierte Messwerte erfassen anwendungsspezifische Fehlermuster.

9. Legen Sie Autoscaling-Limits und Budgets fest; setzen Sie eine maximale Instanzanzahl (max instances), um die Ausgaben zu deckeln, und definieren Sie die Behandlung von 429-Fehlern bei Überlastung.

• Begründung: Die Begrenzung der Skalierung verhindert unkontrollierte Kosten und die Erschöpfung des Backends. Ein kontrolliertes Überlastverhalten erhält die Stabilität des Dienstes.

10. Dokumentieren Sie den Rollback: Leiten Sie 100 % des Traffics mit einem einzigen Befehl auf die vorherige Cloud Run-Revision zurück.

• Begründung: Unveränderliche Revisionen machen den Rollback sicher und schnell und minimieren so die mittlere Wiederherstellungszeit (MTTR).

← Cloud-native Anwendungsarchitektur und Service-Auswahl · Alle Domänen · API-Design →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Google durchsuchen →