A cloud engineer must migrate non-critical batch processing workloads on a Google Kubernetes Engine (GKE) Standard cluster named `prod-cluster` to a dedicated Spot VM node pool to lower compute expenses. The engineer must prevent general workloads from being scheduled onto the Spot nodes while ensuring existing batch pods transition smoothly without resource contention. In what chronological sequence should the engineer perform the following operational steps?
- 1Execute `gcloud container node-pools create spot-batch-pool --cluster=prod-cluster --zone=us-central1-a --spot --node-taints=workload=batch:NoSchedule` to provision the new cost-optimized infrastructure.
- 2Update the batch deployment YAML manifest to add a toleration for `workload=batch:NoSchedule` and a node selector for `cloud.google.com/gke-spot=true`.
- 3Run `kubectl apply -f batch-deployment.yaml` to deploy the updated pod specifications to the GKE cluster.
- 4Execute `gcloud container node-pools delete standard-batch-pool --cluster=prod-cluster --zone=us-central1-a` after verifying that all batch pods are running on the Spot pool.
Cevap
The correct operational sequence is: 1) Provision the new Spot VM node pool with a `NoSchedule` taint using `gcloud container node-pools create`; 2) Update the batch deployment manifest with matching tolerations and Spot node selectors; 3) Apply the manifest using `kubectl apply` to launch pods on the Spot pool; 4) Delete the legacy standard node pool using `gcloud container node-pools delete` after verifying migration success.
Order requires establishing the tainted infrastructure first, configuring workload specifications to tolerate the taint, applying those specifications to migrate running pods, and finally deleting the legacy node pool once migration is complete.
Adım Adım Çözüm
Anahtar Kavram
GKE Node Pool Migration and Workload Isolation using Spot VMs, Taints, and Tolerations