Skip to main content

Introducing PDB Operator v0.1.0

· 4 min read
Nick Nikolakakis
Lead Maintainer

We're excited to announce the initial release of PDB Operator -a Kubernetes operator that automates PodDisruptionBudget management through policy-driven availability classes.

Why PDB Operator?

PodDisruptionBudgets are critical for maintaining application availability during voluntary disruptions like node drains, cluster upgrades, and rolling deployments. Yet in practice, PDB management is one of the most overlooked areas of Kubernetes operations:

  • Teams forget to create PDBs for new deployments
  • Values are set incorrectly or left at defaults that don't match actual availability requirements
  • Stale PDBs linger after workloads are removed, blocking node drains
  • There's no consistent way to enforce availability standards across namespaces

PDB Operator solves this with a declarative, policy-driven approach. Define your availability requirements once as PDBPolicy resources, and the operator handles the rest.

What's in v0.1.0

Policy-Driven PDB Management

The core abstraction is the PDBPolicy custom resource. A single policy can target workloads across namespaces using label selectors, name patterns, or workload function classifications:

apiVersion: availability.pdboperator.io/v1alpha1
kind: PDBPolicy
metadata:
name: production-ha
spec:
availabilityClass: high-availability
enforcement: strict
workloadSelector:
matchLabels:
env: production

Five built-in availability classes map to minAvailable percentages:

ClassminAvailableUse Case
non-critical20%Batch jobs, dev tools
standard50%Internal services
high-availability75%Production APIs
mission-critical90%Payment, auth, data stores
customUser-definedFull control

Two-Controller Architecture

PDB Operator runs two controllers that work together:

  1. PDBPolicyController watches PDBPolicy resources, resolves conflicts when multiple policies match a workload (using priority-based resolution), and annotates target deployments with their resolved policy configuration.

  2. DeploymentController watches annotated deployments and manages the full PDB lifecycle -creating, updating, and cleaning up PDBs automatically.

This separation ensures clean ownership boundaries and makes the reconciliation logic easier to reason about.

Enforcement Modes

Three enforcement modes control how strictly policies are applied:

  • strict -Annotations cannot override policy settings. The operator is the single source of truth.
  • flexible -Deployment annotations can override availability class and PDB settings, with an optional reason requirement for audit trails.
  • advisory -The operator creates PDBs based on policy defaults but won't block annotation overrides.

Maintenance Windows

Schedule maintenance windows with timezone and day-of-week support. During active windows, PDBs automatically relax to allow smoother node drains:

spec:
maintenanceWindows:
- name: weekly-patch
schedule: "0 2 * * SAT"
duration: 4h
timezone: America/New_York

Smart Workload Classification

The operator automatically classifies workloads by function (core, management, security) and applies function-specific PDB optimization. Security workloads like cert-manager, Falco, and OPA get automatic availability boosting -because your security infrastructure should be the last thing to go down during disruptions.

Full Observability Stack

  • Prometheus metrics -11 metrics covering reconciliation latency, PDB operations, policy compliance, and enforcement actions
  • OpenTelemetry tracing -Distributed tracing via OTLP/gRPC for end-to-end visibility into reconciliation flows
  • Structured logging -JSON-formatted logs with audit trails and correlation IDs
  • Kubernetes events -Policy and PDB lifecycle events for kubectl describe workflows

Production Hardened

  • Admission webhooks for CRD validation and defaulting
  • Leader election for high-availability deployments
  • Circuit breaker pattern protecting the Kubernetes API server
  • Policy caching for efficient reconciliation at scale
  • Health check endpoints (/healthz, /readyz)
  • Multi-architecture images (amd64, arm64) on a distroless base

Getting Started

Install with Helm:

helm install pdb-operator oci://ghcr.io/pdb-operator/charts/pdb-operator \
--namespace pdb-operator-system \
--create-namespace

Or with kubectl:

kubectl apply -f https://raw.githubusercontent.com/pdb-operator/pdb-operator/main/dist/install.yaml

Check out the documentation for the full guide, including quickstart, Helm values reference, and monitoring setup.

Contributing

We welcome contributions! See the Contributing Guide to get started. All commits must be signed off with DCO.