GKE, Serverless & the Agent Platform

Assumes you're comfortable with Part 4's shared-responsibility framing. This chapter moves progressively toward the "Google manages more" end of that same spectrum, ending at a platform where you don't manage servers at all.

Table of Contents#

1. What This Chapter Covers
2. GKE Autopilot vs. Standard: Billing, Requests, and Choosing
3. Deploying a GKE Cluster
4. kubectl, Node Pools, and Cluster Access
5. Pod Autoscaling: HPA, VPA, and Autopilot's Resource Model
6. GKE and Artifact Registry
7. Cloud Run, Cloud Run Functions, and Traffic Splitting
8. Eventarc: Event-Driven Serverless
9. GPUs and TPUs on GKE and Cloud Run
10. The Agent Runtime on the Gemini Enterprise Agent Platform
11. Cloud Workstations: Standardized Developer Environments
12. Notebooks: Agent Platform Workbench and BigQuery
13. Choosing Between GKE, Cloud Run, and the Agent Runtime
14. A Full Worked Example: Meridian's AI Dispatch Assistant
15. Real-World Scenario: The Autopilot Bill Nobody Understood
16. Second Real-World Scenario: The Cloud Workstation That Drifted From Production
17. Part 5 kubectl and gcloud Cheat Sheet
18. Pre-Flight Checklist: Is This Serverless/GKE Design Production-Ready?
19. Common Mistakes and Interview Traps
20. Worked Practice Problems
21. Summary and What's Next

What This Chapter Covers#

🎯 By the end of this chapter, you'll be able to choose correctly between GKE, Cloud Run, and the newest addition to this exam domain, deploying an AI agent onto a managed runtime, and know which developer-facing tooling (Cloud Workstations, managed notebooks) belongs alongside each.

GKE Autopilot vs. Standard: Billing, Requests, and Choosing#

GKE Standard gives you full control over node pools: you choose machine types, manage node-level scaling, and pay for provisioned VMs whether or not Pods are using their full capacity. GKE Autopilot removes node management entirely: Google provisions and scales the underlying infrastructure automatically, and you're billed per Pod resource request (vCPU and memory), not per node.

Deploying a GKE Cluster#

# Autopilot: a single command provisions a fully managed cluster
gcloud container clusters create-auto meridian-agent-cluster \
  --region=us-central1 \
  --project=meridian-freight-prod-8f2k

# Standard, regional (control plane replicated across 3 zones),
# private (nodes have no public IP)
gcloud container clusters create meridian-freight-cluster \
  --region=us-central1 \
  --num-nodes=2 \
  --enable-private-nodes \
  --enable-ip-alias \
  --workload-pool=meridian-freight-prod-8f2k.svc.id.goog

--workload-pool enables Workload Identity Federation for GKE (Part 3) at cluster creation, the current recommended default rather than something bolted on afterward. --enable-private-nodes means nodes have no public IP at all, reachable only through the cluster's internal network and (for control-plane access) Google's own private connection path, a meaningful reduction in attack surface for any production cluster.

kubectl, Node Pools, and Cluster Access#

kubectl is installed as a gcloud component (gcloud components install kubectl) and authenticated against a specific cluster via gcloud container clusters get-credentials, which writes the cluster's endpoint and a short-lived auth plugin configuration into your local kubeconfig.

Node pools (Standard mode only, since Autopilot has no visible nodes to pool) are a set of nodes sharing a common configuration; a cluster typically has several, letting you mix machine types or Spot/on-demand nodes for different workload classes within one cluster.

gcloud container clusters get-credentials meridian-freight-cluster --region=us-central1

# Add a Spot-backed node pool for fault-tolerant batch workloads
gcloud container node-pools create batch-spot-pool \
  --cluster=meridian-freight-cluster \
  --region=us-central1 \
  --spot \
  --machine-type=n2-standard-4 \
  --enable-autoscaling --min-nodes=0 --max-nodes=10

Pod Autoscaling: HPA, VPA, and Autopilot's Resource Model#

⚠️ On Autopilot, every Pod must declare resource requests, and Autopilot will modify a Pod that doesn't meet its minimum thresholds rather than schedule it as-is. This is a meaningful behavioral difference from Standard mode, where an un-requested Pod is technically schedulable (though never advisable) and simply competes uncontrolled for whatever capacity the node happens to have free.

GKE and Artifact Registry#

Artifact Registry is GCP's current container and package registry (the successor to the deprecated Container Registry), and GKE nodes need explicit IAM permission (roles/artifactregistry.reader, typically via the node's or workload's service account) to pull images from it. A cluster's Pods failing with ImagePullBackOff against a private Artifact Registry repository is almost always this permission missing, not a networking problem, the same "check enablement/permission before networking" instinct from Part 1's API troubleshooting habit.

Cloud Run, Cloud Run Functions, and Traffic Splitting#

Cloud Run runs a containerized application as a fully managed, autoscaling (including to zero) service, billed only while a request is being processed. Cloud Run functions (the current name for what was Cloud Functions 2nd gen) is the same underlying platform, framed around a single function handler rather than a full container you build yourself.

gcloud run deploy meridian-dispatch-api \
  --image=us-central1-docker.pkg.dev/meridian-freight-prod-8f2k/app-images/dispatch-api:v3 \
  --region=us-central1 \
  --no-allow-unauthenticated \
  --service-account=meridian-dispatcher@meridian-freight-prod-8f2k.iam.gserviceaccount.com

# Deploy a new revision without shifting any traffic to it yet
gcloud run deploy meridian-dispatch-api \
  --image=.../dispatch-api:v4 --no-traffic --tag=canary

# Shift 10% of traffic to the new revision, watch metrics, then promote
gcloud run services update-traffic meridian-dispatch-api \
  --to-tags=canary=10

Caption: the old revision isn't deleted on promotion, it scales to zero and stays available, which is exactly what makes an instant rollback (update-traffic --to-revisions=v3=100) possible if the canary's metrics turn bad after full promotion.

Eventarc: Event-Driven Serverless#

Eventarc routes events (a Cloud Storage object finalized, a Pub/Sub message published, an Audit Log entry, a direct custom event) to a target (Cloud Run, Cloud Run functions, GKE) using a standardized CloudEvents format, decoupling the event source from the handler so the same routing infrastructure works regardless of which service actually emits the event.

gcloud eventarc triggers create meridian-shipment-upload \
  --destination-run-service=meridian-shipment-processor \
  --destination-run-region=us-central1 \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=meridian-shipment-docs"

GPUs and TPUs on GKE and Cloud Run#

Both GKE and Cloud Run now support attaching GPUs directly to a Pod or service, letting a serverless or Kubernetes-native workload use accelerated compute without you provisioning a dedicated Compute Engine VM. The tradeoff versus a raw Compute Engine GPU instance (Part 4) is the same tradeoff that runs through this whole chapter: less infrastructure to manage, at the cost of some configuration flexibility (available GPU models and node-pool-level tuning are more constrained on Autopilot and Cloud Run than on a hand-managed Standard-mode node pool).

The Agent Runtime on the Gemini Enterprise Agent Platform#

The Agent Runtime is a managed, serverless execution environment specifically for deploying and running AI agents (built with a framework like the Agent Development Kit, or any framework packaged to its interface) without managing the underlying compute yourself, conceptually Cloud Run's autoscale-to-zero, pay-per-use model, but purpose-built for agent workloads: session state, tool-calling, and memory across a multi-turn interaction.

# Deploy a packaged agent to the Agent Runtime
gcloud ai agent-engines deploy meridian-dispatch-assistant \
  --project=meridian-freight-prod-8f2k \
  --region=us-central1 \
  --agent-package=./dispatch-assistant/

💡 The exam-relevant mental model: Cloud Run runs your general-purpose container; the Agent Runtime runs your agent specifically, with built-in primitives (conversational session state, tool invocation tracking) that a plain Cloud Run deployment would require you to build yourself on top of a database and a queue.

Cloud Workstations: Standardized Developer Environments#

Cloud Workstations provisions browser-accessible (or local-IDE-connected, via VS Code or JetBrains) development environments from a versioned workstation configuration, a template defining the machine type, persistent storage, and container image that defines the dev environment itself. Updating the configuration doesn't retroactively change a running workstation; the update applies the next time that workstation starts, the same "template edits don't touch existing instances until an explicit action" pattern from Part 4's MIG rolling updates.

Notebooks: Agent Platform Workbench and BigQuery#

Managed notebooks appear in two contexts on the exam: Gemini Enterprise Agent Platform Workbench (the renamed Vertex AI Workbench) provides managed Jupyter notebooks pre-wired with authentication and libraries for ML development against the Agent Platform, while BigQuery's own built-in notebook lets an analyst iterate directly against BigQuery data without leaving the BigQuery console or provisioning any separate compute at all. The distinction to hold onto: Workbench notebooks are a general ML development environment; BigQuery notebooks are specifically for in-place data analysis against BigQuery datasets.

Choosing Between GKE, Cloud Run, and the Agent Runtime#

Caption: the first, decisive question is whether the workload is specifically an agent; everything else follows the same serverless-vs-Kubernetes tradeoff this course has already built intuition for.

A Full Worked Example: Meridian's AI Dispatch Assistant#

# 1. Cloud Workstation for the team building the assistant,
#    using the same base image as CI
gcloud workstations configs create dispatch-assistant-dev \
  --cluster=meridian-dev-workstations \
  --region=us-central1 \
  --container-custom-image=us-central1-docker.pkg.dev/.../dev-base:latest

# 2. Deploy the packaged agent to the Agent Runtime
gcloud ai agent-engines deploy meridian-dispatch-assistant \
  --region=us-central1 --agent-package=./dispatch-assistant/

# 3. Front it with a Cloud Run service handling auth and request shaping
gcloud run deploy dispatch-assistant-gateway \
  --image=.../gateway:v1 --no-allow-unauthenticated

# 4. Wire an Eventarc trigger so a new shipment document
#    automatically kicks off an agent session
gcloud eventarc triggers create dispatch-assistant-trigger \
  --destination-run-service=dispatch-assistant-gateway \
  --event-filters="type=google.cloud.storage.object.v1.finalized"

Real-World Scenario: The Autopilot Bill Nobody Understood#

Meridian's platform team migrated a bursty internal reporting service from GKE Standard to Autopilot expecting savings, based on a general "serverless is cheaper" assumption rather than actual usage analysis. The following month's bill was 40% higher than Standard mode had been. The immediate cause was that the service, despite being "bursty" in request volume, ran at consistently high CPU utilization whenever it was active, batch report generation that fully saturated its allocated resources for hours at a stretch, exactly the profile where Standard mode's flat per-VM pricing beats Autopilot's per-request-resource premium. The underlying condition: the team had applied a general industry heuristic ("serverless saves money for bursty workloads") without checking whether this specific workload's utilization pattern actually matched the heuristic's assumption. They reverted to Standard mode with a properly sized, autoscaling node pool and cut costs back below the original baseline.

Second Real-World Scenario: The Cloud Workstation That Drifted From Production#

An engineer's Cloud Workstation, provisioned eight months earlier from a configuration nobody had updated since, still had an older major version of a shared internal library baked into its container image. Code that worked perfectly in local testing on that workstation failed immediately in CI, which built against the current production base image. Two engineers lost most of a day tracing what looked like a flaky test before realizing the workstation's environment itself was the actual variable. The fix mirrors this chapter's own Best Practice callout: the workstation configuration's container image was repointed to build from the same base image tag as the CI pipeline, with a scheduled monthly check confirming the two hadn't silently diverged again.

Part 5 kubectl and gcloud Cheat Sheet#

Pre-Flight Checklist: Is This Serverless/GKE Design Production-Ready?#

• The Autopilot-vs-Standard decision was based on actual measured utilization, not a general cost heuristic
• Every GKE cluster uses Workload Identity Federation (--workload-pool), not node-level default credentials
• Cloud Run services default to --no-allow-unauthenticated unless genuinely public
• A rollback path (a previous revision, or --to-revisions) is confirmed working before a canary promotion, not assumed
• Cloud Workstation images are built from the same base as CI, on a checked, non-drifting cadence
• Any AI agent workload uses the Agent Runtime's built-in session/tool-calling primitives rather than reinventing them on plain Cloud Run

Common Mistakes and Interview Traps#

Worked Practice Problems#

Problem 1: Meridian is deciding between GKE Autopilot and Standard for a workload with highly variable, spiky traffic that's idle roughly 70% of the day. Which mode fits better, and why?

Answer: Autopilot is the better fit here. Standard mode bills for provisioned node capacity around the clock regardless of whether Pods are using it, so a workload idle 70% of the time would still pay for that idle node capacity. Autopilot bills per Pod resource request only while Pods are actually running, meaning the idle periods cost nothing, exactly the profile Autopilot's pricing model is built to reward.

Problem 2: A Cloud Run canary deployment at 10% traffic shows an elevated error rate after fifteen minutes. What's the correct, safest next action, and why does keeping the previous revision around matter here?

Answer: Shift traffic back to the previous, known-good revision at 100% (gcloud run services update-traffic --to-revisions=PREVIOUS=100) rather than attempting to patch the new revision forward. This works instantly and safely specifically because Cloud Run never deletes a superseded revision on its own, it scales to zero and remains available, so a full rollback is a traffic-routing change, not a redeploy, and completes in seconds rather than however long a new build and deploy would take.

Problem 3: An engineer wants to build an internal tool that answers multi-turn questions about shipment status, calling out to several internal APIs mid-conversation and remembering context from earlier in the same conversation. Should this be built as a plain Cloud Run service, or deployed to the Agent Runtime, and why?

Answer: The Agent Runtime is the better fit. The requirement describes exactly what the Agent Runtime provides natively, multi-turn session state and tool-calling, both of which a plain Cloud Run service would require the team to build themselves on top of a database (for session state) and custom orchestration code (for tool-calling), duplicating infrastructure the Agent Runtime already offers as a managed primitive.

Summary and What's Next#

This chapter moved through the "Google manages more" end of the compute spectrum: GKE Autopilot versus Standard and their genuinely different billing models, Cloud Run's revision-based traffic splitting for safe rollouts, Eventarc for event-driven serverless, and the newest additions to this exam domain, the Agent Runtime for AI agent workloads, Cloud Workstations for standardized developer environments, and managed notebooks for ML and data work.

Part 6 moves to where all of this compute's data actually lives: Cloud Storage, the expanded set of managed databases (including newer additions like Managed Service for Apache Kafka and Memorystore), and the operational disciplines, backup, CMEK, cost estimation, that keep a data layer both correct and defensible in an audit.