Lesson 1: Every Google Cloud Container Service on One Page

Why start with a map?

On Google Cloud you can run a container about six different ways. Several services have also been renamed in the last few years. So when you get a job advert asking for "Anthos", a Terraform file that pushes to gcr.io, and a runbook that mentions "Traffic Director", you can lose a morning just working out what they mean today. This level is the map. Later levels go deep on each service. Here you learn what exists, what it is for, what it used to be called and how the pieces connect.

Think of it like the floor plan of a factory. Source code comes in at one end, gets built into an image, is stored in a warehouse (the registry), is checked at the gate (policy), runs on a production line (the runtime), talks to other lines (the mesh) and is watched by security cameras (threat detection).

The landscape, sorted by category

Gotcha: Cloud Run worker pools are new. They became GA on 14 April 2026 and suit pull-based background work, such as reading from a queue, that has no HTTP endpoint. Older articles say they don't exist or are in Preview.

Old name → new name

This is the decoder ring. Keep it next to any legacy repo.

Retiring: GKE on AWS and GKE on Azure went into maintenance mode on 17 March 2025. Support ends on 17 March 2027. Don't start new work on them.

The features from GKE Enterprise that now come with GKE include Fleet dashboard, Config Sync, Policy Controller, Connect Gateway and multi-team management. So when an old design says "we need Anthos for multi-cluster policy", that requirement no longer means a separate product.

Walkthrough: audit a project for old and new services

Before you choose anything, find out what is already switched on. Each service has an API name, and many API names still use the old product name.

# List enabled APIs and keep only the container-related ones
gcloud services list --enabled --format="value(config.name)" \
  | grep -E 'container|run|artifactregistry|cloudfunctions|cloudbuild|clouddeploy|mesh|trafficdirector|binaryauthorization|gkemulticloud|containerthreatdetection'

Realistic output from a five-year-old project:

artifactregistry.googleapis.com     # Artifact Registry
cloudbuild.googleapis.com           # Cloud Build
cloudfunctions.googleapis.com       # Cloud Run functions, still under its old API name
container.googleapis.com            # GKE ('container' = Kubernetes Engine)
containerregistry.googleapis.com    # legacy Container Registry: shut down, plan removal
run.googleapis.com                  # Cloud Run
trafficdirector.googleapis.com      # now part of Cloud Service Mesh

Then look for old names in your infrastructure code:

# Find legacy registry hosts and renamed products in Terraform and manifests
grep -rnE 'gcr\.io|anthos|traffic_director|cloudfunctions' --include='*.tf' --include='*.yaml' .

Trade-off to know: API names and Terraform resource names usually do not change when the marketing name does. GKE is still google_container_cluster and Cloud Run functions are still google_cloudfunctions2_function. Don't "fix" them. Just know what they are.

A gcr.io/... image path is not automatically broken. Artifact Registry can serve gcr.io domains if someone set up gcr.io repositories in it. If you see gcr.io, check where it really resolves before you assume it still works or that it fails.

The one-page map

Here is the arrow diagram to sketch from memory:

 source code (GitHub, GitLab, Cloud Source)
      │  trigger
      ▼
 Cloud Build ──builds + attests──► Artifact Registry (images, vuln scanning)
      │                                   │
      └──► Cloud Deploy (dev → staging → prod)
                                          │ pull
                     Binary Authorization ┤  (gate: only signed images pass)
                                          ▼
        ┌───────────────┬────────────────┬──────────────────┐
        GKE Standard /   Cloud Run        Compute Engine     (OpenShift Dedicated,
        Autopilot        services, jobs,  + Container-       App Engine flex)
        (fleets)         worker pools,    Optimized OS
                         functions
        └──── Cloud Service Mesh (mTLS, traffic splitting) ──┘
                                          │ runtime signals
                                          ▼
             Security Command Center: Container / Cloud Run Threat Detection

Read it top to bottom: build → store → gate → run → connect → watch. Binary Authorization checks at deploy time, before anything runs. Threat detection watches while it runs. One prevents, the other detects. You need both.

Key takeaways

• There are four main ways to run containers: GKE (Standard or Autopilot), Cloud Run (services, jobs, worker pools, functions), VMs with Container-Optimized OS, and the niche options (App Engine flex, OpenShift Dedicated).
• Around the runtimes sit Artifact Registry, Cloud Build / Cloud Deploy, Cloud Service Mesh, Binary Authorization and Security Command Center threat detection.
• Renames: GKE Enterprise and Anthos features folded into GKE (2 Sep 2025); Anthos Service Mesh + Traffic Director → Cloud Service Mesh; Cloud Functions → Cloud Run functions (Aug 2024); Container Registry → Artifact Registry (writes stopped 18 Mar 2025).
• Retiring: GKE on AWS/Azure (17 Mar 2027). Already shut down: the Compute Engine container startup agent (31 Jul 2026).
• API and Terraform names often keep the old product name, so audit by API, not by brochure.