- Ya
- 4 Septemba 2026, 21:22 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 0208862
Switches every PodDisruptionBudget from minAvailable: 1 to maxUnavailable: 1. On a two-replica Deployment the two are identical — one pod evictable at a time. On a ONE-replica Deployment they are opposites: minAvailable: 1 permits ZERO disruptions, so it does not protect the workload, it deadlocks kubectl drain forever and the node never comes up for maintenance. That is not hypothetical, and it is visible right now. These budgets applied in a single KlusterServices deploy while the replica bumps they belong to are still queued behind fifty service builds on two CI runners, so 22 of the 26 live budgets currently describe a Deployment that is still at one replica — every one of them showing ALLOWED DISRUPTIONS 0. A node drain attempted in this window would have blocked on services that are not even protected yet. Under maxUnavailable the same window is one in which the budgets simply do nothing yet, which is the correct thing for them to do until the second pod exists. It covers the likelier future case too: somebody scales a service back to one and does not think to remove its entry here. The README warned about exactly that, and a warning is a worse guard than a failure mode that cannot bite. A budget that quietly stops protecting is a bug found in review. One that quietly stops node maintenance is found at 3am.