Run containerized apps on Google Cloud: push images to Artifact Registry, run them serverlessly on Cloud Run with autoscaling and scale-to-zero, and understand when to reach for GKE (managed Kubernetes).
Containers package an app with everything it needs to run. Google Cloud gives you: Artifact Registry (store images), Cloud Run (run containers serverlessly), and GKE (managed Kubernetes). Why: Cloud Run is the simplest path — give it an image and it serves traffic; GKE is for teams already invested in Kubernetes.
echo "Artifact Registry = store container images"echo "Cloud Run = run containers serverlessly, scale to zero"echo "GKE = managed Kubernetes, for the Kubernetes ecosystem"Artifact Registry is a private Docker registry in your project (the successor to Container Registry). Why: Cloud Run and GKE pull images from somewhere — Artifact Registry is the secure, integrated place to push them.
Create a Docker repository in a region
gcloud artifacts repositories create my-repo \
--repository-format docker --location us-central1Configure Docker to authenticate to it, then push an image
gcloud auth configure-docker us-central1-docker.pkg.devdocker tag my-app:latest \
us-central1-docker.pkg.dev/learn-gcp-7f3k/my-repo/my-app:latestdocker push \
us-central1-docker.pkg.dev/learn-gcp-7f3k/my-repo/my-app:latestCloud Build can build your container image from source without a local Docker install, pushing the result straight to Artifact Registry. Why: reproducible builds in the cloud, and you can build even from a machine that has no Docker.
Build from the local Dockerfile and push to Artifact Registry
gcloud builds submit \
--tag us-central1-docker.pkg.dev/learn-gcp-7f3k/my-repo/my-app:latestCloud Run runs your container and handles HTTPS, scaling, and revisions for you. Why serverless: you give it an image and a port, and it scales from zero (you pay nothing when idle) up to many instances under load — no servers, no clusters.
Deploy the image as a public service
gcloud run deploy web \
--image us-central1-docker.pkg.dev/learn-gcp-7f3k/my-repo/my-app:latest \
--region us-central1 \
--allow-unauthenticated \
--port 80The deploy prints the service's https://...run.app URL.
Each deploy creates a "revision"; Cloud Run can split traffic between revisions and autoscale each. Why: set min instances to avoid cold starts, cap max to control cost, and roll out a new version to 10% of traffic before sending it everything.
Set autoscaling bounds and concurrency
gcloud run services update web --region us-central1 \
--min-instances 0 --max-instances 10 --concurrency 80Canary: send 10% of traffic to the latest revision
gcloud run services update-traffic web --region us-central1 \
--to-revisions LATEST=10Google Kubernetes Engine (GKE) runs the Kubernetes control plane for you; Autopilot mode even manages the nodes. Why choose it: if your team already uses Kubernetes tooling (kubectl, Helm, existing manifests) or needs its portability. Note: more moving parts than Cloud Run — reach for it when you specifically want Kubernetes.
Create an Autopilot cluster (Google manages the nodes)
gcloud container clusters create-auto learn-gke \
--region us-central1Fetch credentials so kubectl talks to it, then run normal Kubernetes
gcloud container clusters get-credentials learn-gke --region us-central1kubectl create deployment web --image=nginxkubectl get pods