4.1.2. GKE Cluster and Workload Management
💡 First Principle: Operating a GKE cluster day-to-day means managing at two distinct levels simultaneously — the node pools that provide capacity, and the Kubernetes workloads running on top of that capacity — and most operational tasks belong clearly to one level or the other.
Viewing current running GKE cluster inventory — nodes, Pods, Services — is done via kubectl get commands or the GKE console's Workloads/Services views. Configuring GKE to access Artifact Registry lets the cluster pull container images from Google's managed registry, typically via the node service account's IAM permissions. Node pools can be added, edited, or removed independently — letting a cluster run, for example, a general-purpose pool alongside a GPU-attached pool for specialized workloads — and node pools themselves can autoscale based on pending Pod demand. At the workload level, Kubernetes resources like Pods, Services, and StatefulSets are managed via manifests, and Pod autoscaling comes in two flavors: horizontal (adding or removing Pod replicas based on load) and vertical (adjusting a Pod's resource requests/limits based on observed usage). On GKE Autopilot specifically, Pod resource requests you define directly determine what you're billed for, since Autopilot bills per-Pod resource consumption rather than per-node.
⚠️ Exam Trap: A GKE node pool always contains identical, unconfigurable nodes — that's an easy but wrong assumption. Node pools are precisely how you group nodes with different machine types, GPU/TPU attachments, or taints within a single cluster — clusters routinely run several node pools side by side for exactly this reason.
Reflection Question: A cluster runs a mix of general web workloads and a GPU-dependent ML inference workload. What GKE feature lets both coexist in one cluster without forcing every node to have an expensive GPU attached?
