GCP ACE: Kubernetes Architecture and GKE Autopilot vs. Standard
The previous article covered Kubernetes objects (Pods, Deployments, Services) from the outside — what you declare. This one opens the cluster up: what actually runs those objects, and the two ways GKE lets you run a cluster.
The control plane
Every Kubernetes cluster has a control plane — the set of components that make decisions about the cluster but don’t run your application code.
| Component | What it does |
|---|---|
| kube-apiserver | The front door. Every kubectl command, and every other component, talks to the cluster only through this API. It’s the sole component that reads and writes to etcd. |
| etcd | A distributed key-value store holding all cluster state: every object you’ve created, its current status, everything. If etcd is gone, the cluster’s memory is gone. |
| kube-scheduler | Watches for Pods with no node assigned yet, and picks a node for them based on available resources, affinity rules, and taints/tolerations. |
| kube-controller-manager | Runs the control loops that do the reconciling — the Deployment controller noticing “I need 3 replicas but only have 2” and creating one, for example. |
| cloud-controller-manager | Talks to Google Cloud’s APIs on the cluster’s behalf — provisioning a load balancer when you create a LoadBalancer Service, attaching a persistent disk, and so on. |
On GKE, Google runs and manages all of this for you — you never SSH into a control plane node. What you do pay for is a flat cluster management fee of $0.10 per cluster per hour, the same in every mode (zonal, regional, or Autopilot). The GKE free tier gives each billing account $74.40 in monthly credits, which covers exactly one zonal Standard or Autopilot cluster; it can’t be applied to regional Standard clusters or to compute.
The nodes
Nodes are where your Pods actually run. Each node runs three things:
| Component | What it does |
|---|---|
| kubelet | The agent on the node. It reads the Pod specs assigned to this node and makes sure those containers are actually running and healthy — restarting them if they crash. |
| kube-proxy | Maintains the networking rules on the node so traffic sent to a Service’s IP actually reaches one of the right Pods, wherever they’re running. |
| Container runtime | The software that actually starts and stops containers (containerd, in GKE’s case). The kubelet talks to it through a standard interface (CRI). |
One GKE-specific detail: clusters using GKE Dataplane V2 (the default for all new Autopilot clusters) handle Service routing with eBPF programs in the kernel instead of kube-proxy and iptables. The job is the same; the component doing it is different.
Put together: you kubectl apply a Deployment → the API server stores it in etcd → the controller manager notices it needs Pods and creates them → the scheduler assigns each Pod to a node → that node’s kubelet tells the container runtime to start the containers → kube-proxy makes sure Service traffic can reach them.
GKE Autopilot vs. Standard
GKE always manages the control plane for you, in both modes. The difference is what happens to the nodes.
| Autopilot | Standard | |
|---|---|---|
| Node management | Google manages the nodes entirely — you never create or configure one | You create and manage node pools yourself |
| Scaling | Nodes scale automatically with Pod demand; a cluster with no workloads can scale to zero nodes | You configure autoscaling (or node auto-provisioning) yourself |
| Pricing | Pod-based billing — you pay for what your Pods request, not the whole node | You pay for every node you provision, regardless of how much of it your Pods actually use |
| Security defaults | Ships hardened by default; security patches applied automatically within your maintenance window | Autopilot’s hardening is not automatic — you configure it, or enforce Autopilot-style policies manually across the cluster |
| Workloads allowed | Only Autopilot-compatible workloads (no privileged Pods, restricted configs) | Anything, including privileged Pods and custom node configuration |
| Best for | Most production workloads — Google’s own recommendation | Workloads needing privileged access, custom node images, or manual infrastructure control |
Two exact details worth memorizing:
- In Autopilot, the annotation
cluster-autoscaler.kubernetes.io/safe-to-evict=falseprotects a Pod from eviction caused by node auto-upgrades or scale-down for up to 7 days. - A Standard cluster can still run specific workloads in Autopilot mode by assigning them a compute class — it’s not all-or-nothing at the cluster level.
Choosing a mode
Google’s own guidance is blunt: default to Autopilot. Pick Standard only when you specifically need something Autopilot restricts — privileged containers, DaemonSets requiring host access, custom node-level configuration, or fine-grained control over capacity planning. For exam purposes, if a question describes a workload needing “minimal operational overhead” or “pay only for what you use,” that’s Autopilot. If it mentions privileged Pods, custom node pools, or manual node sizing, that’s Standard.
Exam Takeaways
- The control plane (API server, etcd, scheduler, controller manager, cloud controller manager) makes decisions; nodes (kubelet, kube-proxy, container runtime) run the workloads.
kube-apiserveris the only component that talks directly toetcd.kube-schedulerassigns nodes to pending Pods;kube-controller-managerreconciles actual state toward desired state.- GKE always manages the control plane, in both Autopilot and Standard. Every cluster pays a $0.10/hour management fee; the free tier ($74.40/month per billing account) covers one zonal or Autopilot cluster.
- Autopilot: Google manages nodes, Pod-based billing, can scale to zero nodes, hardened by default.
- Standard: you manage nodes, billed per node regardless of utilization, full configuration control.
- A Standard cluster can run Autopilot-mode workloads on specific Pods via a compute class — the choice isn’t locked at the cluster level.
- The Autopilot eviction-protection annotation (
safe-to-evict=false) holds a Pod for up to 7 days. - Default recommendation: Autopilot, unless the workload specifically needs what only Standard allows.