GKE

Google Kubernetes Engine is managed Kubernetes for teams that need portable orchestration, custom controllers, batch jobs, or multi-service meshes. A FullStack shop often runs APIs, workers, and ingress on GKE while using Workload Identity instead of long-lived JSON keys.

					apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      serviceAccountName: api-sa
      containers:
        - name: api
          image: gcr.io/project/api:2.1.0
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 3000
				

| GKE feature | Why it matters | |-------------|----------------| | Node pools | Separate system and app workloads | | Workload Identity | Pods call GCP APIs without static keys | | Autopilot vs Standard | Less node ops versus more tuning freedom |

Plan upgrades, pod disruption budgets, and cluster autoscaling before production traffic.

On interviews: when GKE beats Cloud Run; Workload Identity; Ingress/Gateway; node pool sizing; rollout strategy with readiness probes.

Common pitfalls: running production on a single node pool without taints; cluster-admin for app service accounts; no resource requests blocking HPA; surprise control-plane upgrade windows.

The trade-off is Kubernetes portability and ecosystem power versus YAML complexity, cluster cost, and platform team overhead.

Checklist:

• Use Workload Identity for GCP API access from pods.
• Separate node pools for system and application tiers.
• Gate rollouts with readiness and PDBs.
• Right-size requests before enabling cluster or HPA scaling.