I have a workload that typically runs with just one pod. When I need to drain a node, I want to ensure that the existing pod isn't killed right away. Instead, I'd prefer Kubernetes to launch a second pod on another node first, wait for it to be healthy, and only then remove the original pod. This way, downtime will be minimized. Is there a built-in Kubernetes method to achieve this for a single-replica workload, or will I need to create a custom solution?
3 Answers
Set your rolling update parameters to allow a max surge of 1 and max unavailable to 0. First, cordon the node, then perform a rollout restart before finally draining it. This should help ensure minimal disruption.
Before draining the node, try cordoning it, followed by a rollout of your deployment. This way, you can use the maxSurge strategy to temporarily have two replicas running, which will help in maintaining availability during the drain.
This situation can vary based on your workload. If it can handle multiple replicas, opting for a deployment or stateful set with at least two replicas is best. It ensures resilience against failures and unplanned restarts. But if you can't run multiple replicas, you might need a VM with live migration capabilities for better reliability.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures