---
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 wires minAvailable, maxUnavailable, and EKS managed node group semantics.
url: https://www.factualminds.com/blog/kubernetes-pod-disruption-budgets-eks-zero-downtime/
datePublished: 2026-06-12T00:00:00.000Z
dateModified: 2026-06-12T00:00:00.000Z
author: Palaniappan P
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 wires 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.

> **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](/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.

```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                          |
| Fargate                           | No DaemonSets; PDB still applies to Fargate pods    |

## 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](/blog/how-to-deploy-eks-karpenter-cost-optimized-autoscaling/).

## What this guide doesn't cover

Service mesh traffic shifting—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.factualminds.com/blog/kubernetes-pod-disruption-budgets-eks-zero-downtime/*