This is the first blog post of a series of posts covering the topic about increasing the application availability on Azure Kubernetes Service / Kubernetes.
Today we cover the PodDisruptionBudget.
What is a PodDisruptionBudget?
A PDB is an additional Kubernetes object that is deployed beside your Deployment, ReplicaSet or StatefulSet increasing your application’s availability. This is done by specifying either the minAvailable or maxUnavailable setting for a PDB. Both settings accept an absolute number or a percentage as value.
When you choose percentage as value Kubernetes rounds up to the nearest integer if your current replica number is uneven.
Assuming you want to specify how many pods must always be available, you choose the minAvailable setting.
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-one-pdb
namespace: app-one
spec:
minAvailable: 50%
selector:
matchLabels:
app: app-one
The other way around with the maxUnavailable setting lets you specify how many pods can be unavailable.
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-two-pdb
namespace: app-two
spec:
maxUnavailable: 2
selector:
matchLabels:
app: app-two
Let me show you a brief example of what this looks like for a highly available Istio control plane setup on my AKS cluster.
As seen in the screenshot, both deployments istio-ingressgateway and istiod allow one disruption running with two replicas each.
> kubectl get poddisruptionbudgets istio-ingressgateway -o yaml
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
labels:
app: istio-ingressgateway
install.operator.istio.io/owning-resource: installed-state
install.operator.istio.io/owning-resource-namespace: istio-system
istio: ingressgateway
istio.io/rev: default
operator.istio.io/component: IngressGateways
operator.istio.io/managed: Reconcile
operator.istio.io/version: 1.7.3
release: istio
name: istio-ingressgateway
namespace: istio-system
spec:
minAvailable: 1
selector:
matchLabels:
app: istio-ingressgateway
istio: ingressgateway
What protection provides a PDB?
A PDB provides protection against so called voluntary evictions.
This can be a cluster upgrade of your AKS cluster for instance. Every node gets replaced after another during the upgrade process by evicting the pods, deleting the node, and bringing up a new one.
-> https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster
Or you use kured (Kubernetes Reboot Daemon) for automatically rebooting your nodes applying the latest security patches. Again, this is done by evicting the pods and then rebooting the node.
-> https://github.com/weaveworks/kured
-> https://docs.microsoft.com/en-us/azure/aks/node-updates-kured
Another scenario is a manual initiated maintenance by running the kubectl drain command.
The PDB does not provide protection against node failures!
Just assume you run at the minimum size specified in the PDB. Then the node with your application pod fails. Your application will then be unavailable for a brief period until it is brought up again by Kubernetes.
Summary
A PDB increases your application availability by protecting the application from voluntary evictions like cluster upgrades or planned node reboots.
But you are not protected against node failures as mentioned above.