Memory hook: Google runs the control plane; choose who manages the nodes.
Must remember
GKE Standard gives greater node-pool control; Autopilot manages more infrastructure and applies its supported workload/configuration model. Regional control planes improve control-plane availability; workload replicas and node placement still determine application resilience. Private networking choices govern node addresses and API access separately.
Authenticate to the intended cluster and verify the kubectl context/namespace before changes. Deployments manage stateless replicas and rollouts; StatefulSets manage stable identities and storage patterns; Services discover/expose workloads. Inspect Pods, events, logs, Services and EndpointSlices before changing cluster capacity blindly.
Store images in Artifact Registry and grant the actual pulling identity appropriate access. Image-pull failures can result from a wrong image path, permissions, network restrictions or missing artifacts. Kubernetes ServiceAccounts and Google IAM service accounts are different identities; Workload Identity Federation for GKE connects supported workload identity to Google API access without embedding static keys.
HPA changes Pod replicas; VPA recommends/adjusts resource requests under its configured mode; cluster/node autoscaling changes node capacity. Requests affect scheduling, limits constrain use, and disruption budgets influence voluntary maintenance. Do not expect a Pod autoscaler to manufacture node capacity instantly.
Node pools group node configuration. Plan upgrades, surge/disruption settings, maintenance windows and compatibility. A node count can be healthy while a workload is Pending because of affinity, taints, quota or a PVC. Persistent-volume topology and access modes must match placement.
GKE Enterprise features can help manage fleets, policy and multi-cluster environments. Choose them for actual governance/operational needs rather than assuming every small application requires a fleet platform.
Review details
Probe distinction: readiness removes an unhealthy Pod from eligible service endpoints; liveness restarts a failed container; startup permits slow initialization before normal probes take over. Do not use an aggressive liveness probe to respond to every downstream database timeout.
Read-only diagnosis sequence: kubectl config current-context → kubectl get pods,svc → kubectl describe pod POD → kubectl logs POD. Inspect events for image authorization, scheduling, volume attachment and probe failures. Image pulling often uses a different identity from the application making a Google API call; granting the latter access does not necessarily fix the former.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Minimal node administration | Autopilot when the workload fits its model. |
| Application needs Google API access | Workload Identity Federation with narrowly scoped IAM. |
| Pods Pending after replica increase | Check requests, placement, storage and node capacity. |
Traps
- A regional control plane does not automatically replicate your database.
- Kubernetes RBAC and Google IAM govern different parts of the access path.
Active recall
1. Standard versus Autopilot?
Standard exposes more node control; Autopilot manages more infrastructure under its supported workload model.
2. What does HPA scale?
Workload replica count.
3. What does VPA primarily address?
Pod resource requests, through recommendations or configured adjustment behavior.
4. Why avoid service-account keys in images?
They can leak through registries and remain valid outside the intended workload.
5. What first explains ImagePullBackOff?
Pod events showing image reference, authentication or connectivity failure.