PodDisruptionBudgets — the voluntary disruption limit

A PodDisruptionBudget (PDB) is the cluster’s protection against voluntary disruption. The PDB limits the number of Pods that can be evicted voluntarily (by a node drain, a cluster shutdown, or an upgrade). The PDB does not protect against involuntary disruption (memory pressure, disk pressure). This lesson walks the PDB’s mechanics, the controller, and the operational patterns.

What a PDB is

A PDB is a Kubernetes object (apiVersion: policy/v1, kind: PodDisruptionBudget) that limits the number of Pods that can be evicted voluntarily.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: billing-pdb
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: billing

The PDB’s minAvailable: 3 means at least 3 Pods must be available at any time. The eviction API rejects the eviction if the eviction would reduce the available Pods below 3.

The PDB’s selector specifies the Pods that the PDB applies to. The PDB applies to all Pods with the app=billing label.

What a PDB is not

A PDB is not a protection against involuntary disruption. The PDB does not protect against:

• Memory pressure: the kubelet’s eviction is involuntary. The PDB does not check the kubelet’s eviction.
• Disk pressure: the kubelet’s eviction is involuntary. The kubelet reclaims the node’s disk without consulting the eviction API.
• PID pressure: the kubelet’s eviction is involuntary. The Pod is killed locally; no Eviction request reaches the API server.
• Node failure: the cluster’s eviction is involuntary. The PDB does not check the cluster’s eviction.

The PDB is a contract between the cluster and the workload. The cluster promises not to evict the Pod beyond the PDB’s limit. The cluster can break the contract under involuntary disruption.

The minAvailable and maxUnavailable fields

The PDB’s two fields are mutually exclusive:

spec:
  minAvailable: 3      # at least 3 Pods must be available
  # OR
  maxUnavailable: 1    # at most 1 Pod can be unavailable

The fields are the PDB’s protection level. The production rule is to choose the field that matches the workload’s redundancy.

The minAvailable field is the minimum number of Pods that must be available at any time. The field is an integer or a percentage string.

The maxUnavailable field is the maximum number of Pods that can be unavailable at any time. A percentage is resolved against the controller’s replica count and rounded up.

The PDB’s selector

The PDB’s selector is the Pods that the PDB applies to. The selector is a label selector.

spec:
  selector:
    matchLabels:
      app: billing

The PDB applies to all Pods with the app=billing label. The Pods are scoped to the PDB’s namespace.

The PDB’s selector must match the Pods that the workload manages. A PDB that does not match the Pods is a PDB that does not protect the workload.

The PDB’s status

The PDB’s status shows the current state of the PDB:

status:
  currentHealthy: 5
  desiredHealthy: 3
  expectedPods: 5
  disruptionsAllowed: 0

The fields:

• currentHealthy: the number of currently healthy Pods.
• desiredHealthy: the number of Pods that must be healthy (minAvailable).
• expectedPods: the total number of Pods that the PDB applies to.
• disruptionsAllowed: the number of Pods that can be evicted without violating the PDB.

The disruptionsAllowed is the operator’s primary signal. disruptionsAllowed: 0 means the PDB is saturated; no more evictions are allowed.

The PDB controller

The PDB controller is the eviction controller in the kube-controller-manager. The controller watches the Pod’s status and the PDB’s spec.

The controller’s logic:

flowchart TD
    A[Pod evicted] --> B[Update PDB status]
    B --> C{CurrentHealthy > desiredHealthy?}
    C -->|Yes| D[Allow eviction]
    C -->|No| E[Reject eviction]

The controller’s logic is the cluster’s enforcement of the PDB. The controller is the cluster’s protection against the drain disrupting the workload.

The eviction API’s integration

The eviction API checks the PDB:

sequenceDiagram
    autonumber
    participant O as Operator
    participant API as API server
    participant PDB as PDB controller

    O->>API: evict Pod
    API->>PDB: check PDB
    PDB->>API: can evict?
    API->>O: 200 OK or 403 Forbidden

The eviction API checks the PDB before allowing the eviction. The PDB’s disruptionsAllowed is the primary signal.

The PDB’s failure modes

The PDB’s failure modes:

The diagnostic:

# Substitute your own value before running:
PDB=billing-pdb

kubectl describe pdb "$PDB"

The PDB’s status shows the current state. The fix is to investigate the PDB’s configuration.

The PDB’s anti-patterns

The PDB’s anti-patterns:

• PDB with minAvailable: 100%. The PDB that requires all Pods to be available is a PDB that blocks the drain.
• PDB with minAvailable: 0. The PDB that requires no Pods to be available is a PDB that does not protect the workload.
• PDB with no selector. The PDB that does not select any Pods is a PDB that does not protect the workload.
• PDB with a wrong selector. The PDB that selects the wrong Pods is a PDB that does not protect the workload.

The PDB’s design is the operator’s responsibility. kubectl get pdb reports an ALLOWED DISRUPTIONS column; a value stuck at 0 is a PDB that will block every drain.

The PDB’s design

The PDB’s design should be:

• Permissive enough to allow the drain. The minAvailable should be one less than the replica count; the maxUnavailable should be one.
• Restrictive enough to protect the workload. The minAvailable should be the minimum number of Pods that can serve the workload; the maxUnavailable should be the maximum number of Pods that can be unavailable.

The PDB’s design is the cluster’s protection against the drain disrupting the workload. The production rule is to design the PDB to allow the drain while protecting the workload.

Quiz

Production discipline

• The PDB is the cluster’s protection against voluntary disruption. The PDB is a workload’s contract with the cluster.
• Design the PDB to allow the drain. The minAvailable should be one less than the replica count; the maxUnavailable should be one.
• The PDB is not a protection against involuntary disruption. The cluster can break the contract under involuntary disruption.
• Audit the PDB at every release. The PDB’s configuration should be version-controlled; the audit catches the failures.
• Test the PDB in non-production. A staging cluster that mirrors production is the right place to test the PDB.
• Monitor the PDB’s status. The PDB’s disruptionsAllowed is the operator’s primary signal.
• Document the PDB’s intent. A PDB that does not have a documented intent is a PDB that does not protect the workload.