What is Containers — Google Kubernetes Engine (GKE) in Google Cloud?

6 / 24

Google Cloud

Containers — Google Kubernetes Engine (GKE)

Run Kubernetes the way Google designed it, in Standard or fully-managed Autopilot mode.

GKE is managed Kubernetes from the people who wrote Kubernetes, and it shows in the defaults.

GKE Standard is leasing a fully-equipped industrial kitchen where you still decide how many ovens to run. GKE Autopilot is the same kitchen but the venue silently adds exactly the equipment each dish needs and bills you per dish — you just cook, never count appliances.

Key Concepts

The mode is the decision.

    Standard   you manage node pools, size them and pay per node
    Autopilot  Google manages nodes entirely; you pay per POD
               resource request

Autopilot changes the cost model, not just the operations. You stop paying for unused node capacity because you are billed for what the pods request — which also makes requests and limits financially significant rather than merely good practice.

Autopilot enforces good hygiene by refusing privileged containers, requiring resource requests, and managing node security itself. That is a constraint, and usually a welcome one.

Workload Identity is the right auth model and should be used from day one:

    Kubernetes service account  ->  Google service account
      pod calls Google APIs with a short-lived token
      no key file anywhere

Release channels manage upgrades — rapid, regular or stable — so clusters stay current without manual planning. Maintenance windows control when.

The things that actually cause incidents.

    no resource requests/limits   noisy neighbours and evictions
    no PodDisruptionBudget        an upgrade drains everything at once
    single-zone cluster           a zone outage is a total outage
    no cluster autoscaler         pods pending indefinitely
    latest tag                    nobody knows what is running

Regional clusters replicate the control plane across zones and spread nodes automatically. A zonal cluster is cheaper and is a single point of failure.

Networking choices are consequential. VPC-native clusters use alias IPs so pods are first-class VPC addresses, and the pod CIDR must be sized for the growth you expect — it cannot be changed later.

GKE or Cloud Run? Cloud Run unless you need the Kubernetes API, operators, custom scheduling, or you already run Kubernetes. "We might need Kubernetes eventually" is not a reason to start there.

What the interviewer is probing.1. "Standard or Autopilot?" Probing: the cost and operations model. Stalls: "Standard, for control." Moves up: Autopilot bills per pod resource request rather than per node, so unused node capacity disappears — and it enforces requests and limits, which is usually welcome.

2. "How should a pod authenticate to Google APIs?" Probing: Workload Identity. Stalls: "A service account key in a secret." Moves up: Workload Identity maps a Kubernetes service account to a Google one, so the pod gets short-lived tokens and no key file exists.

3. "What cannot be changed after cluster creation?" Probing: the sizing decision. Stalls: "Nothing important." Moves up: the pod CIDR on a VPC-native cluster, so it must be sized for expected growth.

4. "What causes most GKE incidents?" Probing: the basics. Stalls: "Kubernetes complexity." Moves up: missing resource requests and limits, no PodDisruptionBudget so an upgrade drains everything, a single-zone cluster, and the latest tag hiding what is running.