3.1.3. Managed Instance Groups and Google Kubernetes Engine
💡 First Principle: Both Managed Instance Groups (MIGs) and GKE solve the same underlying problem — keeping a fleet of identical or similar workloads healthy and appropriately sized without manual intervention — but they operate at different levels of abstraction: MIGs manage VMs, GKE manages containers within those VMs.
A Managed Instance Group built from an instance template (a reusable configuration blueprint) can autoscale — automatically adding or removing VM instances based on load metrics like CPU utilization — and automatically heals by replacing unhealthy instances detected via health checks. GKE requires the kubectl CLI (installed via the gcloud components install kubectl or the Cloud SDK) to interact with a cluster once deployed. Deploying a GKE cluster means choosing between Autopilot (Google manages nodes; you manage workloads) and Standard (you manage node pools directly), and between zonal (single-zone control plane), regional (control plane replicated across zones in a region, for higher availability), and private clusters (nodes have no public IP addresses, reducing attack surface). Once a cluster exists, deploying a containerized application typically means applying a Kubernetes manifest (a Deployment plus a Service) via kubectl apply, which GKE then reconciles into running Pods.
⚠️ Exam Trap: A scenario emphasizing "minimize the attack surface of the cluster's nodes" is pointing at a private cluster configuration specifically, not just "use GKE" generically — the exam distinguishes cluster network exposure as its own tested decision point, separate from the Autopilot-vs-Standard choice.
Reflection Question: Why would a company choose a regional GKE cluster over a zonal one for a production workload, and what specifically does the control plane replication protect against that a zonal cluster's control plane doesn't?
