Google Kubernetes Engine (GKE) Study Notes

Google Kubernetes Engine is a managed Kubernetes service for deploying, managing, and scaling containerized applications using Google infrastructure. GKE provisions and manages the control plane and, depending on mode, some or all of the worker nodes. It is the standard choice when an application is built from containers and needs orchestration and rolling updates.

Key facts

• In GKE Standard mode you manage node pools and node configuration yourself, while in Autopilot mode Google manages the nodes and you pay per pod resource request rather than per node.
• A pod is the smallest deployable unit in Kubernetes and usually runs one container, with deployments managing replica sets to keep a desired number of identical pods running.
• Services expose a set of pods through a stable endpoint: ClusterIP is internal only, NodePort opens a port on every node, and LoadBalancer provisions an external cloud load balancer.
• Node pools are groups of nodes in a cluster that share the same configuration, letting you run different machine types, accelerators, or Spot nodes for different workloads in one cluster.
• Workload Identity lets a Kubernetes service account impersonate a Google service account, so pods get Google Cloud credentials without you distributing long-lived service account keys.
• GKE clusters can be zonal or regional; a regional cluster replicates the control plane across zones and offers higher availability for production workloads at additional cost.
• ConfigMaps store non-sensitive configuration and Secrets store sensitive values separately from container images, so the same image can run with different settings per environment.
• Horizontal Pod Autoscaling adjusts pod replicas based on CPU, memory, or custom metrics, while the cluster autoscaler adds or removes nodes in Standard mode when pods cannot be scheduled.

What the exam expects you to know

• Choosing between Standard and Autopilot based on how much node management, customization, and control a scenario requires.
• Explaining Deployments, Services, and Ingress, and which object provides external HTTP access and load balancing to pods.
• Applying Workload Identity instead of service account keys when a pod needs to call Google Cloud APIs securely.
• Scaling a workload at the pod level versus the node level, and recognizing which autoscaler handles each layer.
• Using namespaces, labels, and node pools to separate environments or workload types inside a single shared cluster.
• Storing configuration and secrets outside the image, and understanding why rebuilding an image for a config change is an anti-pattern.

Google Kubernetes Engine (GKE) vs Cloud Run: when to use which

Choose GKE when you need Kubernetes-specific features such as custom scheduling, StatefulSets, DaemonSets, GPUs, or long-running and stateful workloads that do not fit a request-driven model. Choose Cloud Run when you have stateless containers or services that should scale to zero and you want no cluster to manage at all. The key criteria are control and workload shape: GKE gives you the full Kubernetes API and node-level choices but adds operational responsibility, while Cloud Run trades that flexibility for simplicity, per-request billing, and automatic scaling for HTTP and event-driven services. See also the Cloud Run notes.

Useful gcloud commands

gcloud container clusters create my-cluster --zone=us-central1-a --num-nodes=3
gcloud container clusters get-credentials my-cluster --zone=us-central1-a
kubectl get pods
kubectl apply -f deployment.yaml

Common exam traps

• Assuming Autopilot bills per node: Autopilot charges for the CPU, memory, and storage resources your pods request, because Google manages the underlying nodes for you.
• Thinking a pod IP is stable: pods are ephemeral and their IPs change, so clients should always connect through a Service rather than directly to a pod.
• Storing secrets in a container image or plain environment file in version control: use Kubernetes Secrets or Secret Manager so credentials can rotate without rebuilding images.
• Confusing Ingress with a Service type: a LoadBalancer service works at layer 4, while Ingress provides layer 7 HTTP routing, hostnames, and managed TLS for HTTP services.

Frequently asked questions

What is the difference between GKE Standard and Autopilot?

In Standard mode you create and configure node pools, choose machine types, and manage node upgrades and sizing, paying for the nodes you provision. In Autopilot mode Google manages the nodes, applies default security and scaling settings, and bills you for the resources your pods request, which suits teams that want Kubernetes without node operations.

How do pods access Google Cloud APIs securely?

Use Workload Identity. You annotate a Kubernetes service account with the Google service account it should impersonate, bind the two with an IAM policy, and assign that Kubernetes service account to your pods. The pods then receive short-lived tokens automatically, so no service account key file needs to be stored in the cluster.

When do I need a regional cluster instead of a zonal cluster?

Choose a regional cluster for production workloads that must survive a zone outage, because the control plane and, with regional node pools, your nodes are spread across multiple zones in the region. A zonal cluster is cheaper and simpler and is usually sufficient for development, testing, and workloads that tolerate downtime.

Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.