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.
The most common use case when you want to protect an application specified by one of the built-in Kubernetes controllers:
In this case, make a note of the controller’s
.spec.selector; the same
selector goes into the PDBs
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 Controllers and Selectors.
Decide how many instances can be down at the same time for a short period due to a voluntary disruption.
PodDisruptionBudget has three fields:
.spec.selectorto specify the set of pods to which it applies. This field is required.
.spec.minAvailablewhich is a description of the number of pods from that set that must still be available after the eviction, even in the absence of the evicted pod.
minAvailablecan be either an absolute number or a percentage.
.spec.maxUnavailable(available in Kubernetes 1.7 and higher) which is a description of the number of pods from that set that can be unavailable after the eviction. It can be either an absolute number or a percentage.
Note: For versions 1.8 and earlier: When creating a
PodDisruptionBudgetobject using the
kubectlcommand line tool, the
minAvailablefield has a default value of 1 if neither
You can specify only one of
minAvailable in a single
maxUnavailable can only be used to control the eviction of pods
that have an associated controller managing them. In the examples below, “desired replicas”
scale of the controller managing the pods being selected by the
Example 1: With a
minAvailable of 5, evictions are allowed as long as they leave behind
5 or more healthy pods among those selected by the PodDisruptionBudget’s
Example 2: With a
minAvailable of 30%, evictions are allowed as long as at least 30%
of the number of desired replicas are healthy.
Example 3: With a
maxUnavailable of 5, evictions are allowed as long as there are at most 5
unhealthy replicas among the total number of desired replicas.
Example 4: With a
maxUnavailable of 30%, evictions are allowed as long as no more than 30%
of the desired replicas are unhealthy.
In typical usage, a single budget would be used for a collection of pods managed by a controller—for example, the pods in a single ReplicaSet or StatefulSet.
Note: A disruption budget does not truly guarantee that the specified number/percentage of pods will always be up. For example, a node that hosts a pod from the collection may fail when the collection is at the minimum size specified in the budget, thus bringing the number of available pods from the collection below the specified size. The budget can only protect against voluntary evictions, not all causes of unavailability.
maxUnavailable of 0% (or 0) or a
minAvailable of 100% (or equal to the
number of replicas) may block node drains entirely. This is permitted as per the
You can find examples of pod disruption budgets defined below. They match pods with the label
Example PDB Using minAvailable:
apiVersion: policy/v1beta1 kind: PodDisruptionBudget metadata: name: zk-pdb spec: minAvailable: 2 selector: matchLabels: app: zookeeper
Example PDB Using maxUnavailable (Kubernetes 1.7 or higher):
apiVersion: policy/v1beta1 kind: PodDisruptionBudget metadata: name: zk-pdb spec: maxUnavailable: 1 selector: matchLabels: app: zookeeper
For example, if the above
zk-pdb object selects the pods of a StatefulSet of size 3, both
specifications have the exact same meaning. The use of
maxUnavailable is recommended as it
automatically responds to changes in the number of replicas of the corresponding controller.
You can create the PDB object with a command like
kubectl create -f mypdb.yaml.
You cannot update PDB objects. They must be deleted and re-created.
Use kubectl to check that your PDB is created.
Assuming you don’t actually have pods matching
app: zookeeper in your namespace,
then you’ll see something like this:
$ kubectl get poddisruptionbudgets NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE zk-pdb 2 0 7s
If there are matching pods (say, 3), then you would see something like this:
$ kubectl get poddisruptionbudgets NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE zk-pdb 2 1 7s
The non-zero value for
ALLOWED-DISRUPTIONS means that the disruption controller has seen the pods,
counted the matching pods, and updated the status of the PDB.
You can get more information about the status of a PDB with this command:
$ kubectl get poddisruptionbudgets zk-pdb -o yaml apiVersion: policy/v1beta1 kind: PodDisruptionBudget metadata: creationTimestamp: 2017-08-28T02:38:26Z generation: 1 name: zk-pdb ... status: currentHealthy: 3 desiredHealthy: 3 disruptedPods: null disruptionsAllowed: 1 expectedPods: 3 observedGeneration: 1
You can skip this section if you only use PDBs with the built-in application controllers (Deployment, ReplicationController, ReplicaSet, and StatefulSet), with the PDB selector matching the controller’s selector.
You can use a PDB with pods controlled by another type of controller, by an “operator”, or bare pods, but with these restrictions:
.spec.minAvailablecan be used, not
.spec.minAvailable, not a percentage.
You can use a selector which selects a subset or superset of the pods belonging to a built-in controller. However, when there are multiple PDBs in a namespace, you must be careful not to create PDBs whose selectors overlap.