What does a PodDisruptionBudget actually protect against?

It protects against voluntary disruptions only, things Kubernetes itself initiates or allows, like node drains during cluster upgrades, cluster autoscaler scale-downs, or `kubectl drain`. It has no effect on involuntary disruptions like a node crashing or a Pod being OOM-killed; nothing can prevent those.

Why can I only set minAvailable or maxUnavailable, not both?

Kubernetes' PodDisruptionBudget spec only accepts one or the other, never both in the same object, since they express the same constraint from opposite directions and setting both would be redundant or contradictory.

What's the difference between a count and a percentage value?

A plain integer (like 2) is an absolute number of Pods. A percentage (like 50%) is evaluated against the total number of Pods the selector matches at eviction time, which scales automatically if you later change replica counts, unlike a fixed integer.

What happens if an eviction would violate the budget?

The Kubernetes eviction API rejects the request with a 429 Too Many Requests response, and the voluntary disruption is blocked until enough Pods become available again or the budget is changed.

Kubernetes PodDisruptionBudget Generator

Overview

Introduction

A PodDisruptionBudget is a small manifest, but the minAvailable/maxUnavailable choice and count-vs-percentage distinction trip people up regularly, especially since Kubernetes silently rejects an object that sets both.

This tool generates a PodDisruptionBudget manifest from a form that only lets you pick one mode at a time and validates the value's format, entirely client-side.

What Is Kubernetes PodDisruptionBudget YAML Generator?

A Kubernetes PodDisruptionBudget YAML generator targeting the stable policy/v1 API, which limits how many of a selected set of Pods can be voluntarily disrupted at once.

It supports both PDB modes, minAvailable and maxUnavailable, each accepting either a whole-number count or a percentage string.

How Kubernetes PodDisruptionBudget YAML Generator Works

The selector labels you enter populate spec.selector.matchLabels, defining which Pods this budget applies to, the same label set you'd use on a Deployment or its Pod template.

The mode toggle decides whether the generated manifest's spec block contains minAvailable or maxUnavailable, never both, matching what the Kubernetes API accepts.

The value is validated as either a plain non-negative integer or a percentage string ending in '%' with a number from 0 to 100, then written into the spec exactly as typed.

When To Use Kubernetes PodDisruptionBudget YAML Generator

Use it for any Deployment or StatefulSet where you need a guarantee that cluster maintenance, node drains, or autoscaler scale-downs won't take down too many replicas at once.

It's especially important for anything with fewer replicas or tighter availability requirements, where losing even one or two Pods simultaneously would cause a real outage.

Often used alongside Kubernetes Deployment YAML Generator, Kubernetes HorizontalPodAutoscaler YAML Generator and Kubernetes ResourceQuota YAML Generator.

Features

Advantages

Prevents the invalid-object mistake of setting both minAvailable and maxUnavailable by only letting you configure one mode at a time.
Validates the value format (integer vs. percentage) before you ever try to apply the manifest.
Runs entirely client-side; nothing about your Pod topology or availability requirements is sent anywhere.

Limitations

Doesn't verify that the selector labels actually match any Pods with enough replicas to satisfy the budget you've configured.
Only targets the policy/v1 API; the older policy/v1beta1 API (removed in Kubernetes 1.25) isn't produced.
Doesn't account for unhealthy Pod eviction policy settings (unhealthyPodEvictionPolicy), an optional, more advanced PDB field this generator's form doesn't expose.

Examples

Requiring at least 2 Pods available during voluntary disruption

Input

name: web-pdb, selector: app=web, mode: minAvailable, value: 2

Output

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

A node drain or cluster upgrade can only evict Pods matching app: web as long as at least 2 remain available afterward.

Best Practices & Notes

Best Practices

Match the selector exactly against your Deployment's Pod template labels, the same care needed for a Service's selector.
Prefer a percentage value (like 50%) over a fixed integer for Deployments whose replica count changes over time via an HPA, so the budget scales with it automatically.
Avoid setting minAvailable equal to your total replica count; that blocks all voluntary disruption entirely, including routine node maintenance.

Developer Notes

Validation accepts either a bare non-negative integer string or a percentage string matching 0%-100%, since both are valid IntOrString values for minAvailable/maxUnavailable in the policy/v1 API. The tool enforces the mutual exclusivity Kubernetes' API itself enforces (only one of minAvailable/maxUnavailable may be set) at generation time, rather than letting you produce an object the API server would reject anyway.

Kubernetes PodDisruptionBudget YAML Generator Use Cases

Guaranteeing a minimum number of available replicas for a user-facing service during cluster node maintenance
Allowing a controlled percentage of a large Deployment's Pods to be evicted at once during a cluster autoscaler scale-down
Protecting a small, fixed-replica-count StatefulSet from losing quorum during voluntary disruptions

Common Mistakes

Expecting a PodDisruptionBudget to protect against involuntary disruptions like node crashes or OOM kills; it only governs voluntary, API-initiated evictions.
Setting a minAvailable value that equals or exceeds the total replica count, which effectively blocks all voluntary disruption and can stall cluster upgrades indefinitely.
Forgetting that this budget applies per-selector across the whole namespace, not per-Deployment, so it can unexpectedly interact with any other Pods sharing the same labels.

Tips

Pair this with the Kubernetes HPA Generator: the HPA changes replica count, and a percentage-based PDB scales its protection alongside it automatically.

Kubernetes PodDisruptionBudget YAML Generator