Most PDBs I see in the wild are maxUnavailable: 1 against a Deployment with 1 replica, which means “do not evict me, ever.” That protects your pod from voluntary disruptions (like a node drain) but also blocks routine maintenance. The cluster admin eventually force-drains and you lose the protection anyway.

A PDB that actually works pairs minAvailable with a replica count greater than one, and uses a percentage so it scales with horizontal autoscaling.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
  namespace: platform
spec:
  # Keep at least 50% of api pods available during voluntary disruptions.
  # With 4 replicas: at most 2 can be evicted at once.
  # With 10 replicas: at most 5 can be evicted at once.
  minAvailable: 50%
  selector:
    matchLabels:
      app.kubernetes.io/name: api

And the Deployment it guards needs at least two replicas for this to be meaningful:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: platform
spec:
  replicas: 4
  selector:
    matchLabels:
      app.kubernetes.io/name: api
  template:
    metadata:
      labels:
        app.kubernetes.io/name: api
    spec:
      containers:
        - name: api
          image: ghcr.io/me/api:1.2.3
          ports: [{containerPort: 8080}]

minAvailable can be absolute too (minAvailable: 2). Use whichever matches your reasoning; percentages survive HPA scaling. See also /posts/admission-webhook-crash-loop/.