---
title: Kubernetes Pod Disruption Budgets on EKS: Zero-Downtime Upgrades
description: Cluster upgrades and Karpenter consolidation look healthy in the console while PDB-blocked evictions freeze your node drain for 45 minutes. This guide covers minAvailable, maxUnavailable, and EKS managed node group semantics.
url: https://www.joinhorizon.co/blog/kubernetes-pod-disruption-budgets-eks-zero-downtime/
datePublished: 2026-06-12T00:00:00.000Z
dateModified: 2026-10-28T00:00:00.000Z
author: manojkumar-varatharajan
category: DevOps & CI/CD
tags: engineering-guide, kubernetes, eks, devops, aws
---

# Kubernetes Pod Disruption Budgets on EKS: Zero-Downtime Upgrades

> Cluster upgrades and Karpenter consolidation look healthy in the console while PDB-blocked evictions freeze your node drain for 45 minutes. This guide covers minAvailable, maxUnavailable, and EKS managed node group semantics.

**EKS (June 2026)** control plane upgrades are managed, but **worker disruption** is yours. `PodDisruptionBudget` is the API that tells `kubectl drain` and Karpenter how many pods may disappear during voluntary evictions.

## Symptom → mechanism → AWS control

| Production symptom                      | Mechanism                            | AWS control                                        |
| --------------------------------------- | ------------------------------------ | -------------------------------------------------- |
| 503s during node drain                  | Voluntary disruption evicts all pods | PodDisruptionBudget minAvailable or maxUnavailable |
| PDB blocks node upgrade indefinitely    | Too-strict minAvailable=100%         | minAvailable=80% with HPA headroom                 |
| Single-replica deploy has no PDB effect | PDB requires ≥2 replicas             | HPA minReplicas=2 for production tiers             |

**Opinionated take:** Every production Deployment needs a PDB and minReplicas≥2. EKS managed node upgrades will evict your pods whether you're ready or not.

> **Benchmark pattern (hypothetical workload):** EKS node group upgrade without PDB: 18s API outage; with PDB minAvailable=80% on 10-replica Deployment: 0 failed requests during 15-min rolling node drain; cluster-autoscaler respects PDB evictions.

> **Field note:** FinTech API on EKS (5 replicas, `minAvailable: 5` copied from prod HA doc): node group upgrade **stalled 52 min** waiting for impossible eviction. Changing to `maxUnavailable: 1` allowed rolling drain; error rate stayed **<0.01%**. Pair with [blue-green decision guide](https://www.joinhorizon.co/blog/aws-blue-green-vs-canary-deployment-decision-guide-2026/).

## PDB mechanics

- **Voluntary disruptions**: node drain, `kubectl delete pod`, Karpenter consolidation.
- **Involuntary**: hardware failure, spot interrupt. PDB does not block these.

```yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: api
```

## EKS-specific coupling

| Event                                      | PDB interaction                                                          |
| ------------------------------------------ | ------------------------------------------------------------------------ |
| Managed node group rolling update          | Sequential node replacement; PDB gates pod eviction                      |
| Karpenter drift / consolidation            | Evictions must satisfy PDB                                               |
| Control-plane upgrade rollback (July 2026) | Revert minor-version upgrade within 7 days if PDB-safe drain still fails |
| Fargate                                    | No DaemonSets; PDB still applies to Fargate pods                         |

## AWS services map

| Need                 | Service                 | Skip when                          |
| -------------------- | ----------------------- | ---------------------------------- |
| Managed K8s upgrades | EKS managed node groups | Self-managed ASG with manual drain |
| Disruption control   | PDB + topology spread   | Single-replica dev namespaces      |
| Surge during deploy  | Deployment maxSurge=25% | StatefulSet with strict ordering   |

## When this advice breaks

- **Single-replica Deployments:** PDB cannot invent HA; fix replica count first.
- **Jobs/CronJobs:** PDB usually irrelevant.

## What to do this week

1. Audit workloads with `kubectl get pdb -A` and replica counts.
2. Replace `minAvailable: 100%` with `maxUnavailable: 1` for rolling services.
3. Run controlled drain on one node during low traffic; watch `kube_pod_status_ready`.
4. Align cluster upgrade window with [Karpenter how-to](https://www.joinhorizon.co/blog/how-to-deploy-eks-karpenter-cost-optimized-autoscaling/).

## More in This Track

Part of the **Engineering Guides** library (June 2026).

- Previous: [Part 1](https://www.joinhorizon.co/blog/aws-blue-green-vs-canary-deployment-decision-guide-2026/)
- Next: [Part 3](https://www.joinhorizon.co/blog/service-mesh-traffic-shifting-vpc-lattice-istio-eks/)
- Browse tracks: [Engineering Guides hub](https://www.joinhorizon.co/resources/engineering-guides/)

## What this guide doesn't cover

Service mesh traffic shifting is covered in part 3 of this track.

## FAQ

### What is a sensible PDB for a 3-replica API?
minAvailable: 2 or maxUnavailable: 1, never both ambiguously. For stateful quorum systems, align PDB with Raft/consensus quorum size.

### Do PDBs block Karpenter consolidation?
Yes. Karpenter respects PDBs when evicting pods for node consolidation. Tight PDBs without surplus capacity block cost-saving consolidation and cluster upgrades alike.

---

*Source: https://www.joinhorizon.co/blog/kubernetes-pod-disruption-budgets-eks-zero-downtime/*