Choosing a Kubernetes Pod Disruption Budget Strategy

The problem: maintenance can evict too many replicas at once

You cordon and drain a node to apply a kernel patch or upgrade Kubernetes. The eviction controller attempts to terminate pods on that node. If you run four replicas of a stateless API and the drain proceeds without constraints, Kubernetes may evict all four before replacement pods become ready. Traffic drops, latency spikes, or the service fails entirely.

A Pod Disruption Budget (PDB) is a Kubernetes object that limits how many pods of a replicated application can be unavailable during voluntary disruptionsdisruptions initiated by an administrator or controller, such as a node drain, cluster upgrade, or cluster autoscaling scale-down. It does not protect against involuntary disruptions, such as hardware failure or a kernel panic.

Useful takeaway: set a PDB before you need it. Use minAvailable when your service must keep a fixed number of healthy replicas, and maxUnavailable when you can tolerate a percentage of capacity loss. Always validate the budget with a controlled drain before relying on it during a maintenance window.

Decision constraints

Before choosing a setting, confirm these conditions:

• The workload is managed by a controller such as a Deployment, ReplicaSet, or StatefulSet. PDBs do not create replacement pods; the controller does.
• You are concerned with voluntary disruptions only. PDBs cannot prevent pod loss from node hardware failure.
• You have permission to create policy objects in the target namespace and, for testing, to drain nodes.

This guide assumes Kubernetes 1.21 or later, where the policy/v1 PDB API is generally available. Earlier versions may use the deprecated policy/v1beta1 API. Verify API availability in your target cluster before production use.

Compare minAvailable and maxUnavailable

Setting	Unit	Best for	Main risk
minAvailable	Integer or percentage	Services with a known minimum healthy capacity, such as a frontend that needs at least two replicas	Setting it equal to the replica count can block node drains indefinitely
maxUnavailable	Integer or percentage	Workloads where temporary percentage-based capacity loss is acceptable, such as a worker pool that can lose 20 percent	During a drain, more pods than expected may be unavailable if replicas scale down simultaneously

Trade-offs

minAvailable guarantees a floor. If you set minAvailable: 2 on a four-replica Deployment, Kubernetes will not evict a pod if doing so would leave fewer than two healthy replicas. This is safest for user-facing services, but it can make cluster maintenance impossible if every replica must stay up.

maxUnavailable guarantees a ceiling on loss. If you set maxUnavailable: 25% on an eight-replica Deployment, up to two replicas may be unavailable during a voluntary disruption. This is friendlier to autoscaling and node maintenance, but it does not guarantee that a specific number of replicas keep serving traffic.

PDBs evaluate the current number of ready pods. If you scale a Deployment down, the allowed disruption count adjusts automatically. If you scale up, the budget may allow more disruptions. PDBs do not trigger pod creation; they only block eviction when the budget would be exceeded.

Concrete implementation: PDB for a Deployment

The following example protects a Deployment named api with label app: api. It requires at least two healthy replicas at all times during voluntary disruptions.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-min-available
  namespace: default
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: api

Apply the manifest from a machine with kubectl configured for the cluster:

kubectl apply -f api-pdb.yaml -n default

Required permissions: namespace-level permission to create PodDisruptionBudget objects, typically granted to cluster administrators or namespace editors. Draining a node for validation requires cluster-admin or equivalent permissions.

Validate the budget before maintenance

Check the PDB status after applying it:

kubectl get pdb api-min-available -n default

Look at the ALLOWED DISRUPTIONS column. A value greater than zero means the budget currently permits some evictions. A value of zero means any further eviction would violate the budget, and a node drain will block until a pod becomes healthy or the budget changes.

To test behavior in a non-production cluster, drain a node that hosts one of the API pods:

kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

Replace <node-name> with the actual node. Expected behavior: if evicting the pod would drop healthy replicas below minAvailable, the drain command waits or reports an eviction error. If headroom exists, the pod is evicted and the Deployment controller starts a replacement.

Risk: draining a node evicts all eligible pods on it, not just the target application. Schedule this test during a low-traffic period and be ready to uncordon the node with kubectl uncordon <node-name>.

Limitations and how to check the result

• PDBs do not protect against involuntary disruptions. A node hardware failure can still take down replicas regardless of the budget.
• PDBs do not create pods. If a pod is deleted for a reason outside the budget, the controller must replace it.
• Setting minAvailable equal to the total replica count can block all drains. In a one- or two-replica cluster, this often causes maintenance deadlocks.

Practical check: after applying the PDB and before any maintenance, run:

kubectl get pdb -n default

Confirm ALLOWED DISRUPTIONS matches your expectation based on current replica count. If it shows zero and you expected headroom, reduce minAvailable, increase replicas, or switch to maxUnavailable.

Remove or adjust a PDB

Applying a PDB changes cluster state. To remove it:

kubectl delete pdb api-min-available -n default

To adjust it, edit the manifest and reapply, or use kubectl patch pdb. Removing the PDB restores default behavior: voluntary disruptions are not blocked by a budget.