Comparison
Pod disruption budgetvsRolling deployment
Pod disruption budget
a node upgrade rolled through the cluster and stopped, because taking one more replica down would have breached what you declared.
A declaration of how much of a workload may be voluntarily unavailable at once, which drains and upgrades must respect. It is the only thing standing between a routine cluster upgrade and every replica of a service being evicted in sequence faster than it can start. It constrains only voluntary disruption — a node catching fire does not consult it — and a budget that can never be satisfied will wedge an upgrade indefinitely.
Full entry →Rolling deployment
instances are replaced a few at a time, so both versions serve traffic simultaneously for several minutes.
Replacing instances incrementally, controlled by how many extra may exist and how many may be missing at once. It is the default because it needs no spare environment and no traffic switch, and its defining consequence is version coexistence: your database schema, your caches and your APIs must tolerate both versions at once. Rollback is slow, because undoing it is another roll.
Full entry →