Before diving into what is pod disruption budget we need to understand two types of disruptions i.e., Voluntary Disruptions & Involuntary Disruptions.

What are disruptions in kubernetes? A disruption is an interrupt or event that has occured and which may lead to destroying of a running pod.

There are two types of disruption in kubernetes which cause pod disruptions:

Involuntary Disruptions:

Cases where unavoidable hardware or system software errors occur, it cause involuntary disruption of a pod. They may be:

• a hardware failure of the physical machine backing the node
• cluster administrator deletes VM (instance) by mistake
• cloud provider or hypervisor failure makes VM disappear
• a kernel panic
• the node disappears from the cluster due to cluster network partition
• eviction of a pod due to the node being out-of-resources.

These disruptions can't be avoided at any cause even by the cluster administrator.

Voluntary Disruptions:

Voluntary Disruptions occur when the Cluster administrator or Application owner perform any of these actions:

• deleting the deployment or other controller that manages the pod
• updating a deployment's pod template causing a restart
• directly deleting a pod
• Draining a node for repair or upgrade.
• Draining a node from a cluster to scale the cluster down.
• Removing a pod from a node to permit something else to fit on that node.

So kubernetes introduced a feature to make our applications highly available even when voluntary disruptions occur which is known as pod disruption budget.

NOTE: Deleting pods or deployments can't be constrained by PodDisruptionBudget.

PodDisruptionBudget (PDB): A PDB limits the number of Pods of a replicated application that are down simultaneously from voluntary disruptions.

For example, a quorum-based application would like to ensure that the number of replicas running is never brought below the number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain percentage of the total.

So now let us get through a demo of how pod disruption budget can be configured for our applications in-order to make our applications highly available in-case of voluntary disruptions.

Configuring PodDisruptionBudget for an application

Currently there are no pods in the cluster

So, let's create an Nginx deployment.

Creating an Nginx Deployment

Now we have the 4 Nginx pods up and running in the node.

Creating a PodDisruptionBudget

A pdb is created by specifying the kind as "PodDisruptionBudget".A pdb template can be written as simple as other templates.

The 2 important fields that need to be looked into are kind which should be "PodDisruptionBudget" and minAvailable which is number of pods you need in running state even after a voluntary disruption occurs. And another field that we need is matchLabels which indicates that for what pod the pdb need to be created. So make sure you use the same labels in your application's deployment file.

Now let's apply the pod disruption budget.

Let's test it by creating a voluntary disruption. By draining a node which is one of the voluntary disruption, the pods present in that node gets evicted. But as we created PodDisruptionBudget with minimum availability of 2 pods we should see 2 pods running always even in the case of voluntary disruptions.

Command to drain a node

kubectl drain node-name --ignore-daemonsets --force

We created the Nginx deployment with 4 replicas and the PodDisruptionBudget with a minimum availability of 2 pods. That is the reason we see 2 pods are evicted successfully and 2 pods have an error when evicting, while draining the node.

So if we look into our pods status we can see 2 pods are ready and in running state even if the node is drained and scheduling is disabled on that node.

Now you can uncordon your node by using the command kubectl uncordon node-name

In this way you can configure PodDisruptionBudget for your pods and make them available when there are voluntary disruptions.

Instead of the field minAvailable we can also use maxUnavailable which specifies the number of pods that can be evicted in-case of disruption. We can also specify the % value(what percentage of pods need to be available or evicted) instead of an integer value for minAvailable or maxUnavailable.

Hope this article helps you in basic understanding of PodDisruptionBudget. Thanks for reading :)

References: https://kubernetes.io/docs/concepts/workloads/pods/disruptions/