Ensuring the successful operation of a cloud solution · Topic 2 of 8
Managing GKE Workloads
Viewing GKE nodes, Pods and Services, Artifact Registry access, node pools, StatefulSets, horizontal and vertical Pod autoscaling and Autopilot requests.
- 4 min
- kubectl get and describe for inventory; logs for troubleshooting.
- Node service account needs
roles/artifactregistry.readerto pull images. - Node pools group nodes; create new pools for new hardware; cluster autoscaler scales nodes.
What it is
Operating GKE means knowing what is running, letting nodes pull images from Artifact Registry, managing node pools, working with Kubernetes resources (Pods, Services, StatefulSets), configuring horizontal and vertical Pod autoscaling, setting resource requests in Autopilot, and splitting traffic between versions.
How it works
Viewing cluster inventory
kubectl get nodes
kubectl get pods --all-namespaces
kubectl get services
kubectl describe pod web-7d4b9c8f6-abcde
kubectl logs web-7d4b9c8f6-abcde
The GKE pages in the console show the same: clusters, workloads, Services and Ingress, with health and events.
Accessing Artifact Registry
GKE nodes pull images using the node service account. For images in Artifact Registry in the same project, the default setup usually works; otherwise grant the node service account Artifact Registry Reader (roles/artifactregistry.reader) on the repository. Image paths look like REGION-docker.pkg.dev/PROJECT/REPOSITORY/IMAGE:TAG.
Node pools
A node pool is a group of nodes with the same configuration in a Standard cluster.
gcloud container node-pools create gpu-pool --cluster=shop-std --region=us-central1 \
--machine-type=n1-standard-8 --accelerator=type=nvidia-tesla-t4,count=1 \
--enable-autoscaling --min-nodes=0 --max-nodes=3
gcloud container node-pools update default-pool --cluster=shop-std --region=us-central1 \
--enable-autoscaling --min-nodes=1 --max-nodes=5
gcloud container node-pools delete old-pool --cluster=shop-std --region=us-central1
Use separate node pools for different hardware (GPUs, high memory) or Spot VMs. The cluster autoscaler adds and removes nodes in a pool based on Pods that cannot be scheduled.
Kubernetes resources
| Resource | Purpose |
|---|---|
| Pod | One or more containers that run together |
| Deployment | Keeps a number of identical, stateless Pods running and manages rolling updates |
| StatefulSet | For stateful apps: stable Pod names and network identities and persistent storage per Pod (databases, queues) |
| DaemonSet | One Pod on every node (log agents) |
| Service | Stable endpoint and load balancing for a set of Pods (ClusterIP, NodePort, LoadBalancer) |
| Job and CronJob | Run to completion, once or on a schedule |
Pod autoscaling
| Autoscaler | What it changes | Based on |
|---|---|---|
| Horizontal Pod Autoscaler (HPA) | The number of Pods | CPU, memory or custom and external metrics |
| Vertical Pod Autoscaler (VPA) | The CPU and memory requests of Pods | Observed usage over time |
kubectl autoscale deployment web --cpu-percent=60 --min=2 --max=10
kubectl get hpa
Do not let HPA and VPA both act on CPU or memory for the same workload; they conflict.
"Traffic varies through the day" calls for HPA. "Pods keep running out of memory or are over-provisioned" calls for VPA.
Autopilot resource requests
In Autopilot you pay for the CPU, memory and ephemeral storage that Pods request. Set requests in the Pod spec; if you do not, Autopilot applies defaults, and it adjusts requests to supported values. Right-sizing requests is the main cost lever in Autopilot.
Traffic splitting on GKE
To send a share of traffic to a new version, run two Deployments (for example v1 and v2) behind routing that supports weights, such as the Gateway API with weighted backends, or use a service mesh. Simply scaling replica counts gives only rough proportions.
A worked scenario
A team's GKE app slows at lunchtime. They add an HPA on CPU, enable cluster autoscaling on the node pool, and create a separate GPU node pool scaling from zero for image processing. A Redis-like cache moves to a StatefulSet with persistent volumes. New releases go to 10 percent of users through Gateway API weighted routing before full rollout.
How the exam asks about this
- "See all Pods in every namespace."
kubectl get pods --all-namespaces. - "Add GPU nodes to an existing cluster." Create a new node pool with accelerators.
- "Scale Pods with CPU load." Horizontal Pod Autoscaler (
kubectl autoscale). - "Stable identity and storage per Pod." StatefulSet.
- "Nodes cannot pull images from Artifact Registry." Grant the node service account Artifact Registry Reader.
What to remember for the exam
- kubectl get and describe for inventory; logs for troubleshooting.
- Node service account needs
roles/artifactregistry.readerto pull images. - Node pools group nodes; create new pools for new hardware; cluster autoscaler scales nodes.
- Deployment for stateless, StatefulSet for stateful, DaemonSet for per-node agents.
- HPA changes Pod count; VPA changes Pod requests.
- Autopilot bills on Pod requests.
Changing a node pool's machine type recreates all of its nodes, which can disrupt workloads. Many teams create a new pool and migrate workloads instead.
Common mistakes
Using a Deployment for a database needing stable storage per replica. Use a StatefulSet.
Combining HPA and VPA on the same CPU metric. They fight each other.
Ignoring requests in Autopilot. They decide cost and scheduling.
Check yourself
Which autoscaler changes the number of Pods?
The Horizontal Pod Autoscaler.
Which Kubernetes resource gives each Pod a stable identity and its own persistent storage?
A StatefulSet.
What role does a GKE node service account need to pull images from Artifact Registry?
Artifact Registry Reader,
roles/artifactregistry.reader.
Topic 2 of 8 in Ensuring the successful operation of a cloud solution
Test yourself on Ensuring the successful operation of a cloud solution
The full Google Cloud Associate Cloud Engineer question bank has 661 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.