Practice the vocabulary of protecting a service's availability during a planned cluster disruption.
0 / 5 completed
1 / 5
At standup, a dev mentions a Kubernetes object specifying the minimum number of replicas that must remain available during a voluntary disruption, like a node drain for maintenance. What is this object called?
A PodDisruptionBudget, or PDB, specifies the minimum number of replicas that must remain available during a voluntary disruption, like a node drain performed for planned maintenance. A resource limit constraining CPU and memory addresses a completely different concern and doesn't protect availability during a disruption. This object is what lets Kubernetes' own eviction logic respect a service's availability requirement during planned maintenance.
2 / 5
During a design review, the team wants the PDB to apply specifically to a planned node drain or cluster upgrade, while leaving an unplanned node crash entirely outside its scope. Which capability supports this?
The distinction between a voluntary disruption, like a planned node drain or cluster upgrade, and an involuntary one, like an unexpected node crash, is central to what a PDB governs, since it only constrains the former. Treating both types identically misunderstands that a PDB can't prevent or delay an unplanned crash from happening in the first place. This distinction is essential to setting the right expectation for what a PodDisruptionBudget actually protects against.
3 / 5
In a code review, a dev notices the PDB is configured with a minAvailable value rather than a maxUnavailable value, requiring at least that many replicas to stay up throughout a voluntary disruption. What does this represent?
The minAvailable field sets a floor on the number of replicas that must remain up throughout a voluntary disruption, and the cluster's eviction logic won't evict a pod if doing so would drop below that floor. Configuring a PDB with no field set at all leaves no actual floor enforced during maintenance. This field, or its counterpart maxUnavailable, is what gives a PDB its concrete, enforceable meaning.
4 / 5
An incident report shows every replica of a service was evicted simultaneously during a routine node drain for cluster maintenance, causing a full outage, because no PodDisruptionBudget had been configured for that service. What practice would prevent this?
Configuring a PodDisruptionBudget with a minAvailable value prevents the cluster's eviction logic from dropping a service below a safe replica floor during a voluntary disruption like a node drain. Draining a node with no PDB configured leaves nothing stopping every replica from being evicted simultaneously, exactly as this incident describes. This configuration is a baseline safeguard any service with an availability requirement needs before a planned maintenance event.
5 / 5
During a PR review, a teammate asks why the team configures a PodDisruptionBudget instead of just relying on running enough total replicas to survive a maintenance event. What is the reasoning?
Replica count alone doesn't stop Kubernetes' own eviction logic from taking down too many replicas at once during a voluntary disruption, since nothing inherently limits how aggressively a drain proceeds without an explicit constraint. A PDB enforces a floor during exactly that scenario, regardless of the total replica count configured elsewhere. The tradeoff is the added configuration of correctly setting a PDB's floor to match a service's actual availability requirement.