Skip to content

The drain and PodDisruptionBudget contract

This is the one platform rule every workload must follow. Read it before you set a PodDisruptionBudget.

Background: rolling maintenance

Design your applications to take advantage of Kubernetes' availability and scaling features: Deployments, StatefulSets, multiple replicas, and Horizontal Pod Autoscaling. Keep applications stateless and use external storage for persistent data so they can scale and recover gracefully. The Twelve-Factor App methodology is a solid starting point.

Sunet handles maintenance and rolling updates of the underlying infrastructure without prior notice. We never perform updates that bring down the entire cluster, but individual nodes may briefly restart during the process, so your applications need to handle this.

Pod Disruption Budgets

Kubernetes lets you protect workloads from voluntary disruption with a PodDisruptionBudget (PDB). PDBs are useful, but the platform reserves the right to drain any node at any time for maintenance, and drain must be able to succeed. A PDB that can never let a pod be evicted will block the entire cluster's maintenance schedule.

Not allowed. These PDBs cannot tolerate eviction and will be treated as a configuration error during maintenance windows:

# A single-replica Deployment + minAvailable: 1.
# Eviction is never allowed; drain fails forever.
apiVersion: apps/v1
kind: Deployment
metadata: {name: my-app}
spec:
  replicas: 1
  ...
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: {name: my-app}
spec:
  minAvailable: 1
  selector: {matchLabels: {app: my-app}}

# maxUnavailable: 0 never allows any pod to go down.
spec:
  maxUnavailable: 0

Recommended patterns:

# Multi-replica + relative budget, so drain can take one pod at a time.
spec:
  replicas: 3
---
spec:
  maxUnavailable: 1   # or minAvailable: 2

# Single-replica workload that genuinely cannot be HA (legacy app etc.):
# omit the PDB entirely. The pod will be restarted on another node
# during drain; expect a brief outage. Use a readiness probe so
# traffic stops before the pod is killed.

If you operate a stateful workload that requires multiple replicas to remain available (a database with quorum, for example), set the PDB to maxUnavailable: 1 against an N≥3 StatefulSet. That tolerates drain and protects the quorum.

Summary: every workload on the platform must be drain-tolerant. Either run multiple replicas with a PDB that allows at least one disruption, or accept eviction on a single replica with no PDB. PDBs that block all eviction are not supported.