Examkin

Question

Difficulty: Very hardManaging Google Kubernetes Engine Resources

An operations engineer manages a production Google Kubernetes Engine (GKE) Standard cluster named `prod-cluster` in zone `us-central1-a`. The cluster currently runs a batch processing deployment on an on-demand node pool named `batch-pool-v1`. To optimize infrastructure costs, the team must convert this workload to run on Spot VMs without causing service interruption. The engineer attempts to execute an in-place update command on `batch-pool-v1` to convert its VM provisioning type to Spot VMs, but the operational update fails. Which procedure should the engineer perform to successfully transition the workload to Spot VMs?

  1. Create a new node pool named `batch-pool-v2` with the `--spot` flag using `gcloud container node-pools create`, cordon and drain the nodes in `batch-pool-v1` using `kubectl`, and then delete `batch-pool-v1`.Answer
  2. B
    Execute `kubectl autoscale deployment batch-app --enable-spot-instances --min=2 --max=10` to instruct the Horizontal Pod Autoscaler to provision Spot nodes automatically.
  3. C
    Run `gcloud container node-pools update batch-pool-v1 --cluster=prod-cluster --zone=us-central1-a --enable-spot` to force a rolling update of the underlying compute instances.
  4. D
    Update the cluster configuration to GKE Autopilot mode using `gcloud container clusters update prod-cluster --enable-autopilot`, which automatically converts all existing standard node pools to Spot VM pools.

Answer

Create a new node pool named `batch-pool-v2` with the `--spot` flag using `gcloud container node-pools create`, cordon and drain the nodes in `batch-pool-v1` using `kubectl`, and then delete `batch-pool-v1`.
GKE node pools cannot modify their VM provisioning model (such as switching from On-Demand to Spot VMs) after creation. The standard operational procedure requires creating a new node pool configured with the `--spot` flag, cordoning and draining the existing nodes to smoothly migrate running pods to the new capacity, and subsequently deleting the old node pool.

Step-by-Step Solution

1
Analyze GKE node pool immutability rules.
Determine that core node pool properties such as machine type, boot disk size, and Spot/Preemptible instance configuration are immutable post-creation.
Google Cloud Engine instance templates backing GKE node pools do not allow changing instance billing/provisioning models on existing pools.
2
Provision a replacement node pool with Spot VMs enabled.
Execute `gcloud container node-pools create batch-pool-v2 --cluster=prod-cluster --zone=us-central1-a --spot`.
This establishes new node capacity configured specifically to run Spot instances.
3
Migrate workloads cleanly using Kubernetes administrative commands.
Mark `batch-pool-v1` nodes as unschedulable using `kubectl cordon` and safely evict running pods using `kubectl drain`.
Cordoning prevents new pods from landing on old nodes, while draining forces existing pods to reschedule onto the newly available Spot node pool (`batch-pool-v2`).
4
Decommission the legacy node pool.
Execute `gcloud container node-pools delete batch-pool-v1 --cluster=prod-cluster --zone=us-central1-a`.
Removes the unneeded on-demand node capacity once all workloads have migrated.

Key Concept

GKE Node Pool Immutability and Blue-Green Workload Migration
Estimated Time:2m 0s
Rate this question

Topics

Managing Google Kubernetes Engine Resources