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.
4 Answers
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.
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?
I reworded my question to be clearer—hopefully, that helps!
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.
I see your point! I totally get why that's an issue now.
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.
Thanks! I appreciate you clarifying that. My original question was a bit confusing, but this really helps!