Specifying a Disruption Budget for your Application [page]deterministic

tasksschedulingobservability

This page shows how to limit the number of concurrent disruptions that your application experiences, allowing for higher availability while permitting the cluster administrator to manage the clusters nodes.

You are the owner of an application running on a Kubernetes cluster that requires high availability.
You should know how to deploy [Replicated Stateless Applications](/docs/tasks/run-application/run-stateless-application-deployment/) and/or [Replicated Stateful Applications](/docs/tasks/run-application/run-replicated-stateful-application/).
You should have read about [Pod Disruptions](/docs/concepts/workloads/pods/disruptions/).
You should confirm with your cluster owner or service provider that they respect Pod Disruption Budgets.

## Protecting an Application with a PodDisruptionBudget

1. Identify what application you want to protect with a PodDisruptionBudget (PDB). 1. Think about how your application reacts to disruptions. 1. Create a PDB definition as a YAML file. 1. Create the PDB object from the YAML file.

## Identify an Application to Protect

The most common use case when you want to protect an application specified by one of the built-in Kubernetes controllers:

Deployment
ReplicationController
ReplicaSet
StatefulSet

In this case, make a note of the controller's `.spec.selector`; the same selector goes into the PDBs `.spec.selector`.

From version 1.15 PDBs support custom controllers where the [scale subresource](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) is enabled.

You can also use PDBs with pods which are not controlled by one of the above controllers, or arbitrary groups of pods, but there are some restrictions, described in [Arbitrary workloads and arbitrary selectors](#arbitrary-controllers-and-selectors).

## Think about how your application reacts to disruptions

Decide how many instances can be down at the same time for a short period due to a voluntary disruption.

Stateless frontends: - Concern: don't reduce serving capacity by more than 10%. - Solution: use PDB with minAvailable 90% for example.
Single-instance Stateful Application: - Concern: do not terminate this application without talking to me. - Possible Solution 1: Do not use a PDB and tolerate occasional downtime. - Possible Solution 2: Set PDB with maxUnavailable=0. Have an understanding (outside of Kubernetes) that the cluster operator needs to consult you before termination. When the cluster operator contacts you, prepare for downtime, and then delete the PDB to indicate readiness for disruption. Recreate afterwards.
Multiple-instance Stateful application such as Consul, ZooKeeper, or etcd: - Concern: Do not reduce number of instances below quorum, otherwise writes fail. - Possible Solution 1: set maxUnavailable to 1 (works with varying scale of application). - Possible Solution 2: set minAvailable to quorum-size (e.g. 3 when scale is 5). (Allows more disruptions at once).
Restartable Batch Job: - Concern: Job needs to complete in case of voluntary disruption. - Possible solution: Do not create a PDB. The Job controller will create a replacement pod.

### Rounding logic when specifying percentages

Values for `minAvailable` or `maxUnavailable` can be expressed as integers or as a percentage.

When you specify an integer, it represents a number of Pods. For instance, if you set `minAvailable` to 10, then 10 Pods must always be available, even during a disruption.
When you specify a percentage by setting the value to a string representation of a percentage (eg. `"50%"`), it represents a percentage of total Pods. For instance, if you set `minAvailable` to `"50%"`, then at least 50% of the Pods remain available during a disruption.

When you specify the value as a percentage, it may not map to an exact number of Pods. For example, if you have 7 Pods and you set `minAvailable` to …(trimmed)