GCP Core Services Hands-on Tutorial: Compute Engine, Cloud Run, GKE Complete Operations Guide

Want to run your programs on GCP but don't know which service to use?

Compute Engine, Cloud Run, GKE... they all sound similar—what's the difference?

This article will walk you through actually operating GCP's three major compute services. From creating your first VM, to deploying Serverless containers, to managing Kubernetes clusters—step-by-step to get you started.

Want to understand GCP's overall architecture first? Please refer to "GCP Complete Guide: From Beginner Concepts to Enterprise Practice."

---

GCP Compute Service Selection Guide

Before getting hands-on, understand the differences between these three services.

VM vs Container vs Serverless Comparison

Service	Type	What You Manage	Suitable Scenarios
Compute Engine	VM	OS, Runtime, Application	Need full control, special software requirements
GKE	Container Orchestration	Containers, Pods, Deployments	Large-scale microservices, complex orchestration
Cloud Run	Serverless Container	Container image	API services, Web apps, quick deployment

Simple Memory Aid:

• Need full control → Compute Engine
• Want to save effort and money → Cloud Run
• Need large-scale management → GKE

Choosing Services Based on Workload

Choose Compute Engine when:

• Need to install specific software (like licensed software)
• Need GPU for machine learning training
• Need Windows Server
• Traditional monolithic applications
• Need fixed IP services

Choose Cloud Run when:

• HTTP services (API, Web)
• Unstable traffic (sometimes busy, sometimes idle)
• Want automatic scaling
• Want per-request billing (no traffic = no charge)
• Quick deployment and iteration

Choose GKE when:

• Many microservices need orchestration
• Need fine-grained network control
• Have on-premise K8s experience to migrate to cloud
• Need stateful services
• Enterprise container platform requirements

Service Combinations and Hybrid Architecture

In practice, many projects mix these services:

Common Combo 1: Frontend/Backend Separation

• Frontend: Cloud Run (static site, SSR)
• Backend API: Cloud Run
• Background tasks: Compute Engine

Common Combo 2: Microservices Architecture

• Main services: GKE
• Lightweight webhooks: Cloud Run
• Batch processing: Compute Engine (Spot VM)

Common Combo 3: ML Workflow

• Model training: Compute Engine (GPU)
• Model serving: Cloud Run or GKE
• Data processing: Dataflow

---

Compute Engine (VM) Hands-on Tutorial

Compute Engine is GCP's most basic compute service. Like renting a computer in the cloud.

Creating Your First VM Instance

Method 1: Using Cloud Console (Web Interface)

1. Go to Cloud Console → Compute Engine → VM instances

2. Click "Create Instance"

3. Set basic info:

   • Name: my-first-vm
   • Region: asia-east1 (Taiwan)
   • Zone: asia-east1-b

4. Select machine type (detailed next section)

5. Select boot disk (detailed next section)

6. Set firewall:

   • Check "Allow HTTP traffic" (if running web)
   • Check "Allow HTTPS traffic"

7. Click "Create"

Method 2: Using gcloud CLI

gcloud compute instances create my-first-vm \
  --zone=asia-east1-b \
  --machine-type=e2-medium \
  --image-family=debian-11 \
  --image-project=debian-cloud \
  --boot-disk-size=20GB \
  --tags=http-server,https-server

CLI benefits: can be scripted for easy repetition and version control.

Machine Types and Spec Selection

GCP has many machine series—choosing wrong wastes money.

Machine Series Comparison:

Series	Features	Use Cases	Price
E2	Cheapest, shared CPU	Dev/test, small services	💰
N2	Balanced, dedicated CPU	General production	💰💰
N2D	AMD processor	High cost-performance needs	💰💰
C2	Compute optimized	CPU-intensive work	💰💰💰
M2	Memory optimized	Large databases, SAP	💰💰💰💰
A2	GPU optimized	ML training, rendering	💰💰💰💰💰

How to Choose?

• Dev/test environments → e2-micro (free) or e2-small
• Small web services → e2-medium
• General production → n2-standard-2 minimum
• Databases → n2-highmem-*
• Batch computing → c2-standard-*

Custom Machine Type:

If standard specs don't fit your needs, customize vCPU and memory:

gcloud compute instances create custom-vm \
  --custom-cpu=6 \
  --custom-memory=12GB

Boot Disk and Image Settings

Image Selection:

Type	Options	Cost
Public images	Debian, Ubuntu, CentOS	Free
Premium images	Windows, RHEL, SUSE	Extra charge
Custom images	Your own	Storage cost

Disk Types:

Type	IOPS	Use Cases	Price
pd-standard (HDD)	Low	Backup, cold data	$0.04/GB
pd-balanced (SSD)	Medium	General purpose	$0.10/GB
pd-ssd (SSD)	High	Databases, high I/O	$0.17/GB
pd-extreme (SSD)	Very high	High-performance databases	$0.125/GB

Recommendations:

• Dev/test → pd-balanced, 20-50GB
• General production → pd-balanced, 50-100GB
• Databases → pd-ssd or pd-extreme

Network and Firewall Configuration

Default Network Settings:

Each VM gets by default:

• Internal IP (for VPC internal use)
• External IP (for external connections, optional)

Firewall Rule Setup:

# Allow HTTP
gcloud compute firewall-rules create allow-http \
  --allow=tcp:80 \
  --target-tags=http-server

# Allow HTTPS
gcloud compute firewall-rules create allow-https \
  --allow=tcp:443 \
  --target-tags=https-server

# Allow SSH from specific IP
gcloud compute firewall-rules create allow-ssh-from-office \
  --allow=tcp:22 \
  --source-ranges=203.0.113.0/24

Security Recommendations:

• Don't open 0.0.0.0/0 for SSH (whole world can connect)
• Use IAP (Identity-Aware Proxy) instead of direct SSH
• Regularly review unnecessary firewall rules

SSH Connection and Basic Management

Connection Methods:

1. Cloud Console Built-in SSH

Simplest way—click and connect.

2. gcloud CLI

gcloud compute ssh my-first-vm --zone=asia-east1-b

3. Standard SSH Client

# First set up SSH Key
gcloud compute config-ssh

# Then use regular SSH
ssh my-first-vm.asia-east1-b.your-project

Common Management Commands:

# List all VMs
gcloud compute instances list

# Stop VM (stops vCPU billing, but disk still charges)
gcloud compute instances stop my-first-vm --zone=asia-east1-b

# Start VM
gcloud compute instances start my-first-vm --zone=asia-east1-b

# Delete VM
gcloud compute instances delete my-first-vm --zone=asia-east1-b

For cost details, see "GCP Pricing and Cost Calculation Complete Guide."

---

Cloud Run Container Deployment Tutorial

Cloud Run is GCP's Serverless container service. Just give it a container—everything else is handled.

How Cloud Run Works

Core Concepts:

1. You package a container image
2. Deploy to Cloud Run
3. Cloud Run automatically handles:
   • Starting containers
   • Load balancing
   • Auto-scaling (0 to N instances)
   • HTTPS certificates
   • Custom domains

Billing Method:

• Only charged when processing requests
• Can scale to 0 instances with no requests
• Billed by CPU time and memory

Limitations:

• Must be HTTP service (listening on PORT environment variable)
• Request timeout max 60 minutes
• Single request max 32GB memory

Deploying Services from Container Registry

Step 1: Prepare Your Application

Using Node.js as example, create index.js:

const express = require('express');
const app = express();
const port = process.env.PORT || 8080;

app.get('/', (req, res) => {
  res.send('Hello from Cloud Run!');
});

app.listen(port, () => {
  console.log(`Server running on port ${port}`);
});

Step 2: Create Dockerfile

FROM node:18-slim
WORKDIR /app
COPY package*.json ./
RUN npm install --production
COPY . .
CMD ["node", "index.js"]

Step 3: Build and Push to Artifact Registry

# Configure Docker authentication
gcloud auth configure-docker asia-east1-docker.pkg.dev

# Build image
docker build -t asia-east1-docker.pkg.dev/PROJECT_ID/REPO_NAME/my-app:v1 .

# Push
docker push asia-east1-docker.pkg.dev/PROJECT_ID/REPO_NAME/my-app:v1

Step 4: Deploy to Cloud Run

gcloud run deploy my-service \
  --image=asia-east1-docker.pkg.dev/PROJECT_ID/REPO_NAME/my-app:v1 \
  --region=asia-east1 \
  --platform=managed \
  --allow-unauthenticated

After deployment, you'll get an HTTPS URL.

Auto-Scaling and Traffic Management

Auto-Scaling Settings:

gcloud run deploy my-service \
  --min-instances=0 \    # Min instances (0 = can scale to 0)
  --max-instances=100 \  # Max instances
  --concurrency=80       # Max concurrent requests per instance

Traffic Split (Multi-Version Deployment):

# Deploy new version without traffic
gcloud run deploy my-service \
  --image=my-app:v2 \
  --no-traffic

# Gradually shift traffic
gcloud run services update-traffic my-service \
  --to-revisions=my-service-v2=50,my-service-v1=50

# All traffic to new version
gcloud run services update-traffic my-service \
  --to-latest

Custom Domain and HTTPS Setup

Setting Up Custom Domain:

1. Go to Cloud Run → Select service → Manage Custom Domains
2. Click "Add Mapping"
3. Enter your domain (e.g., api.example.com)
4. Follow instructions to set up DNS

DNS Setup:

• Add CNAME record at your DNS provider
• Point to target provided by Cloud Run

HTTPS:

• Cloud Run automatically provides SSL certificate
• Supports auto-renewal
• No additional setup needed

Environment Variables and Secret Management

Setting Environment Variables:

gcloud run deploy my-service \
  --set-env-vars=DATABASE_URL=xxx,API_KEY=yyy

Using Secret Manager:

# First create Secret
echo -n "my-secret-value" | gcloud secrets create my-secret --data-file=-

# Mount Secret during deployment
gcloud run deploy my-service \
  --set-secrets=API_KEY=my-secret:latest

Benefits:

• Secrets don't appear in deploy commands or env var lists
• Can set IAM permissions to control access
• Supports version management

---

GKE (Google Kubernetes Engine) Introduction

If your service scale is large and complex enough, GKE is the most powerful choice.

Creating and Configuring GKE Clusters

Using Console:

1. Go to GKE → Create Cluster
2. Choose mode: Autopilot or Standard (explained next section)
3. Set name and region
4. Configure node pools (Standard mode)
5. Create

Using gcloud:

# Autopilot mode
gcloud container clusters create-auto my-cluster \
  --region=asia-east1

# Standard mode
gcloud container clusters create my-cluster \
  --zone=asia-east1-b \
  --num-nodes=3 \
  --machine-type=e2-medium

Get Cluster Credentials:

gcloud container clusters get-credentials my-cluster \
  --region=asia-east1

After running, you can use kubectl to operate the cluster.

Autopilot vs Standard Mode Comparison

Item	Autopilot	Standard
Node Management	Google manages	You manage
Billing Unit	Pod resources	Node resources
Configuration Flexibility	Less	Fully customizable
Security	Hardened by default	Self-configured
Complexity	Low	High
Suitable For	Most users	Need special configurations

Recommendations:

• Just starting with GKE → Autopilot
• Need GPU, special node configs → Standard
• Want to save management effort → Autopilot
• Have dedicated K8s team → Standard

Workload Deployment Basics

Deploying a Simple Application:

Create deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: asia-east1-docker.pkg.dev/PROJECT_ID/REPO/my-app:v1
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"

Deploy:

kubectl apply -f deployment.yaml

Common Commands:

# View Deployments
kubectl get deployments

# View Pods
kubectl get pods

# View Pod logs
kubectl logs <pod-name>

# Enter Pod
kubectl exec -it <pod-name> -- /bin/sh

# Scale replicas
kubectl scale deployment my-app --replicas=5

Service Exposure and Load Balancing

Create Service:

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080

Service Types:

Type	Purpose	External Access
ClusterIP	Cluster internal communication	No
NodePort	Open node port	Yes (rarely used)
LoadBalancer	GCP load balancer	Yes

Ingress (Advanced):

To manage routing for multiple services:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

---

Storage Service Integration

Compute services often need storage.

Cloud Storage Mounting and Usage

Accessing Cloud Storage from VM:

# Install gsutil (usually pre-installed)
# Upload file
gsutil cp local-file.txt gs://my-bucket/

# Download file
gsutil cp gs://my-bucket/file.txt ./

# Sync folder
gsutil rsync -r ./local-folder gs://my-bucket/folder

Accessing from Cloud Run:

const {Storage} = require('@google-cloud/storage');
const storage = new Storage();

async function uploadFile() {
  await storage.bucket('my-bucket').upload('local-file.txt');
}

Persistent Disk Configuration

Add Disk to VM:

# Create disk
gcloud compute disks create my-disk \
  --size=100GB \
  --type=pd-ssd \
  --zone=asia-east1-b

# Attach to VM
gcloud compute instances attach-disk my-vm \
  --disk=my-disk \
  --zone=asia-east1-b

Mount Inside VM:

# After SSH into VM
sudo mkfs.ext4 -m 0 -F /dev/sdb
sudo mkdir /mnt/data
sudo mount /dev/sdb /mnt/data

# Set auto-mount on boot
echo '/dev/sdb /mnt/data ext4 defaults 0 0' | sudo tee -a /etc/fstab

Filestore (NFS) Use Cases

Suitable Scenarios:

• Multiple VMs need shared files
• Need POSIX filesystem semantics
• Traditional apps needing NFS

Create Filestore:

gcloud filestore instances create my-filestore \
  --zone=asia-east1-b \
  --tier=BASIC_HDD \
  --file-share=name=vol1,capacity=1TB \
  --network=name=default

Mount on VM:

sudo apt-get install nfs-common
sudo mkdir /mnt/filestore
sudo mount 10.0.0.2:/vol1 /mnt/filestore

---

Common Issues and Best Practices

Practical problems and solutions commonly encountered.

Performance Tuning Recommendations

Compute Engine:

• Choose correct machine type (don't over-provision)
• Use SSD instead of HDD for databases
• Consider Local SSD for temporary storage
• Enable Preemptible/Spot VM for batch jobs

Cloud Run:

• Set appropriate concurrency (default 80)
• Use min-instances to avoid cold starts
• Container images should be small (use Alpine, Distroless)
• Use CPU boost feature

GKE:

• Set Resource Requests and Limits
• Use HPA (Horizontal Pod Autoscaler)
• Consider Node Auto-provisioning
• Use Pod Disruption Budget

Cost Control Techniques

Compute Engine:

• Use Spot VMs for dev environments
• Use Scheduling to auto-shutdown after hours
• Regularly clean unused disks and snapshots

Cloud Run:

• Set min-instances to 0 (allow scale to 0)
• Don't set max-instances too high when not needed
• Optimize container startup time

GKE:

• Autopilot mode bills more precisely by Pod
• Use Cluster Autoscaler
• Consider Spot Node Pool for interruptible work

Monitoring and Logging Setup

Cloud Monitoring:

All GCP service metrics automatically go to Cloud Monitoring.

Key Metrics:

• CPU usage
• Memory usage
• Network traffic
• Latency and error rates

Cloud Logging:

# View VM logs
gcloud logging read "resource.type=gce_instance"

# View Cloud Run logs
gcloud logging read "resource.type=cloud_run_revision"

# View GKE logs
gcloud logging read "resource.type=k8s_container"

Setting Up Alerts:

1. Go to Cloud Monitoring → Alerting
2. Create Alert Policy
3. Select metrics and conditions
4. Set notification channels (Email, Slack, PagerDuty)

For security settings, see "GCP Security and Cloud Armor Protection Complete Guide."

---

Need a Second Opinion on Architecture Design?

Good architecture can save several times the operational costs.

Schedule Architecture Consultation and let us review your cloud architecture together.

CloudInsight's Architecture Consulting Services:

• Existing Architecture Assessment: Find performance bottlenecks and cost waste
• Migration Planning: Complete planning from on-premise to cloud
• Best Practice Recommendations: Recommend optimal service combinations for your needs
• Proof of Concept (POC): Help you quickly validate architecture feasibility

---

Conclusion: Building Your GCP Compute Architecture

After this tutorial, you should know how to choose and use GCP's compute services.

Quick Recap:

Need	Choice	Reason
Need full control	Compute Engine	Can install any software
Want it easy	Cloud Run	Don't manage infrastructure
Large-scale microservices	GKE	Powerful orchestration
Unstable traffic	Cloud Run	Can scale to 0
Need GPU	Compute Engine	Supports NVIDIA GPU
Complex network needs	GKE	Fine-grained network control

Next Step Recommendations:

1. For new projects, start with Cloud Run
2. If need full control, use Compute Engine
3. If services exceed 10, consider GKE
4. Mixed use is normal—don't force everything into one type

Hands-on is the best way to learn. Open a test project and run through all the examples in this tutorial!

FAQ

Q1: Cloud Run vs Compute Engine vs GKE — what's the real decision criteria?

Decide based on control requirements and operational overhead tolerance. (1) Cloud Run — fully managed, pay-per-use, scale-to-zero. Fits: stateless APIs, microservices, sporadic traffic. Skip it if: need persistent storage on-instance, long-running processes (>60 min), or complex networking. (2) Compute Engine — full VM control, like EC2. Fits: legacy apps, specific OS requirements, custom hardware (GPU, TPU), sticky-session apps. Skip it if: just need to run stateless containers (Cloud Run is 10x easier to manage). (3) GKE — managed Kubernetes. Fits: 10+ microservices, need advanced orchestration, multi-tenant clusters, or already K8s-experienced team. Skip it if: <5 services (complexity exceeds value), team doesn't know K8s well (learning curve 3–6 months). Real-world pattern: start with Cloud Run for new apps, migrate to GKE only when microservice count grows; use Compute Engine only for legacy or special-purpose workloads. Don't overengineer — Cloud Run handles 80% of use cases.

Q2: Cloud SQL vs Firestore vs BigQuery — which database for which scenario?

Each serves a distinct database pattern. (1) Cloud SQL (managed MySQL/PostgreSQL) — relational, OLTP. Fits: traditional web apps, need ACID transactions, existing SQL expertise, <100TB data. Use when: you'd pick MySQL/PostgreSQL anyway. (2) Firestore (managed NoSQL document) — flexible schema, real-time sync. Fits: mobile apps, real-time collaboration, rapid iteration, <10M documents per collection. Skip when: need complex queries or joins (painful with document DB). (3) BigQuery (analytics warehouse) — columnar, petabyte-scale. Fits: data analytics, dashboards, ML training data prep, historical logs. Not for OLTP — writes are expensive, latency is high (seconds not milliseconds). (4) Spanner (global distributed SQL) — ACID + horizontal scaling. Fits: finance, global apps needing strong consistency. Expensive, use only when justified. Common mistake: forcing Firestore for relational data or BigQuery for real-time apps. Match database type to workload type first, optimize later.

Q3: What are the hidden networking costs in GCP that catch people off guard?

Four expensive surprises. (1) NAT Gateway egress — Cloud NAT charges $0.045/hour + $0.045/GB processed. A busy VPC can rack up $500+/month just on NAT. Mitigate by using VPC Endpoints (Private Google Access) for GCS/BigQuery traffic. (2) Cross-region traffic — same-continent cross-region is $0.02/GB; cross-continent is $0.08/GB. A multi-region app unaware of this can cost thousands. Mitigate by keeping data and compute in the same region when possible. (3) Internet egress — $0.12/GB to most regions; a CDN miss on a 1TB download costs $120. Mitigate with Cloud CDN (caches at edge, reducing origin egress). (4) Load Balancer forwarding rules — each external HTTP(S) LB has a fixed $18/month cost plus $0.025/GB processed. Many small services each with their own LB adds up fast; consolidate via path-based routing on one LB. General tip: enable VPC Flow Logs for a week and analyze the data — you'll often find surprising traffic patterns driving costs.

Q4: How do we handle GCP service account keys securely?

Prefer Workload Identity over downloaded keys wherever possible. (1) Avoid downloading SA keys if you can — downloaded .json keys are long-lived credentials that are easily leaked (GitHub, Slack, Dropbox). Once leaked, attackers can act as the service account indefinitely until you manually rotate. (2) Use Workload Identity instead — (A) GKE: attach Kubernetes ServiceAccount to GCP SA, pods authenticate automatically without keys; (B) Cloud Run / Cloud Functions: run as a SA directly, no key needed; (C) External workloads (AWS, on-prem): use Workload Identity Federation, SA impersonation via OIDC/SAML. (3) If you must use keys — (A) rotate every 90 days; (B) store in Secret Manager, never in source code; (C) enable org-level policy to disable SA key creation for non-essential accounts; (D) audit with Cloud Asset Inventory. (4) Monitor for leaks — GitHub has automatic scanning that notifies you and automatically disables leaked GCP keys, but don't rely on it alone. Use GitLeaks or TruffleHog in pre-commit hooks.

Q5: What GCP operations should I automate with Terraform vs. leave manual?

Automate anything repeatable; leave experimental or one-off work manual. Terraform good for: (1) VPCs and networking — subnets, firewall rules, routes change rarely but mistakes are catastrophic; (2) IAM policies — auditable, reproducible, peer-reviewable; (3) Production resources — GKE clusters, Cloud SQL instances, Load Balancers — ensures consistency across environments; (4) Multi-environment setups — dev/staging/prod using same module with different variables. Not worth automating: (1) One-off experiments — spinning up a test VM to try something, use gcloud CLI; (2) Data operations — don't Terraform BigQuery datasets that grow constantly; (3) Rapidly-changing configs — Cloud Run revisions during active development. Practical workflow: (A) start by Terraforming infrastructure (VPC, IAM, DBs); (B) leave application deployment to CI/CD (Cloud Build + gcloud); (C) use terraform import to bring existing resources under management gradually, don't try to Terraform everything at once. Tools: Terraform Cloud / Atlantis for PR-based workflow, or tfsec / terraform validate for security/syntax checks in CI.

---

Further Reading

• To understand GCP basics, refer to GCP Complete Guide
• To learn about costs, see GCP Pricing and Cost Calculation Complete Guide
• For AI services, see GCP AI/ML and Vertex AI Complete Guide
• For security settings, see GCP Security and Cloud Armor Protection Guide
• Preparing for certification? See GCP Certification and Course Complete Learning Guide

---

Image Descriptions

---

---

---

---

References

1. Google Cloud, "Compute Engine Documentation" (2024)
2. Google Cloud, "Cloud Run Documentation" (2024)
3. Google Cloud, "Google Kubernetes Engine Documentation" (2024)
4. Google Cloud, "Cloud Storage Documentation" (2024)
5. Google Cloud, "Best Practices for Operating Containers" (2024)