search by tags

for the user

adventures into the land of the command line

pod disruption budgets

pod disruption budgets prevent a service from going down due to voluntary disruptions caused by an application owner:

- 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)

or a cluster administrator:

- 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

with minAvailable:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: rabbitmq-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: rabbitmq

with maxAvailable:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: rabbitmq-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: rabbitmq

deploy it and check. if there are matching pods (say, 3), then you would see something like this:

$ kubectl get poddisruptionbudgets
NAME            MIN-AVAILABLE   ALLOWED-DISRUPTIONS   AGE
rabbitmq-pdb    2               1                     7s

ALLOWED-DISRUPTIONS means that the disruption controller has seen the pods, counted them and updated the status of the pdb. The above means it has counted 3 matching pods. Therefore, with a MIN-AVAILABLE of 2, 1 pod will be allowed to be disrupted.