GKE vs Cloud Run decision in GCP - CLI Comparison

Introduction

Choosing between GKE and Cloud Run helps you decide how to run your applications in the cloud. GKE manages containers with more control, while Cloud Run runs containers without managing servers.

When you want full control over container orchestration and scaling for complex apps, use GKE.

When you want to deploy simple containerized apps quickly without managing infrastructure, use Cloud Run.

When your app needs to run continuously with custom networking, GKE is better.

When your app can scale down to zero and only run on demand, Cloud Run saves cost.

When you want to integrate with Kubernetes tools and ecosystem, choose GKE.

Commands

This command creates a GKE cluster named example-cluster with 3 nodes in the us-central1-a zone. It sets up the environment to run containerized apps with Kubernetes.

Terminal

gcloud container clusters create example-cluster --zone us-central1-a --num-nodes 3

Expected Output

Creating cluster example-cluster in us-central1-a...



Created [https://container.googleapis.com/v1/projects/my-project/zones/us-central1-a/clusters/example-cluster].



To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/us-central1-a/example-cluster?project=my-project



kubeconfig entry generated for example-cluster.



NAME              LOCATION       MASTER_VERSION  MASTER_IP       MACHINE_TYPE   NODE_VERSION  NUM_NODES  STATUS

example-cluster   us-central1-a  1.26.8-gke.1200 34.68.123.45    e2-medium      1.26.8-gke.1200  3          RUNNING

→

--num-nodes - Sets the number of nodes in the cluster

→

--zone - Specifies the zone where the cluster is created

This command deploys a containerized app named example-app to the GKE cluster using the specified container image and port.

Terminal

kubectl run example-app --image=gcr.io/my-project/example-app:latest --port=8080

Expected Output

pod/example-app created

→

--image - Specifies the container image to run

→

--port - Exposes the container port

This command deploys the container image to Cloud Run as a managed service named example-service in the us-central1 region, allowing public access.

Terminal

gcloud run deploy example-service --image=gcr.io/my-project/example-app:latest --region us-central1 --platform managed --allow-unauthenticated

Expected Output

Deploying container to Cloud Run service [example-service] in project [my-project] region [us-central1]



✓ Creating Revision...

✓ Routing traffic...



Service [example-service] revision [example-service-00001-abc] has been deployed and is serving 100 percent of traffic.



Service URL: https://example-service-abc-uc.a.run.app

→

--platform managed - Deploys to fully managed Cloud Run

→

--allow-unauthenticated - Allows public access to the service

This command lists all Cloud Run services in the us-central1 region to verify the deployment.

Terminal

gcloud run services list --region us-central1

Expected Output

SERVICE         REGION      URL

example-service us-central1 https://example-service-abc-uc.a.run.app

→

--region - Specifies the region to list services

Key Concept

If you remember nothing else, remember: GKE gives you full control and complexity for container orchestration, while Cloud Run offers simple, serverless container deployment with automatic scaling.

Common Mistakes

Trying to deploy a container to Cloud Run without specifying the region or platform flags

Cloud Run needs region and platform info to know where and how to deploy the service

Always include --region and --platform managed flags when deploying to Cloud Run

Creating a GKE cluster with too few nodes for the app's resource needs

The app may not have enough resources to run properly, causing failures or slow performance

Estimate resource needs and create the cluster with enough nodes or scale nodes later

Not exposing the container port when deploying to GKE

Kubernetes won't know which port the app listens on, so traffic won't reach the app

Use the --port flag with kubectl run to expose the correct container port

Summary

Use 'gcloud container clusters create' to set up a GKE cluster for full container orchestration control.

Deploy containers to GKE with 'kubectl run' specifying image and port for app access.

Use 'gcloud run deploy' with region and platform flags to deploy containers serverlessly on Cloud Run.

List Cloud Run services with 'gcloud run services list' to verify deployments.

Practice

1. Which service should you choose if you want to avoid managing servers and focus only on deploying containers?

easy

A. Compute Engine

B. Google Kubernetes Engine (GKE)

C. App Engine Standard

D. Cloud Run

Solution

1. Step 1: Understand server management needs

   Cloud Run is serverless, so it handles server management automatically.

2. Step 2: Compare with GKE

   GKE requires managing Kubernetes clusters and nodes, which means more management effort.

3. Final Answer:

   Cloud Run -> Option D

4. Quick Check:

   Serverless = Cloud Run [OK]

Hint: Serverless means no server management needed [OK]

Common Mistakes:

• Confusing GKE as serverless
• Choosing Compute Engine which is VM-based
• Thinking App Engine Standard is container-focused

2. Which of the following is the correct way to deploy a container image to Cloud Run using gcloud CLI?

easy

A. gcloud run deploy SERVICE --image IMAGE_URL --platform managed

B. gcloud container clusters create SERVICE --image IMAGE_URL

C. gcloud compute instances create SERVICE --image IMAGE_URL

D. gcloud app deploy --image IMAGE_URL

Solution

1. Step 1: Identify Cloud Run deployment command

   The correct command uses gcloud run deploy with the service name and image URL.

2. Step 2: Eliminate other commands

   Other options relate to Kubernetes clusters, VM instances, or App Engine, which are incorrect for Cloud Run.

3. Final Answer:

   gcloud run deploy SERVICE --image IMAGE_URL --platform managed -> Option A

4. Quick Check:

   Cloud Run deploy uses gcloud run deploy [OK]

Hint: Cloud Run deploy always uses 'gcloud run deploy' [OK]

Common Mistakes:

• Using 'gcloud container clusters create' for Cloud Run
• Confusing Compute Engine commands with Cloud Run
• Using App Engine deploy command for Cloud Run

3. You deploy a containerized app to GKE with autoscaling enabled. What happens when traffic suddenly spikes?

medium

A. Cloud Run automatically pauses the service until traffic decreases.

B. GKE automatically adds more pods to handle the increased load.

C. GKE shuts down pods to save resources during high traffic.

D. Cloud Run requires manual scaling to handle traffic spikes.

Solution

1. Step 1: Understand GKE autoscaling behavior

   GKE uses Horizontal Pod Autoscaler to add pods automatically when traffic increases.

2. Step 2: Compare with Cloud Run behavior

   Cloud Run scales automatically but does not pause services; manual scaling is not required.

3. Final Answer:

   GKE automatically adds more pods to handle the increased load. -> Option B

4. Quick Check:

   GKE autoscaling adds pods on traffic spike [OK]

Hint: GKE autoscaling adds pods automatically on load [OK]

Common Mistakes:

• Thinking Cloud Run pauses services on high traffic
• Believing GKE shuts down pods during spikes
• Assuming Cloud Run needs manual scaling

4. You tried deploying a container to Cloud Run but got an error about missing CPU allocation. What is the likely cause?

medium

A. You did not specify the CPU limit in the deployment command.

B. Cloud Run does not support containers with CPU requirements.

C. You deployed to GKE instead of Cloud Run by mistake.

D. The container image is not compatible with Cloud Run.

Solution

1. Step 1: Understand Cloud Run CPU allocation

   Cloud Run requires CPU allocation settings; missing these can cause errors.

2. Step 2: Check deployment command

   If CPU limits are not specified, Cloud Run deployment fails with CPU allocation errors.

3. Final Answer:

   You did not specify the CPU limit in the deployment command. -> Option A

4. Quick Check:

   Missing CPU limit causes deployment error [OK]

Hint: Always specify CPU limits when deploying to Cloud Run [OK]

Common Mistakes:

• Assuming Cloud Run ignores CPU settings
• Confusing GKE deployment with Cloud Run
• Blaming container image compatibility without checking CPU

5. Your team needs to run a complex microservices app with custom networking, persistent storage, and fine-grained control over scaling. Which service is best?

hard

A. Cloud Run because it handles all scaling automatically

B. Cloud Functions because it runs code without servers

C. GKE because it supports complex orchestration and custom setups

D. App Engine because it is fully managed and simple

Solution

1. Step 1: Analyze app requirements

   The app needs complex orchestration, custom networking, persistent storage, and detailed scaling control.

2. Step 2: Match requirements to services

   GKE supports Kubernetes features for complex setups, while Cloud Run is simpler and serverless but less customizable.

3. Final Answer:

   GKE because it supports complex orchestration and custom setups -> Option C

4. Quick Check:

   Complex control needs = GKE [OK]

Hint: Complex apps with custom needs use GKE [OK]

Common Mistakes:

• Choosing Cloud Run for complex networking
• Confusing App Engine with container orchestration
• Using Cloud Functions for microservices orchestration