Skip to main content
v0.4.1 · Apache 2.0 · building in the open

Policy-driven availability for every workload

PDB Operator turns availability into a declarative policy. Define the classes once and the operator writes, updates, and cleans up PodDisruptionBudgets for every Deployment, StatefulSet, and LeaderWorkerSet that matches, with enforcement modes teams can work inside, maintenance windows that relax budgets on schedule, and group-aware budgets for multi-host inference. No hand-written PDBs, no stale ones left behind.

PDB Operator
reconciling
CLASSIFYENFORCEMAINTENANCEOBSERVEPRIORITYWEBHOOKCLEANUP
PodDisruptionBudget
checkout-api-pdb
minAvailable 75%
9 held · 3 allowed
PodDisruptionBudget
mysql-pdb
minAvailable 75%
4 held · 1 allowed
PodDisruptionBudget
vllm-deepseek-r1-pdb
minAvailable 24
3 groups · 1 allowed
Coverage

The whole cluster. Under one availability policy.

PDB Operator doesn't replace how you run workloads, it governs their availability across three layers: the workload kinds you deploy, the policy that classifies them, and the operations that keep the budgets honest. Stateless services, stateful data systems, and multi-host inference all resolve through the same policy.

PDB Operator
watchesclassifiesenforcesrelaxesreconcilescleans up
manages
Workloads
kinds it manages
DeploymentStatefulSetLeaderWorkerSet+ any replica count ≥ 2
Policy
classes & enforcement
Availability classes
non-critical · 20%standard · 50%high-availability · 75%mission-critical · 90%custom · your own
Enforcement
strictflexibleadvisory+ priority resolution
Operations
windows & signals
Scheduling
maintenance windowstimezonesdaysOfWeekovernight spans
Observability
PrometheusOpenTelemetryKubernetes eventsJSON logs+ audit trails
Multi-host inference

Groups restart together. So the budget counts groups.

A LeaderWorkerSet group is one unit: under the default RecreateGroupOnPodRestart, evicting a single pod takes down all size pods with it. A percentage of pods both under-protects real capacity and can deadlock a node drain, so PDB Operator quantizes the budget to whole groups instead.

Budget calculation
desiredGroups = ceil(class% × replicas)
                clamped to replicas - 1

minAvailable  = desiredGroups × size
replicas4 groups
size8 hosts
classmission-critical · 90%
minAvailable24

Exactly one group may be disrupted at a time, and a drain always makes progress.

replicas: 1

No PDB is created. Any budget over a single group would block node drains permanently, so the operator emits a Warning event explaining why instead.

size: 1

Plain pod-level semantics, identical to a Deployment. Group quantization only kicks in where groups actually exist.

custom minAvailable

An absolute value is rounded up to the next whole group, so a hand-set budget can never split one.

no LWS CRD

Support is detected at startup. Without leaderworkerset.x-k8s.io/v1 installed the operator runs exactly as before.

Resource API

One API for availability. Serving two roles.

Platform teams

Declare the guardrails. A PDBPolicy selects workloads by label, name, function, or namespace, pins them to an availability class, and sets how strictly that class holds. When several policies match, the highest priority wins.

apiVersion: availability.pdboperator.io/v1alpha1
kind: PDBPolicy
metadata:
  name: production-ha
spec:
  availabilityClass: high-availability
  enforcement: strict
  priority: 100
  workloadSelector:
    matchLabels:
      env: production
    namespaces:
      - production
  maintenanceWindows:
    - start: "02:00"
      end: "04:00"
      timezone: "Europe/Athens"
      daysOfWeek: [0, 6]
Application teams

Work inside them. Under advisory a workload sets its own class freely; under flexible it may raise availability but never fall below the policy floor; under strict the policy is final. Security workloads are boosted automatically.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: auth-service
  annotations:
    pdboperator.io/availability-class: "mission-critical"
    pdboperator.io/workload-function: "security"
    pdboperator.io/workload-name: "auth-service"
    pdboperator.io/override-reason: "PCI scope"
spec:
  replicas: 10
Capabilities

Built for the cluster. Not just the workload.

01Classification

Availability as a class, not a number

Five classes cover the range from batch work at 20% to payment and auth systems at 90%, with custom for full control over minAvailable, maxUnavailable, and unhealthyPodEvictionPolicy. Workloads annotated as a security function are boosted automatically: non-critical becomes 50%, standard becomes 75%.

02Enforcement

Guardrails teams can work inside

strict makes the policy final. flexible lets a team raise availability but never drop below the policy floor. advisory hands control to the workload annotation. Overrides can require a written reason, and every decision is counted as a metric and recorded as a Kubernetes event.

03Maintenance

Relax the budget on schedule

Windows are defined on the policy with a timezone, days of week, and overnight spans, or per workload through an annotation. A workload with a window wakes at the next window start rather than waiting on an unrelated event, so the budget relaxes on time and tightens again when the window closes.

04Observability

Every decision is visible

Prometheus metrics cover reconciliation duration and errors, PDBs created, updated and deleted, managed workloads per class, active policies, compliance status, enforcement decisions, and override attempts. OpenTelemetry tracing turns on with an OTLP endpoint, and logs are structured JSON with correlation IDs and trace context.

Install

One command. Then write a policy.

helm
$ helm install pdb-operator oci://ghcr.io/pdb-operator/charts/pdb-operator \
  --namespace pdb-operator-system --create-namespace
Requires Kubernetes 1.28+ and cert-manager for webhook TLS. On a cluster without cert-manager, add --set webhooks.enabled=false --set certManager.enabled=false. Full install guide →
Open source

Genuinely open. Community driven.

PDB Operator is Apache 2.0 and open source end to end. It runs entirely inside your own cluster, depends on nothing outside it, and manages only the PDBs it created. Governance, roadmap, and security policy are all in the open, and contributions are welcome.