Cloud Run (GCP) Pocket Book — Uplatz
Extended 15+ pages • 70+ detailed flashcards • Wide layout • Advanced deployment & serverless best practices
1) What is Cloud Run?
Cloud Run is a fully managed serverless compute platform that executes stateless containers. It scales automatically, bills per-request, and integrates seamlessly with the Google Cloud ecosystem. Developers deploy containers without managing servers.
2) Serverless vs Containers
Cloud Run bridges FaaS and CaaS. Unlike Cloud Functions (FaaS), you can deploy full containers. Unlike GKE (CaaS), you don’t manage clusters. It balances flexibility and simplicity.
3) Supported Runtimes
Any language/runtime packaged in a container works: Node.js, Python, Go, Java, .NET, Ruby, Rust, etc. Cloud Run abstracts runtime, focusing on HTTP entrypoints.
4) VPC Connectivity
Cloud Run connects to VPC networks via Serverless VPC Access connectors. This allows private access to Cloud SQL, Redis, or internal APIs without public IPs.
5) Authentication
Cloud Run supports multiple auth modes: IAM (service-to-service), IAP (user-level), and JWT/OIDC. By default, services are public, but you can restrict to authenticated callers.
6) Ingress Control
Configure ingress to allow only internal traffic, only VPC, or internet + auth. Combine with Cloud Armor for WAF protection.
7) Concurrency
Each Cloud Run instance can process multiple requests concurrently. Default is 80, configurable to balance throughput and latency. Higher concurrency saves cost but may increase response times.
8) Min & Max Instances
Set minimum instances for low latency (avoid cold starts). Set maximum instances to cap spend. Balance responsiveness with budget.
9) CPU Allocation
Choose between CPU only during requests (cheaper) or always allocated (good for background tasks). Configure via flags during deployment.
10) Deploy with gcloud
Deploy from source or prebuilt images. Cloud Build builds and pushes to Artifact Registry. Use `gcloud run deploy` to release services.
11) GitHub Actions
Automate deployments with GitHub Actions. Build Docker image, push to Artifact Registry, deploy to Cloud Run using GCP credentials.
12) Canary Deployments
Split traffic between revisions. Start with 5% → 50% → 100%. Useful for safe rollouts and A/B testing.
13) Logging
Cloud Run integrates with Cloud Logging. Logs per request with trace IDs. Use structured JSON logs for analytics and dashboards.
14) Metrics
Cloud Monitoring tracks request counts, latency, CPU/memory usage, error rates. Define SLOs (e.g., 99% requests under 400ms) and set alerts.
15) Tracing
Use Cloud Trace for distributed tracing across services. Instrument code with OpenTelemetry for end-to-end performance analysis.
16) Region Selection
Choose regions closer to users for performance and lower egress costs. Multi-region deployments improve latency and availability.
17) Instance Sizing
Pick CPU/memory tier per workload. Avoid over-provisioning to cut costs. Start small, scale with demand.
18) Scale-to-Zero
Cloud Run scales down idle services to zero, eliminating idle cost. Great for bursty workloads. For always-on apps, set min instances instead.
19) Event-driven Apps
Integrate with Pub/Sub, Cloud Storage, or Firestore triggers using Eventarc. Build reactive architectures with minimal ops overhead.
20) ML Model Serving
Package TensorFlow/PyTorch models in containers and deploy via Cloud Run for scalable inference. Use GPU-enabled GKE if GPU required.
21) gRPC Microservices
Cloud Run supports gRPC services. Define protobuf contracts, deploy services, and enable HTTP/2 for efficient inter-service communication.
22) Stateless Design
Cloud Run requires stateless containers. Store state in Cloud SQL, Firestore, or Memorystore. Avoid in-memory state for multi-instance consistency.
23) Secrets Management
Use Secret Manager for credentials. Don’t bake secrets into images. Mount secrets securely at runtime.
24) Avoid Long Tasks
Requests max 60 minutes. Offload long-running jobs to Cloud Run Jobs, Dataflow, or GKE. Keep services responsive.
25) vs AWS Fargate
Fargate provides container orchestration with ECS/EKS. Cloud Run is simpler, fully managed, and auto-scales to zero. Fargate offers more control but more ops overhead.
26) vs Azure Container Apps
Azure Container Apps and Cloud Run are similar: serverless containers, event-driven, autoscaling. Cloud Run integrates tightly with GCP ecosystem.
27) vs Knative on GKE
Cloud Run is built on Knative but fully managed. Knative on GKE offers flexibility with ops responsibility. Choose Cloud Run for simplicity, Knative for control.
28) Interview Q&A (20+)
1) What is Cloud Run’s biggest advantage? → Serverless, pay-per-use, container flexibility.
2) How does Cloud Run handle scaling? → Autoscaling per request load, scales to zero.
3) Difference between Cloud Run Service and Job? → Service exposes HTTP endpoint, Job runs batch/cron tasks.
4) How to secure Cloud Run? → IAM auth, ingress restrictions, Cloud Armor, Secret Manager.
5) Cold start mitigation? → Min instances, region choice, concurrency tuning.
6) CI/CD integration? → Cloud Build, GitHub Actions, Artifact Registry.
7) What’s max request duration? → 60 minutes.
8) Can Cloud Run handle gRPC? → Yes, with HTTP/2 support.
9) Stateless design rule? → Yes, state externalized to DBs/services.
10) When not to use Cloud Run? → For stateful apps, GPU-heavy workloads, long tasks > 60min.