A Deployment runs 3 replicas of a service the team considers highly available, with a PodDisruptionBudget of `minAvailable: 2`. A single node fails unexpectedly (not a drain — the node just goes away). Does the PDB protect the service in this incident, and if the 3 replicas happened to be co-located on that one node, could the PDB have prevented that from being possible in the first place?

No to both, and for the same underlying reason: a PodDisruptionBudget only governs voluntary disruptions — evictions the cluster itself initiates and could choose to slow down or refuse, like a node drain for an upgrade or a scale-down. A node simply failing is an involuntary disruption; nothing asks permission, there's no eviction request for the PDB to block, the pods on that node are just gone. And a PDB doesn't influence where pods get scheduled in the first place — if all three replicas happened to land on one node because nothing told the scheduler to spread them, a PDB configured afterward does nothing to fix that placement; it only ever reacts to a voluntary disruption once one is proposed. Actually preventing three replicas from sharing one point of failure needs a topology spread constraint or pod anti-affinity at schedule time — the PDB and the spread constraint solve two different problems (surviving intentional maintenance, and never being all in one place to begin with) and neither one substitutes for the other.