Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.shiftlabs.dev/llms.txt

Use this file to discover all available pages before exploring further.

Pod Disruption Budgets (PDBs) limit the number of pods that can be simultaneously unavailable during voluntary disruptions like node drains, cluster upgrades, or rolling deployments.

​
Key Concepts

PDB

A policy that ensures a minimum number of pods remain available during voluntary disruptions.

Selector

Label selector that identifies which pods are protected by this budget.

Budget

Either minAvailable (minimum pods to keep) or maxUnavailable (maximum pods to disrupt).

Disruptions Allowed

Current number of pods that can be safely disrupted while maintaining the budget.

​
Required Permissions

ActionPermission
View PDBsiam:project:infrastructure:kubernetes:read
Create PDBiam:project:infrastructure:kubernetes:write
Edit PDBiam:project:infrastructure:kubernetes:write
Delete PDBiam:project:infrastructure:kubernetes:delete

​
PDB Status Values

StatusDescription
AllowedDisruptions are allowed (disruptionsAllowed > 0)
BlockedNo disruptions allowed (disruptionsAllowed = 0)
A “Blocked” status means the PDB is protecting pods at the budget limit. Operations like node drains will wait until more pods become available.

​
How to View PDBs

1

Select Cluster

Choose a cluster from the cluster dropdown.
2

Select Namespace

Choose a namespace or select “all” to view PDBs across all namespaces.
3

Search

Use the search box to find PDBs by name or namespace.

​
How to View PDB Details

1

Find the PDB

Locate the PDB in the list.
2

Click PDB Name

Click on the PDB name to open the detail drawer.
3

Review Details

View PDB information including:
  • Overview: Name, namespace, status, age
  • Budget: minAvailable or maxUnavailable setting
  • Pod Counts: currentHealthy, desiredHealthy, expectedPods, disruptionsAllowed
  • Selector: Label selector matching protected pods
  • Conditions: PDB controller conditions
  • Labels & Annotations: Metadata attached to the PDB

​
How to Create a PDB

1

Click Create PDB

Click the Create PDB button in the page header.
2

Write YAML

Enter the PDB manifest in YAML format. Key fields:
  • spec.selector - Label selector for target pods
  • spec.minAvailable - Minimum pods that must be available (integer or percentage)
  • spec.maxUnavailable - Maximum pods that can be unavailable (integer or percentage)
3

Select Namespace

Choose the target namespace for the PDB.
4

Create

Click Create to apply the manifest.
You must specify either minAvailable OR maxUnavailable, not both. Specifying both will result in a validation error.

​
How to Edit a PDB

1

Open Actions Menu

Click the actions menu (three dots) on the PDB row.
2

Click Edit PDB

Select Edit PDB to open the YAML editor.
3

Modify Spec

Edit the PDB specification. Common changes:
  • Adjust minAvailable or maxUnavailable values
  • Update selector labels
  • Modify metadata
4

Save

Click Update to apply changes.

​
How to Delete a PDB

1

Open Actions Menu

Click the actions menu on the PDB row.
2

Click Delete

Select Delete from the menu.
3

Confirm

Confirm the deletion. Pods will no longer be protected from disruptions.
Deleting a PDB removes disruption protection. Voluntary disruptions like node drains can proceed without limits on how many pods go down simultaneously.

​
Budget Types

PDBs support two mutually exclusive budget specifications:

​
minAvailable

Specifies the minimum number of pods that must remain available: 
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
spec:
  minAvailable: 2        # At least 2 pods must be available
  selector:
    matchLabels:
      app: my-app
Or as a percentage: 
spec:
  minAvailable: "50%"    # At least 50% of pods must be available

​
maxUnavailable

Specifies the maximum number of pods that can be unavailable: 
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
spec:
  maxUnavailable: 1      # At most 1 pod can be unavailable
  selector:
    matchLabels:
      app: my-app
Or as a percentage: 
spec:
  maxUnavailable: "25%"  # At most 25% of pods can be unavailable
FieldTypeDescription
minAvailableint or %Minimum pods that must remain available
maxUnavailableint or %Maximum pods that can be unavailable at once
Use percentages for workloads that scale frequently. Use absolute numbers when you need precise control over minimum availability.

​
Pod Counts Explained

FieldDescription
expectedPodsTotal number of pods selected by the PDB
currentHealthyNumber of pods currently in healthy/ready state
desiredHealthyMinimum healthy pods required by the budget
disruptionsAllowedHow many pods can currently be disrupted
Formula: disruptionsAllowed = currentHealthy - desiredHealthy
If disruptionsAllowed is 0, voluntary disruptions are blocked until more pods become healthy or the budget is modified.

​
Troubleshooting

  • Check if a PDB is blocking the drain (disruptionsAllowed = 0)
  • Verify pods are healthy and ready
  • Scale up the deployment temporarily to allow disruption
  • Consider using kubectl drain --disable-eviction for emergencies (bypasses PDB)
  • Verify the selector matches your pod labels
  • Check pods exist in the same namespace as the PDB
  • Use kubectl get pods --selector=<labels> to verify selector
  • Ensure you specify either minAvailable OR maxUnavailable, not both
  • Percentage values must be strings with % suffix (e.g., “50%”)
  • Integer values must be non-negative
  • Selector must be valid label selector syntax
  • This means fewer pods are healthy than required by the budget
  • Check pod health and resolve any pod failures
  • The budget is currently being violated - no disruptions will be allowed
  • PDBs only protect against voluntary disruptions (node drain, delete)
  • Rolling update strategy is separate from PDB
  • Configure maxUnavailable in Deployment spec for rolling updates
  • PDBs don’t prevent involuntary disruptions (node failure, OOM)
  • PDBs can block node upgrades if pods can’t be evicted
  • Ensure replicas > minAvailable to allow rolling evictions
  • Consider temporarily relaxing the PDB during maintenance
  • Scale up workloads before upgrades to allow eviction headroom

​
FAQ

Voluntary: Planned disruptions like node drain, cluster upgrade, pod deletion by admin. PDBs protect against these.Involuntary: Unplanned disruptions like hardware failure, kernel panic, OOM kills. PDBs cannot prevent these.
minAvailable is better when you know the minimum pods needed for availability (e.g., “always need at least 2 pods”).maxUnavailable is better when you want to control disruption rate (e.g., “only disrupt 1 pod at a time”).
Yes, but it’s not recommended. Multiple PDBs selecting the same pods will all be enforced, potentially making eviction impossible. Use a single PDB per workload.
No. Rolling update behavior is controlled by the Deployment’s strategy, not PDBs. PDBs only affect voluntary pod evictions (like node drains), not the deployment controller replacing pods.
No voluntary disruptions will ever be allowed. This blocks node drains and cluster upgrades. Always set minAvailable < replicas to allow rolling operations.
Yes. Both minAvailable and maxUnavailable accept percentages (e.g., “50%”). Percentages are calculated against the total number of pods matching the selector.
policy/v1 is the stable API (Kubernetes 1.21+) and should be used. policy/v1beta1 is deprecated. The main difference is that v1 has an empty selector behavior change.
Yes. PDBs work with any pod controller (Deployments, StatefulSets, DaemonSets, ReplicaSets). The selector just needs to match the pod labels.