This article will cover the introduction, basics, and usage of Kubernetes Pod distribution Budget.

Prerequisites ✅

• I am assuming that you understand the basics of a Kubernetes cluster like Pod, Deployments, ReplicaSets and more.
• You have worked with Kubernetes enough to understand the problem that controllers can helps us to solve.

Being said that. Let's get started!

Introduction 💡

Kubernetes PodDistributionBudget is an in-built API object that ensures the availability of your applications at all times.

Purpose 🎯

The PDB can be a lifesaver in several situations, such as when the admin accidentally deletes the pod or deployment, or when upgrading a pod template. There are several times that critical deployments take precedence over any other requirement in a cluster. This is an easier way to create immutable and highly available resources. Other cloud-native projects use these. For example, **Elasticsearch **manages a PDB for each resource it manages.

Features ✨

• It is a fail-safe for your critical application on Kubernetes.
• It specifies the minimum number or percentage of replicas that must be up at any time at any cost.
• It ensures running the workload, even in case of any voluntary changes made by cluster admin.
• Although it can’t handle situations like hardware failure, or other system software errors.
• Like any other Kubernetes object, this can be defined as a YAML file. The file has two important aspects.
• First, the label selector points the PDB to the Deployment for which it is written.
• Next, an availability level specifies the minimum number of pods that must be available simultaneously.

Sample YAML

A usual PDB's YAML will look something like this:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: <your-critical-deployment>

Example Situation :

Say, you want to change the container runtime of one of the nodes from Docker to Containerd.
You will need to drain that node. It will affect the pods and the deployments running on them. This node of yours may have multiple deployments, each with several replicasets. Crucial services running on this node might also affect the other microservices, or probably the uptime of the whole infrastructure. Shifting the deployments in such cases will be a hectic task.

Solution :

A PDB will be a saver in this case. When the admin commands to drain the Node, PDB will shift the specified workloads to the node where the deployments will be able to run. The minimum number of pods specified on this node won't terminate unless they have started on some other node. kubectl drain command will affect the rest of the Kubernetes objects. But it will put the status of the node as <Running, SchedulingDisabled>. It means that the node won't be able to schedule anything else on it (unless you uncordon it). This node now just runs the PDB-specified number of pods, thus not affecting the availability of the application. It will deny the admin to delete the pods and the deployments until the workload runs on another node. This is an ensured way to change the node of your cluster while not affecting the availability of your application. The working differs for stateful resources. Also if the controller is managing resources that are out of the jurisdiction of the API server, the process will be a little different.

References 📚

I will add links to most of the topics in case you want to read more on them:

• Must read: Here
• Documentation : Here
• Great example : Here

Thanks for reading my article :)

P.S.: Grateful that you are here.