Question

Difficulty: MediumManaging Google Kubernetes Engine Resources

A cloud administrator needs to upgrade the machine type of a node pool in a production Google Kubernetes Engine (GKE) Standard cluster to handle increased resource demands without incurring workload downtime. What is the correct sequence of steps to perform this node pool migration safely?

  1. 1Create a new node pool (`pool-v2`) with the target machine type using `gcloud container node-pools create`.
  2. 2Mark nodes in the existing node pool (`pool-v1`) as unschedulable using `kubectl cordon`.
  3. 3Evict workloads from the existing node pool (`pool-v1`) using `kubectl drain`.
  4. 4Delete the original node pool (`pool-v1`) using `gcloud container node-pools delete`.

Answer

The correct sequence begins with provisioning the new node pool (`pool-v2`), followed by cordoning nodes in the old pool (`pool-v1`), draining the old pool to migrate pods, and finally deleting the old node pool once migration completes.
In GKE node pool migrations, zero-downtime is achieved by following a structured blue-green workflow. First, provision new capacity (`pool-v2`). Second, cordon the original nodes (`pool-v1`) to prevent new pod assignments. Third, drain the original nodes to gracefully evict running pods so Kubernetes deployment controllers recreate them on `pool-v2`. Fourth, delete `pool-v1` after verifying all pods are running successfully on the new nodes.

Step-by-Step Solution

1
Execute `gcloud container node-pools create pool-v2 ...` to add target capacity.
A new GKE node pool with the larger machine type is created and joins the cluster.
Destination nodes must exist so that evicted pods have available capacity to be rescheduled onto immediately.
2
Execute `kubectl cordon` targeting nodes in `pool-v1`.
Old nodes are marked as unschedulable (`SchedulingDisabled`).
Cordoning prevents new pods from landing on the legacy nodes while preparing for eviction.
3
Execute `kubectl drain` targeting nodes in `pool-v1`.
Pods on `pool-v1` nodes are gracefully evicted and rescheduled by Kubernetes on `pool-v2`.
Draining triggers orderly pod termination and rescheduling without causing service downtime.
4
Execute `gcloud container node-pools delete pool-v1 ...`.
The legacy node pool and its associated Compute Engine VM instances are deleted.
Deleting empty legacy nodes frees up project resources after verifying workload health on the new pool.

Key Concept

GKE Blue-Green Node Pool Migration Sequence
Rate this question