Understanding RollingUpdate and PodDisruptionBudget for Single Instance Deployments
Asked by
CuriousCoder99
I'm trying to wrap my head around how RollingUpdate and PodDisruptionBudget (PDB) work, especially in single instance deployments. With a deployment using RollingUpdate, you can set things like maxSurge to 1 and maxUnavailable to 0, allowing you to create a new pod while the old one is still running—great for zero downtime during updates.
However, I've noticed that a PodDisruptionBudget behaves differently. The docs mention that if you set maxUnavailable to 0 or minAvailable to 100% for a deployment, you're essentially preventing any voluntary evictions. This means that if you attempt to drain a node where your pod is not evictable, the drain won't complete.
Why can RollingUpdate accommodate single instance deployments but PDB can't? I'm puzzled about the reasoning behind this limitation. I've tried clarifying my question, and it feels like there should be a way to achieve uninterrupted updates for node cycling as well, similar to what's possible with RollingUpdate.
Answers
Totally depends on your cluster dynamics. If it’s a static cluster, sure, it might not be an issue. But in a dynamic environment where nodes are constantly scaling, having a maxUnavailable of 0 with a single pod can cause hanging drains and unresolved nodes. Essentially, Kubernetes tries to manage resources, but that setting stops it from effectively dealing with node evictions.
Reply to this answer
It's not that PDB doesn't support single instance deployments; it's more that using it in that context often leads to issues. Having a PDB with zero maxUnavailable for a single instance is essentially setting yourself up for trouble. In practice, it creates a situation where you can’t drain a node without causing complications. This is generally seen as an odd configuration to use.
Reply to this answer
You pretty much nailed it with your quote from the docs. Setting zero for maxUnavailable makes too many restrictions. Can you break it down a bit more and let us know what's not clicking?
CuriousCoder99: I reworded my question to be clearer—hopefully, that helps!
Reply to this answer
The key here is the maxSurge setting with RollingUpdate. It allows you to run one more replica than you have defined, which means you can smoothly transition from the old pod to the new one without downtime, even with a single instance. This is why it works seamlessly for rolling updates, as Kubernetes handles the transition gracefully.
CuriousCoder99: Thanks! I appreciate you clarifying that. My original question was a bit confusing, but this really helps!
Reply to this answer
Add your answer
Answers are reviewed before publication.
CuriousCoder99: I see your point! I totally get why that's an issue now.