Increase your application availability with a PodDisruptionBudget on Azure Kubernetes Service

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.

-> https://www.danielstechblog.io/high-available-control-plane-with-istio-1-5-on-azure-kubernetes-service/

Istio PDB Kubernetes output

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.

Facebooktwitterlinkedinmail