Skip to content

Disruption

A budget is a veto, and only over one thing

A PodDisruptionBudget cannot keep your pods alive. It can stop somebody taking them away on purpose — and it can stop them forever.

about 11 minutes

Two kinds of pod going away

You have a PDB with `minAvailable: 2` over three replicas. A node dies, taking two pods with it. What does the budget do?

The drain that is still going on Thursday

disruptionsAllowed is the number of pods that may be evicted right now: healthy pods minus the floor. A budget of minAvailable: 3 over three replicas makes it zero, permanently, because evicting any pod would breach it.

A drain that is refused does not fail. It waits, and asks again, and keeps asking — because the expectation is that a rollout will shortly add a pod and make room. If nothing ever will, it waits forever. There is no error, no timeout by default, and no event that says this will never finish.

Every pod is Running. Every pod is Ready. The node is cordoned, so it is taking no new work and giving up none of its old work. Nothing anywhere is red, and somebody finds out on Thursday.

A budget whose floor equals the replica count can never allow a disruption. It is not a strict policy — it is a deadlock with a friendly name.

Try this
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: checkout
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: checkout
`disruptionsAllowed`, and then what the drain does with it.
0ms simulated

Pods — in creation order

No pods. Nothing has been asked for, or nothing has acted yet.

Events — in the order the cluster produced them

No events yet.

Everything you do here stays in this browser.Part of liter8.sh