Introduction

PodDisruptionBudget, HorizontalPodAutoscaler, and Deployment RollingUpdate all affect availability, but they do not control the cluster in the same way. The key to understanding their interaction is knowing that a PDB governs voluntary disruptions through the eviction path, while HPA and RollingUpdate change the workload’s desired state through its controller.

What Each Controller Is Responsible For

A PodDisruptionBudget, or PDB, protects a minimum amount of availability during voluntary disruptions such as a node drain. It says, in effect, how many matching pods may be disrupted at once.

An HPA changes the replica count of a workload based on metrics.

A Deployment with RollingUpdate controls how old and new ReplicaSets overlap during an application update, mainly through maxSurge and maxUnavailable.

Those are related concerns, but they are not one single scheduling rule.

A Concrete Example

1apiVersion: policy/v1
2kind: PodDisruptionBudget
3metadata:
4  name: web-pdb
5spec:
6  minAvailable: 3
7  selector:
8    matchLabels:
9      app: web
10---
11apiVersion: apps/v1
12kind: Deployment
13metadata:
14  name: web
15spec:
16  replicas: 4
17  strategy:
18    type: RollingUpdate
19    rollingUpdate:
20      maxUnavailable: 1
21      maxSurge: 1

This setup says you want four replicas, at least three available during voluntary disruption, and at most one unavailable during a rolling update.

The Important Interaction Rule

Pods that are unavailable during a rolling update still count as unavailable from the PDB point of view. However, the workload controller is not directly limited by the PDB in the same way that an eviction-based operation such as kubectl drain is.

That leads to the practical rule:

• Use maxUnavailable and maxSurge to control rollout safety.
• Use the PDB to control voluntary evictions such as maintenance drains.
• Use HPA to control scale, knowing it changes the replica target the other rules operate around.

If you expect the PDB alone to prevent an aggressive rollout or scale-down policy, you are likely to be surprised.

How HPA Complicates The Picture

HPA changes the desired replica count over time. If load drops and HPA scales the Deployment down, the availability math changes with it. A percentage-based PDB or rollout configuration may behave differently at 10 replicas than at 3 replicas.

That is why minimum replica settings matter. If a service really needs a floor for safe updates and voluntary disruption, encode that floor in HPA minReplicas, in the rollout strategy, and in the PDB rather than relying on only one of them.

Operational Guidance

A healthy setup usually aligns all three resources around the same business requirement. For example, if the service must keep at least three healthy pods, then:

• HPA should not scale below that floor.
• The rollout strategy should not take more than that budget offline.
• The PDB should reflect the same availability expectation for node drains and other voluntary disruptions.

When those numbers disagree, the cluster behaves correctly from Kubernetes’s perspective but incorrectly from the application owner’s perspective.

Common Pitfalls

One common mistake is assuming a PDB blocks every kind of pod removal. It mainly applies to voluntary disruption through eviction, not as a universal guardrail for all controller actions.

Another mistake is tuning maxUnavailable without considering HPA scale-down behavior. What is safe at a high replica count may be risky at the HPA minimum.

A third issue is using mismatched selectors or inconsistent replica assumptions between the Deployment, HPA, and PDB. The policies then look aligned on paper and protect different pod sets in practice.

Summary

• A PDB protects availability during voluntary disruptions such as node drains.
• RollingUpdate safety is primarily controlled by maxUnavailable and maxSurge.
• HPA changes the replica target, which changes how availability budgets play out over time.
• Treat PDB, HPA, and rollout strategy as coordinated availability controls, not as interchangeable ones.