A Beginner Guide to Kubernetes Pod Disruption Budgets

Kubernetes ships with a good amount of resources to ensure your applications are highly available, from horizontal Pod auto scaling to being able to define a maximum available number of Pods. These primitives ensure your application is available and scales to meet demand as needed.

But how do you prepare for disruptions? In this tutorial, we will explore Pod disruption budgets and how they can enhance your workload resiliency on Kubernetes.

What is a Pod Disruption Budget?

Pod disruption budgets limit the number of Pods of a replicated application that are down simultaneously. The Kubernetes documentation divides disruptions into two categories:

Voluntary disruptions

These include both actions initiated by the application owner and those initiated by a Cluster Administrator. Typical application owner actions include:

• Deleting the deployment or other controller that manages the Pod
• Updating a deployment's Pod template, causing a restart
• Directly deleting a Pod (e.g., by accident)

Involuntary disruptions

These are unavoidable hardware or system software errors. These include but are not limited to:

• A hardware failure of the physical machine backing the node
• The cluster administrator deletes the VM (instance) by mistake
• Cloud provider or hypervisor failure makes the VM disappear
• K kernel panic
• The node disappears from the cluster due to cluster network partition

With an understanding of a Pod disruption budget, let's jump into an example.

Prerequisites

This tutorial assumes a working knowledge of Kubernetes. Additionally, you will need the following installed to follow along:

• Kubectl
• Civo CLI (optional)

Creating a Kubernetes Cluster (Optional)

If you already have a Kubernetes cluster up and running, feel free to skip this step. The important part here is to have a Pod disruption budget available as a resource.

You can verify using the following kubectl command:

kubectl api-resources | grep -i poddisruptionbudgets

Output:

poddisruptionbudgets              pdb          policy/v1                              true         PodDisruptionBudget

If you do not get the output above, you should upgrade your cluster to v1.21 or newer.

To create a cluster using the Civo CLI, run the following command:

civo k3s create --create-firewall --nodes 1 -m --save --switch --wait pdb-civo

This would launch a two-node Kubernetes cluster in your Civo account. The -m flag would merge the kubeconfig for the new cluster with your existing kubeconfig, --switch points your kube-context to the newly created cluster.

Create a Deployment

We begin by creating a deployment in which our Pod disruption budget will target:

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami
  namespace: default
spec:
  replicas: 4
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
        - name: whoami
          image: traefik/whoami
          ports:
            - containerPort: 80 
EOF

This will create a deployment with four replicas of the whoami application.

Create a Pod Disruption Budget

Next, we create a Pod disruption budget that targets the whoami application and specifies the minimum number of available pods to 2.

kubectl apply -f - <<EOF
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: whoami-pdb
  namespace: default
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: whoami
EOF

Verify the PodDisruptionBudget was created:

kubectl  get pdb

Output is similar to:

Simulate a Disruption

Obtain the name of the node your deployment is running on:

export NODE=$(kubectl get pod -l app=whoami -o jsonpath='{.items[0].spec.nodeName}')

Drain the node:

kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data

Output is similar to:

The whoami application is unable to be removed from the form of the node due to the Pod disruption policy we created.

Summary

Kubernetes offers a number of ways to keep your application highly available. In this tutorial, we explored one of the lesser-known features for keeping your applications up and running. Are you interested in learning more about Kubernetes primitives? Check out this guide on admission controllers.