Kubernetes has introduced a PodDisruptionBudget, which prevents the functionality of our applications from being disrupted through manual and automatic vertical (node) scaling.
Let's assume we're using a HozirontalPodAutoscaler. What would be the value of using a PDB additionally? What is the difference between PodDisruptionBudget minAvailable
and HozirontalPodAutoscaler minReplicas
?
They do different things. The HorizontalPodAutoscaler controls the Deployment's replicas:
count based on some metric. The PodDisruptionBudget principally affects whether or not a node can be taken offline.
Let's imagine that you have a cloud-hosted cluster, and your cluster administrator wants to upgrade the base operating system on the cluster nodes. To do this they need to "cordon" each node – prevent new Pods from being scheduled there – and "drain" it – relocate all of the Pods that are located there – before they can restart it.
Meanwhile, let's also imagine that your application Deployment has replicas: 3
, a PodDisruptionBudget that specifies minReplicas: 2
, and it happens that two of the replicas are on the same node that's being terminated. The drain action will delete these replicas and recreate them on a different node. The PDB will keep one of the replicas running until the other has been deleted and recreated.
+--------------+ +--------------+
| Healthy node | | Drained node |
+--------------+ +--------------+
| pod-1 | | pod-2 | <-- PDB keeps this replica alive
| | |~pod-3~~~~~~~~| while this Pod is deleted and recreated
+--------------+ +--------------+
You "should" have a PodDisruptionBudget, but outside of scenarios like this where a cluster administrator is intentionally deleting nodes, you won't notice it.
The PDB is independent of the HPA. The one interaction I'd note is that it doesn't make sense to set the PDB minReplicas:
higher than the HPA minReplicas:
(if you could tolerate autoscaling down to 1 replica, you could support being on 1 replica because of an outage too). If the PDB minReplicas:
is a percentage, it is a percentage of the Deployment's replicas:
, which means it will track changes the HPA makes.