Introducing PDB Operator v0.1.0
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:
| Class | minAvailable | Use Case |
|---|---|---|
non-critical | 20% | Batch jobs, dev tools |
standard | 50% | Internal services |
high-availability | 75% | Production APIs |
mission-critical | 90% | Payment, auth, data stores |
custom | User-defined | Full control |
Two-Controller Architecture
PDB Operator runs two controllers that work together:
-
PDBPolicyController watches
PDBPolicyresources, resolves conflicts when multiple policies match a workload (using priority-based resolution), and annotates target deployments with their resolved policy configuration. -
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 describeworkflows
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.
