Cloud Run for containerized services in GCP - Step-by-Step Execution

Process Flow - Cloud Run for containerized services

Write containerized app

↓

Build container image

↓

Push image to Container Registry

↓

Deploy image to Cloud Run

↓

Cloud Run creates service

↓

Service listens for requests

↓

Requests routed to container instances

↓

Scale instances up/down automatically

↓

Billing based on usage

This flow shows how you build a container, push it, deploy to Cloud Run, and how Cloud Run manages requests and scaling automatically.

Execution Sample

GCP

gcloud builds submit --tag gcr.io/my-project/my-app

gcloud run deploy my-service --image gcr.io/my-project/my-app --platform managed

# Service is live and scales automatically

This code builds a container image from your app and deploys it to Cloud Run, which then runs and scales your service.

Process Table

Step	Action	Input/Condition	Result/Output
1	Build container image	Source code + Dockerfile	Container image created
2	Push image	Container image	Image uploaded to Container Registry
3	Deploy to Cloud Run	Image URL	Cloud Run service created
4	Service starts	No requests yet	No container instances running
5	First request arrives	HTTP request	Cloud Run starts container instance
6	Handle request	Container instance running	Response sent to client
7	More requests	Increased traffic	Cloud Run scales instances up
8	Traffic drops	No requests	Cloud Run scales instances down to zero
9	Billing	Based on CPU, memory, and request time	Charges applied only when serving requests

💡 Execution stops when no requests remain and Cloud Run scales down to zero instances.

Status Tracker

Variable	Start	After Step 4	After Step 5	After Step 7	Final
Container Instances	0	0	1	3	0
Traffic Load	0	0	1 request	High requests	0
Billing Meter	0	0	Starts counting	Increases	Stops counting

Key Moments - 3 Insights

Why are there zero container instances before the first request?

Cloud Run scales to zero when idle to save resources, as shown in execution_table step 4.

How does Cloud Run know when to start more container instances?

It monitors incoming requests and scales up automatically, as seen in steps 5 and 7.

When does billing start and stop?

Billing starts when container instances handle requests (step 5) and stops when scaled down to zero (step 8).

Visual Quiz - 3 Questions

Look at the execution_table, how many container instances are running after step 7?

A 0

B 1

C 3

D 5

💡 Hint

Check the 'Container Instances' variable in variable_tracker after Step 7.

At which step does Cloud Run start the first container instance?

A Step 5

B Step 3

C Step 4

D Step 6

💡 Hint

Look at execution_table where the first request triggers container start.

If no requests come in, what happens to container instances according to the tables?

A They stay running

B They scale down to zero

C They increase

D They restart continuously

💡 Hint

See execution_table step 8 and variable_tracker final state.

Concept Snapshot

Cloud Run runs container images as services.
It automatically scales from zero to many instances.
You pay only when your service handles requests.
Deploy by pushing container image and running 'gcloud run deploy'.
Cloud Run manages infrastructure and scaling for you.

Full Transcript

Cloud Run lets you run containerized apps without managing servers. First, you build your app into a container image. Then you push this image to a container registry. Next, you deploy the image to Cloud Run, which creates a service. Initially, no container instances run until a request arrives. When a request comes, Cloud Run starts a container instance to handle it. If traffic grows, Cloud Run automatically adds more instances. When traffic stops, it scales down to zero to save resources. Billing is based on the time your containers run and handle requests. This makes Cloud Run efficient and cost-effective for running containerized services.

Practice

1. What is the main benefit of using Cloud Run for your containerized applications?

easy

A. It needs you to configure load balancers yourself.

B. It automatically scales your app based on traffic without managing servers.

C. It only works with virtual machines, not containers.

D. It requires you to manage virtual machines manually.

Solution

1. Step 1: Understand Cloud Run's serverless nature

   Cloud Run runs containers without requiring you to manage servers or infrastructure.

2. Step 2: Recognize automatic scaling feature

   Cloud Run automatically adjusts the number of container instances based on incoming traffic.

3. Final Answer:

   It automatically scales your app based on traffic without managing servers. -> Option B

4. Quick Check:

   Serverless + auto-scale = D [OK]

Hint: Cloud Run = serverless + auto scaling [OK]

Common Mistakes:

• Thinking you must manage servers manually
• Confusing Cloud Run with VM services
• Assuming manual load balancer setup is needed

2. Which of the following is the correct command to deploy a container image to Cloud Run?

easy

A. gcloud run deploy --image=gcr.io/my-project/my-image

B. gcloud compute instances create --image=gcr.io/my-project/my-image

C. kubectl run deploy --image=gcr.io/my-project/my-image

D. docker run deploy --image=gcr.io/my-project/my-image

Solution

1. Step 1: Identify the correct CLI tool for Cloud Run deployment

   The gcloud run deploy command is used to deploy container images to Cloud Run.

2. Step 2: Confirm the correct syntax

   The command includes the --image flag followed by the container image URL.

3. Final Answer:

   gcloud run deploy --image=gcr.io/my-project/my-image -> Option A

4. Quick Check:

   Cloud Run deploy uses gcloud run deploy [OK]

Hint: Use 'gcloud run deploy' to deploy containers [OK]

Common Mistakes:

• Using compute or kubectl commands instead of gcloud run
• Confusing docker run with Cloud Run deployment
• Missing the --image flag

3. Given this Cloud Run service configuration snippet, what will happen when traffic increases?

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
spec:
  template:
    spec:
      containers:
      - image: gcr.io/my-project/my-image
        resources:
          limits:
            cpu: 1
            memory: 512Mi

medium

A. The service will scale down to zero immediately.

B. Cloud Run will reject new requests once CPU limit is reached.

C. You must manually add more instances in the configuration.

D. Cloud Run will automatically create more container instances to handle the traffic.

Solution

1. Step 1: Understand Cloud Run's scaling behavior

   Cloud Run automatically scales container instances based on incoming traffic demand.

2. Step 2: Recognize resource limits do not prevent scaling

   Resource limits set max CPU/memory per instance but do not stop Cloud Run from adding instances.

3. Final Answer:

   Cloud Run will automatically create more container instances to handle the traffic. -> Option D

4. Quick Check:

   Auto scaling = more instances with traffic [OK]

Hint: Cloud Run auto scales instances, resource limits per instance [OK]

Common Mistakes:

• Thinking resource limits block scaling
• Assuming manual scaling is required
• Confusing scale down with scale up

4. You deployed a container to Cloud Run but get an error: Container failed to start. What is a common cause to check first?

medium

A. The container image does not expose the port Cloud Run expects.

B. You forgot to create a virtual machine instance.

C. Cloud Run requires a YAML file to deploy containers.

D. The container image must be in Docker Hub only.

Solution

1. Step 1: Understand Cloud Run port requirements

   Cloud Run expects the container to listen on port 8080 by default or the port set in the PORT environment variable.

2. Step 2: Check container image configuration

   If the container does not expose or listen on the expected port, it will fail to start properly.

3. Final Answer:

   The container image does not expose the port Cloud Run expects. -> Option A

4. Quick Check:

   Port mismatch causes start failure [OK]

Hint: Check container listens on port 8080 [OK]

Common Mistakes:

• Assuming VM instances are needed
• Thinking YAML is mandatory for deployment
• Believing container must be on Docker Hub

5. You want to deploy a containerized web app on Cloud Run that must handle sudden traffic spikes and also keep costs low when idle. Which setup is best?

hard

A. Deploy on Compute Engine with fixed VM instances.

B. Deploy on Cloud Run with minimum instances set to 5 to handle spikes.

C. Deploy on Cloud Run with autoscaling enabled and minimum instances set to zero.

D. Deploy on Cloud Run with manual scaling to 3 instances.

Solution

1. Step 1: Understand Cloud Run autoscaling and cost model

   Cloud Run automatically scales instances up and down based on traffic, and setting minimum instances to zero means no cost when idle.

2. Step 2: Compare options for cost and scalability

   Setting minimum instances above zero incurs cost even when idle; Compute Engine fixed VMs do not scale automatically; manual scaling requires more management.

3. Final Answer:

   Deploy on Cloud Run with autoscaling enabled and minimum instances set to zero. -> Option C

4. Quick Check:

   Auto scale + zero min instances = cost efficient [OK]

Hint: Zero min instances saves cost, autoscale handles spikes [OK]

Common Mistakes:

• Setting minimum instances above zero increases cost
• Using fixed VMs lacks automatic scaling
• Manual scaling requires extra management