PodDisruptionBudgets: The Five Lines That Save Your Upgrade

Here's an outage that happens constantly and is almost entirely preventable. A team runs an AKS upgrade. Nodes drain in sequence, evicting pods to reschedule them. On one node sit all three replicas of a service. The drain evicts all three at once. For the seconds it takes them to come back elsewhere, the service is simply down, during a maintenance window the team thought was safe.

The thing that would have prevented it is a PodDisruptionBudget, and it's about five lines:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-service
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-service

A PDB governs voluntary disruptions: the planned evictions from node drains during upgrades and scale-down. It tells Kubernetes: "you may take pods from this app, but never drop below this many available." The drain then respects it, evicting pods a few at a time and waiting for replacements to come up before taking more. Your rolling node upgrade becomes a genuinely rolling pod restart.

Two things worth saying plainly:

• A PDB does nothing for involuntary disruptions: a node crashing, hardware dying. That's what replicas and spread are for. PDBs are about the planned stuff.
• A too-strict PDB blocks the drain entirely. minAvailable equal to your replica count means no pod can ever be evicted, and your upgrade hangs forever. Leave headroom: if you run three, allow one to move.

Every workload that runs more than one replica and that you'd notice going down deserves a PDB. It's the cheapest reliability you'll ever buy in AKS: five lines that turn "we took an outage during a routine upgrade" into a sentence you never have to write.