Cloud Run resource model

Exam guide§2.1

Cloud Run has two ways to run a container: a service (handles requests) and a job (runs to completion, then quits). A service is the main resource; it is built from immutable revisions, and each revision scales out to container instances.

Services

A project runs services in one or more regions; each service holds immutable revisions, and the active revision scales out to as many container instances as the request load needs.

• A service is the main Cloud Run resource. It lives in one specific region and exposes a unique endpoint, automatically scaling the underlying infrastructure to handle incoming requests.
• Services are a regional resource: container instances can start in any zone in the region, and high-traffic services are spread across multiple zones for redundancy - if one zone has issues, the service keeps serving. See Regions & Zones.
• One project can run many services in different regions.

A service gives you a reliable HTTPS endpoint; your only job is to listen on a TCP port and handle HTTP requests. The Cloud Run Proxy sits in front of your container and:

Cloud Run gives you a managed HTTPS endpoint: the Cloud Run Proxy terminates TLS on a *.run.app (or custom) domain and forwards plain HTTP to your container instance.

• Provisions a valid TLS certificate and HTTPS endpoint on a unique subdomain of *.run.app (configure a custom domain if needed).
• Terminates TLS - handles incoming requests, decrypts them, and forwards plain HTTP to your container instance.
• Supports WebSockets, HTTP/2, and gRPC with no extra config. gRPC uses protocol buffers (up to ~7x faster than REST) and is a good fit for internal microservices.

Revisions

• Each deployment of a container image creates a new revision = a specific container image plus its config (environment variables, memory limits, concurrency value).
• Revisions are immutable: once created, a revision is never modified - deploying a new image creates a new revision. Requests are routed to the latest healthy revision as soon as possible.
• Each revision receiving requests is autoscaled with the number of container instances needed. A single instance can serve many requests at once; the concurrency setting caps how many run in parallel per instance.

See Revisions & traffic splitting for splitting traffic across revisions and Autoscaling & concurrency for scaling controls.

Jobs

Instead of serving requests, a job runs code that does work and then quits - batch processing, scheduled tasks, migrations.

A job runs in one region and consists of one or more independent tasks run in parallel; each task runs one container instance, and all tasks must succeed for the execution to succeed.

• Each job lives in a specific region.
• A job consists of one or more independent tasks run in parallel in a given job execution; each task runs one container instance.
• Running a job creates a job execution in which all tasks start. All tasks must complete successfully for the execution to succeed.
• A job that runs multiple identical tasks in parallel is an Array job - e.g. process many Cloud Storage files at once, one per task. Run a job from gcloud, on a schedule, or as a workflow step.

⚠GotchaHandling task failures

A job execution fails if any task fails. To make tasks resilient, set a timeout per task and a number of retries - a task is only considered failed after its retries are exhausted.

Recap

≡FactsCloud Run resource model

• Service = the main resource; regional, one unique endpoint, autoscales. A project can run many services across regions.
• Revision = an immutable snapshot of a container image + its config (env vars, memory, concurrency). Each deploy makes a new one.
• Container instance = handles requests for a revision; a revision autoscales across as many instances as the load needs.
• Job = run-to-completion work; one or more parallel tasks, each one container instance; a job execution must have all tasks succeed.