Kubernetes: Use PodDisruptionBudgets for Application Maintenance and Upgrades
In Kubernetes, PodDisruptionBudgets (PDBs) allow application owners to define their cluster operating budgets, limiting the number of Pods of a replicated application that can be taken offline at any given time. Currently in Beta, PDBs are a way to maintain high availability even while introducing regular voluntary disruptions, such as for application upgrades.
Matthew Robson, principal technical account manager at Red Hat, broke down PBDs and their benefits and drawbacks during his lightning talk at KubeCon + CloudNativeCon Virtual Europe 2020.
By Robson’s definition, “A PodDisruptionBudget is an application owner created object that defines the minimum number of replicas that must be available for that application to operate in a stable manner during a voluntary disruption.”
But why would you want to use them? Robson offered four compelling reasons:
- PDBs are owned by the application team, who he says best understand the requirements and performance characteristics of their services.
- PDBs support the operations team by bridging the gap between application knowledge and operational execution.
- PDBs define availability requirements, like those found in the service level agreement, maintaining quorum or the minimum number of pods to support a specific workload.
- PDBs are respected by the Eviction API, which can programmatically cause evictions, which means that kubectl drain, autoscaling, or the descheduler can use these disruption budgets.
Robson also said that PodDisruptionBudgets easily integrate with the most popular controllers like deployment, ReplicationController, StatefulSets, and ReplicaSets.
But he pointed out there can be some downsides to PDBs. This includes involuntary disruptions like node crashes, hardware failures and unpreventable network outages. Disruption budges also cannot avoid explicit scaling to zero or any deleting of pods.
Robson also warns against using PodDisruptionBudgets for single replicas because they become burdensome for the operations team, which forfeits one of their biggest benefits.
In addition, be aware that you have to delete the PDB if you want a drain to occur, lest you end up with indefinite drain hanging.
Robson further warns that, if you are creating multiple disruption budgets, do not overlap the selectors, which confuses things and again leave drains hanging.
When setting up your PodDisruptionBudget, make sure it has a meaningful name that links it to the pods that it oversees. Then give it a matchLabel that corresponds to your particular controller selector.
Your PodDisruptionBudget also needs to set either a minAvailable — also called Desired, establishing the minimum number of pods that must be available — or maxUnavailable — setting the maximum number of pods that can be deleted at any given time.
Then, Robson says, it’s important to leverage the PDB’s voluntary eviction so you can maintain high availability during cluster maintenance and upgrades.
The Cloud Native Computing Foundation and KubeCon + CloudNativeCon are sponsors of The New Stack.
