Google Cloud Platform Services

GCP: GKE, Cloud Run, Cloud SQL, BigQuery

In our practice, one client on GKE Autopilot received an alert: pod disruption budget violation — the deployment rolled back because Autopilot started evicting nodes to rebuild for a new configuration, and PodDisruptionBudget with maxUnavailable: 0 blocked the process. This is not an Autopilot bug — it is normal behavior with an incorrectly configured PDB. Over five years working with Google Cloud Platform, we have learned to anticipate such scenarios and configure clusters so deployments go smoothly. Our certified engineers have migrated over 50 projects on GCP and guarantee that an audit will identify at least 20% cost savings or we provide a detailed optimization plan. If you need to design or optimize a turnkey infrastructure — order an audit. We will evaluate your project and propose solutions.

What Does GKE Autopilot Change in Practice?

GKE Autopilot on Google Cloud Platform is a mode where Google fully manages nodes. No node pools, no capacity management, no kubectl cordon. Pods describe resources — Autopilot ensures them. (Learn more about Kubernetes — a platform for container orchestration — see Kubernetes documentation.)

What this means practically: requests and limits must be set for every container without exception. In standard GKE you can be lazy and omit requests — pods will still run. In Autopilot — no. Minimum request: cpu: 250m, memory: 512Mi. Billing goes by requests, not actual usage.

Autopilot automatically imposes securityContext restrictions. Containers cannot run with privileged: true or mount hostPath. For tools like Falco or Datadog Agent this is a problem — they need DaemonSets with privileges. In Autopilot they simply do not work. Standard GKE is more flexible here.

Choice between Autopilot and Standard: Autopilot is convenient for teams without a dedicated platform engineer — less operational load, no node patching, automatic bin-packing. Standard is needed when custom node configurations, GPU workloads, or specific system daemonsets are required.

Why Is Workload Identity Mandatory for GKE?

A classic GCP problem — Service Account JSON keys in Kubernetes Secrets. A key is created, stuffed into kubectl create secret generic sa-key --from-file=key.json, rotation never set up. The key lives for years, accessible to anyone who can read Secrets in the namespace. Workload Identity solves this correctly: eliminates long-lived keys and reduces credential leak risk by 5 times compared to JSON keys (per Google Cloud documentation).

To configure Workload Identity, follow three steps:

1. Bind the Kubernetes ServiceAccount to a GCP Service Account via IAM policy:

   gcloud iam service-accounts add-iam-policy-binding \ [email protected] \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:project.svc.id.goog[namespace/ksa-name]" 

2. Add an annotation to the ServiceAccount:

   apiVersion: v1 kind: ServiceAccount metadata: name: ksa-name annotations: iam.gke.io/gcp-service-account: [email protected] 

3. Run a pod with this KSA — GCP Service Account tokens are delivered via the metadata server. No JSON keys, automatic rotation. On Autopilot, Workload Identity is mandatory.

When to Choose Cloud Run for Serverless?

Cloud Run on GCP runs containers without infrastructure management. Difference from Lambda — full container, any runtime, up to 32 GB RAM and 8 vCPU. Scaling from zero to thousands of parallel instances. Cloud Run is built on Kubernetes and Knative.

Cloud Run is suitable for: APIs with unpredictable traffic, webhook handlers, background jobs via Pub/Sub triggers, preview environments for PR reviews. Cold start problem is solved with min-instances: 1 — one instance always warm, not billed during idle (only for RAM in idle). For latency-sensitive APIs with SLA < 200ms this is mandatory — response time drops 3–5 times compared to cold start.

Cloud Run Jobs — for batch tasks. Launched on schedule via Cloud Scheduler, processes tasks in parallel using task-count and parallelism, pay only for execution time.

How to Set Up Cloud SQL for Production?

Cloud SQL on Google Cloud Platform supports PostgreSQL, MySQL, SQL Server. HA configuration via standby replica in another zone — automatic failover, about 60 seconds. Connection pooling is critical for Cloud Run and Cloud Functions. Cloud SQL Auth Proxy — sidecar or separate container that establishes a secure connection via IAM, without open ports or manual SSL certificates. For Cloud Run on GCP: Auth Proxy runs as a sidecar (--dependency in cloud run deploy), app connects to localhost:5432.

# Cloud Run service YAML with Auth Proxy sidecar containers: - name: app image: gcr.io/project/app:latest env: - name: DB_HOST value: "127.0.0.1" - name: cloud-sql-proxy image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.11 args: - "--structured-logs" - "--port=5432" - "project:region:instance-name" 

Read Replicas in Cloud SQL — for read-heavy workloads. Promotions with sudden read request spikes, analytics on production data without master load. Cross-region replica — for DR scenarios.

How Does Cloud SQL Auth Proxy Work?

The Cloud SQL Auth Proxy on GCP uses IAM to authenticate and encrypt connections. It runs as a sidecar container within the same pod (for Cloud Run) or on a VM. The proxy opens a local TCP port and forwards traffic to the Cloud SQL instance through a secure tunnel. No need to whitelist IPs or manage SSL certificates — the proxy handles all security automatically. For applications using private IP, the proxy can connect over the VPC network without internet exposure.

BigQuery: Analytics Without Infrastructure Management

BigQuery on GCP — serverless analytical warehouse. Queries over terabytes of data complete in seconds. Billing: $5 per terabyte of processed data (or flat-rate via capacity reservations). The main mistake newbies make is SELECT * on large tables. BigQuery is columnar storage: SELECT * scans all columns, SELECT id, name, created_at — only three. The cost difference is multiple — correct query saves up to 80% budget.

One client reduced BigQuery costs from $5,000 to $1,200 per month after implementing partitioning and clustering.

Partitioning on a time column (DATE, TIMESTAMP) — mandatory for event tables. Query with WHERE date = DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY) scans only one partition, not the entire history. Clustering on frequently used columns in WHERE/JOIN — additional reduction in scan volume. BigQuery ML allows training models directly in SQL — logistic regression, k-means, time series forecasting — without data export.

Implementation Process

We follow a structured pipeline for every GCP engagement:

1. Infrastructure audit – analyse current setup (IAM, networking, costs, CI/CD, observability). Measure baseline spend and identify quick wins.
2. Solution design – produce HLD/LLD with architecture decisions (Autopilot vs Standard, Workload Identity, Cloud Run vs GKE, partitioning strategy).
3. Implementation – deploy using IaC (Terraform, Cloud Deployment Manager), configure CI/CD pipelines (GitLab CI, GitHub Actions, Cloud Build), set up monitoring (Cloud Monitoring, Grafana).
4. Testing & validation – load testing, chaos engineering (simulate node failures, PDB violations), security scan, cost projection validation.
5. Handover & training – runbook delivery, team workshop (2 sessions), two-week post-implementation support.

What the Service Includes

• Audit of current GCP infrastructure: IAM, networking, costs, identifying savings up to 40%.
• Architectural documentation (HLD/LLD).
• Deployment of GKE clusters with Workload Identity, Autoscaling, NetworkPolicies.
• Configuration of Cloud Run + Cloud SQL Auth Proxy.
• BigQuery optimization: partitioning, clustering, materialized views — reducing query costs by 5–20 times.
• CI/CD pipelines (GitLab CI, GitHub Actions, Cloud Build).
• Monitoring and alerting (Cloud Monitoring, Grafana).
• Team training (GCP workshop).
• Post-implementation support (two weeks).

Typical Timelines

Cost calculated individually after audit of current infrastructure and requirements. If you face similar Autopilot PDB issues or want to cut GCP spend by 20% or more, contact us for a GCP infrastructure audit estimate. Order a consultation and receive a detailed optimization plan for your Google Cloud Platform environment with projected savings of up to 40%.