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.
Top comments (0)