Use PodDisruptionBudget (PDB) to define minimum application availability

A pod disruption budget is used to define number of disruptions that can be tolerated at a given time by a specific set of pods. In simple words, minimum number of pods that should be running or maximum number of pods that can be deleted during voluntary disruptions.

The voluntary disruption means any action in Kubernetes cluster initiated by someone or something that results into deleting the pods running on a given node. For example, during the cluster maintenance, the cluster admin wants to drain the node that results into deleting all the pods running on that node, or the cluster auto scaler is scaling down a node that results into deleting all the pods running on that node.

Implications of not having PDB defined for your application

If your workload does not have PDB defined, it might go offline during cluster maintenance event or scale down action introducing downtime for the application.

Defining PDB for your application

Below is an example of a sample application that defines pod disruption budget.

1. Deployment

The Deployment object defines the application pod and it’s configuration. The application name and label used is app1.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    name: app1
  name: app1
  namespace: ns1
spec:
  selector:
    matchLabels:
      name: app1
  template:
    metadata:
      labels:
        name: app1
    spec:
      containers:
      ...

2. HPA

The HPA object defines the scaling criteria for application pods. The HPA is associated with deployment using the scaleTargetRef tag. Once HPA is associated with deployment, then that deployment can no longer be scaled independently. The OpenShift UI will have the manual scaling of pods disabled as shown below. You won’t see the up and down arrows to scale up or scale down the pod.

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: app1
  labels:
    app: app1
    app.kubernetes.io/instance: app1
  namespace: ns1
spec:
  minReplicas: 2
  maxReplicas: 10
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app1
  targetCPUUtilizationPercentage: 80

3. PDB

The PodDisruptionBudget object defines the criteria for pods to handle disruptions.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: app1
  namespace: ns1
spec:
  minAvailable: 25%
  selector:
    matchLabels:
      app: app1

Assuming the application is running with minimum two pods, one pod can be deleted and created on another node by scheduler during the voluntary disruption as deleting one pod keeps the availability as 50% which is greater than 25% defined in the PDB.