In Kubernetes, managing downtimes is very critical to maintain High Availability. Pod Disruption Budget (PDB in short) and NodePool Disruption Budget (NDB in short) plays an important role in managing high availability at different layers of Kubernetes.
PDBs ensure that a minimum number of application pods are running when one or more nodes are disrupted voluntarily, for example during cluster upgrades, node drain etc.
You can set pdb value to either "minAvailable
" or "maxUnavailable
".
Here are some example usages of PDB:
By setting "
minAvailable
" to quorum size of 3 when scale is 5 for an etcd cluster, you make sure etcd pods do not reduce below quorum thus keeping the writes from failing.If you only run single replica of your application pod and you don't want voluntary disruptions to terminate the application then set "
maxUnavailable=0
". In this case, you have to manually evict the pod. This allows you to plan for downtime and then delete the pod manually.
PDBs help prevent downtime by ensuring enough replicas are running when the nodes are down voluntarily.
Check the popular statefulsets to see how they have configured pdb in their K8s yamls. Here is one such example from strimzi-kafka-operator.
NodePool Disruption Budgets (NDB) controls how many nodes in a node pool can be disrupted simultaneously, e.g., during rolling updates, Karpenter autoscaling etc.
NodePools and NDBs are part of Karpenter and you must have Karpenter installed in your Kubernetes cluster before configuring NDBs.
Karpenter uses NDBs to rate limit Karpenter's disruption. If undefined, it defaults to "node:10%". NDBs do not prevent Karpenter from terminating expired nodes.
Examples of NDB:
- "
spec.disruption.budgets.nodes: 10%
" will only allow 10% nodes in that nodepool to be disrupted. You can add reasons like "if nodes are Empty" along with 10% limit. - Another example for NDB would be to block node disruption first hour during the day for underutilized nodes using:
- nodes: "0"
schedule: "@daily"
duration: 1h
reasons:
- "Underutilized"
You can attach multiple budgets to the same NDB.
Set "karpenter.sh/do-not-disrupt: true
" to block Karpenter from voluntarily choosing you pod, Deployment, Node or NodePool. Note that setting this annotation does not prevent nodes from forceful disruptions like Expiration, Node Repair etc.
As you can see in the diagram, PDB is attached to specific set of pods using a label selector .spec.selector
. You add NDB budget in the NodePool YAML.
To summarize, use PDB to maintain availability of critical application pods and use NDB to limit disruptions at nodepool level.
By combining both, you can increase your pod availability and cluster stability.
Do you use PDB or NDB? Share your experience in comments!
If you are new to my posts, I regularly post about AWS, EKS, Kubernetes and Cloud computing related topics. Do follow me on LinkedIn and visit my website (https://vijay.eu/posts) where I have all my previous posts at one place.
Top comments (0)