minAvailable — the floor on running Pods

The minAvailable field is the PDB’s floor on the number of Pods that must be available at any time. The eviction is rejected if the eviction would reduce the available Pods below the floor. This lesson walks the field’s semantics, the integer and percentage values, the eviction logic, and the design patterns.

The minAvailable field

flowchart TD
    A["Deployment with 5 replicas"] --> B{"minAvailable: 3"}
    B --> C["Available: 5"]
    C --> D["disruptionsAllowed: 2"]
    D -->|Evict 1| E["Available: 4"]
    E -->|Evict 2| F["Available: 3"]
    F -->|Evict 3| G["Available: 2"]
    G -->|REJECTED| H["2 less than 3"]

The PDB’s minAvailable field:

The PDB’s minAvailable field:

spec:
  minAvailable: 3

The field is the minimum number of Pods that must be available at any time. The eviction is rejected if the eviction would reduce the available Pods below the field.

The field is an integer or a percentage string:

minAvailable takes either form. They are alternatives — a PDB sets one or the other, never both:

# absolute number
spec:
  minAvailable: 3
  selector:
    matchLabels: { app: billing }

# percentage of the expected replica count
spec:
  minAvailable: "50%"
  selector:
    matchLabels: { app: billing }

The percentage is computed against status.expectedPods. That is a status field, not something you set: the disruption controller resolves the PDB’s selector back to the workload controller that owns the matching Pods (Deployment, StatefulSet, ReplicaSet) and reads the replica count from it. You configure selector and minAvailable; the controller derives everything else and publishes it under status.

This matters operationally, because it is where PDBs go quietly wrong. If the selector matches Pods owned by no controller — bare Pods, or a workload the controller cannot resolve — the expected count falls back to the number of Pods it can actually see, and the percentage is computed against that. A PDB whose selector has drifted away from its Deployment does not error; it computes a budget against the wrong denominator.

The minAvailable’s semantics

The minAvailable field is the floor on the available Pods. The available Pods are the Pods that are running and healthy. The Pods that are not running (Pending, Failed) are not counted.

For a Deployment with 5 replicas:
  minAvailable: 3
  expectedPods: 5
  availablePods: 5 (all running)
  disruptionsAllowed: 2 (5 - 3)

After evicting 1 Pod:
  availablePods: 4
  disruptionsAllowed: 1 (4 - 3)

After evicting 2 Pods:
  availablePods: 3
  disruptionsAllowed: 0 (3 - 3)

After evicting 3 Pods:
  availablePods: 2
  eviction rejected (2 < 3)

The disruptionsAllowed is the number of Pods that can be evicted before the eviction is rejected.

The minAvailable’s calculation

The minAvailable’s calculation:

disruptionsAllowed = max(0, availablePods - minAvailable)

The disruptionsAllowed is the number of Pods that can be evicted. The disruptionsAllowed is zero when the available Pods is at the minAvailable.

The PDB’s controller recalculates the disruptionsAllowed on every Pod status change. The recalculation is the PDB’s protection.

The minAvailable’s percentage value

The minAvailable’s percentage value:

spec:
  minAvailable: "50%"

The percentage is computed against the expectedPods:

minAvailable (absolute) = ceiling(expectedPods * 50 / 100)

For 5 replicas and 50%: minAvailable = ceiling(2.5) = 3.

The percentage is rounded up. The PDB’s minAvailable is the ceiling of the percentage.

The percentage is the cluster’s protection against the workload’s scale. A Deployment with 10 replicas and minAvailable: 50% has minAvailable: 5. The eviction is allowed until 5 Pods are available.

The minAvailable’s failure modes

The minAvailable’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 minAvailable’s design

The minAvailable’s design should be:

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

For a Deployment with 3 replicas:

spec:
  minAvailable: 2

The minAvailable: 2 allows 1 Pod to be evicted. The drain is allowed; the workload is protected.

For a Deployment with 5 replicas:

spec:
  minAvailable: 4

The minAvailable: 4 allows 1 Pod to be evicted. A node holding two of the five Pods blocks after the first eviction until the replacement reports Ready.

The minAvailable’s design is the operator’s responsibility. The production rule is to design the minAvailable to allow the drain while protecting the workload.

The minAvailable’s anti-patterns

The minAvailable’s anti-patterns:

• minAvailable: 100%. The minAvailable that requires all Pods to be available is a PDB that blocks the drain.
• minAvailable: 0. The minAvailable that requires no Pods to be available is a PDB that does not protect the workload.
• minAvailable: replica_count - 1. The standard pattern. The PDB allows the drain.

The minAvailable’s design is the operator’s responsibility. A percentage is resolved against the controller’s replica count, so minAvailable: 100% blocks every drain however the Deployment is scaled.

The minAvailable’s interaction with the deployment

The minAvailable’s interaction with the deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: billing
spec:
  replicas: 3
  selector:
    matchLabels:
      app: billing
  template:
    metadata:
      labels:
        app: billing
    spec:
      containers:
        - name: billing
          image: registry.example.com/billing:1.0.0
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: billing-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: billing

The PDB’s selector matches the Deployment’s Pods. The PDB’s minAvailable: 2 matches the Deployment’s replica count.

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

The minAvailable’s monitoring

The minAvailable’s monitoring:

kubectl get pdb -A

The output shows the PDB’s status. The PDB’s status shows the current allowed disruptions.

The PDB’s metrics:

promtool query instant http://prometheus:9090 \
  'kube_poddisruptionbudget_status{condition="Disallowed"}'

The metric returns the number of Pods that cannot be evicted. The operator should monitor the metric and alert on the threshold.

Quiz

Production discipline

• The minAvailable is the floor on the available Pods. The eviction is rejected if the eviction would reduce the available Pods below the floor.
• Set the minAvailable to one less than the replica count. The PDB allows the drain while protecting the workload.
• Use the percentage value for elastic workloads. A Deployment with variable replica count should use the percentage value.
• Audit the PDB at every release. The PDB’s configuration should be version-controlled; the audit catches the failures.
• 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.
• Test the PDB in non-production. A staging cluster that mirrors production is the right place to test the PDB.