Rolling Pod nodeSelector migration¶
Rolling Pod nodeSelector migration is a strategy used to safely migrate workloads to a new Kubernetes node pool without downtime. This is typically required when performing maintenance or upgrades on an existing cluster (e.g., GKE upgrades) where the original nodes must be replaced or recreated.^[400-devops-05-cloud-provider-gcp.md]
Procedure¶
The migration process involves creating a temporary node pool to host workloads while the original pool is updated.
- Create Temporary Node Pool: A new node pool (often named
temp) is provisioned in the cloud infrastructure to serve as the target environment for the migration.^[400-devops-05-cloud-provider-gcp.md] - Shift Workloads: The application configurations (e.g., Deployments or StatefulSets) are updated to change their
nodeSelector.^[400-devops-05-cloud-provider-gcp.md]- The selector is switched from the original pool (e.g.,
pool: app) to the temporary pool (pool: temp).^[400-devops-05-cloud-provider-gcp.md] - This change triggers the Kubernetes scheduler to move pods to the new nodes.
- The selector is switched from the original pool (e.g.,
- Upgrade Original Pool: Once the workloads have safely shifted to the temporary pool, the original node pool is upgraded or modified (e.g., changing the GKE version).^[400-devops-05-cloud-provider-gcp.md]
- Restore Workloads: The
nodeSelectoris reverted back to the original pool (pool: app), scheduling the pods onto the now-upgraded nodes.^[400-devops-05-cloud-provider-gcp.md] - Cleanup: The temporary infrastructure is removed, and any external network configurations (such as IPs for CI/CD tools) are verified.^[400-devops-05-cloud-provider-gcp.md]
Related Concepts¶
- Terraform
- [[GKE]]
- [[Kubernetes nodeSelector]]
Sources¶
^[400-devops-05-cloud-provider-gcp.md]