{"id":1990,"date":"2026-02-15T11:53:47","date_gmt":"2026-02-15T11:53:47","guid":{"rendered":"https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/"},"modified":"2026-02-15T11:53:47","modified_gmt":"2026-02-15T11:53:47","slug":"pod-disruption-budget-pdb","status":"publish","type":"post","link":"https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/","title":{"rendered":"What is Pod disruption budget PDB? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide)"},"content":{"rendered":"\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Quick Definition (30\u201360 words)<\/h2>\n\n\n\n<p>A Pod Disruption Budget (PDB) is a Kubernetes API object that limits voluntary disruptions to a set of pods to maintain availability. Analogy: a traffic light that only allows a safe number of cars through an intersection to avoid gridlock. Formal: a PDB controls allowed pod evictions by specifying minAvailable or maxUnavailable.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">What is Pod disruption budget PDB?<\/h2>\n\n\n\n<p>What it is \/ what it is NOT<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>It is a policy object in Kubernetes that governs voluntary disruptions like drain, upgrade, or eviction.<\/li>\n<li>It is NOT a health checker, not a replacement for readiness\/liveness probes, and not a scaling policy.<\/li>\n<li>It does not prevent involuntary disruptions like node hardware failure or kubelet crash.<\/li>\n<\/ul>\n\n\n\n<p>Key properties and constraints<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Defines minAvailable (minimum pods that must remain) or maxUnavailable (maximum pods that can be disrupted).<\/li>\n<li>Applies only to voluntary evictions mediated through the eviction API.<\/li>\n<li>Works at the Pod selector level, often aligned with Deployment\/StatefulSet labels.<\/li>\n<li>PDB enforcement depends on controller behavior and the kube-apiserver eviction subresource.<\/li>\n<li>Interacts with PodDisruptionBudget admission and eviction flow, and with controllers like NodeController, kube-scheduler during node drains.<\/li>\n<li>Does not guarantee zero downtime; it reduces risk during routine maintenance.<\/li>\n<\/ul>\n\n\n\n<p>Where it fits in modern cloud\/SRE workflows<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Used during maintenance windows, cluster upgrades, node autoscaling, and controlled rollouts.<\/li>\n<li>Integrated into CI\/CD pipeline steps that perform rolling upgrades or kube-drain operations.<\/li>\n<li>Tied to SLOs by protecting a minimum capacity so SLIs like availability remain within targets.<\/li>\n<li>Automatable via GitOps, operators, and IaC tooling.<\/li>\n<li>Considered in chaos engineering experiments to simulate safe disruption limits.<\/li>\n<\/ul>\n\n\n\n<p>A text-only \u201cdiagram description\u201d readers can visualize<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cluster with multiple nodes and a ReplicaSet controlling N pods.<\/li>\n<li>A box around the ReplicaSet labelled &#8220;PDB: minAvailable = X&#8221;.<\/li>\n<li>An operator attempts node drain; eviction API consults the PDB.<\/li>\n<li>If evicting would drop pods below X, eviction is delayed until capacity increases or operator overrides.<\/li>\n<li>Continuous feedback loop: controller maintains desired replicas; PDB blocks voluntary evictions as needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pod disruption budget PDB in one sentence<\/h3>\n\n\n\n<p>A PDB is a Kubernetes policy object that restricts voluntary pod evictions to preserve a minimum number of running pods during maintenance and controlled disruptions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pod disruption budget PDB vs related terms (TABLE REQUIRED)<\/h3>\n\n\n\n<p>ID | Term | How it differs from Pod disruption budget PDB | Common confusion\nT1 | Readiness probe | Readiness marks pod traffic eligibility; PDB limits evictions | Confused as a replacement for availability protection\nT2 | Liveness probe | Liveness restarts unhealthy pods; PDB does not restart pods | People expect PDB to fix pod failures\nT3 | HorizontalPodAutoscaler | HPA scales pods based on metrics; PDB limits evictions not scaling | Thought to manage capacity automatically\nT4 | PodPriority | Priority affects eviction order for involuntary evictions; PDB handles voluntary evictions | Assumed to block all evictions\nT5 | StatefulSet | Stateful workloads manage identity and order; PDB only controls disruption count | Mistaken as StatefulSet feature\nT6 | ReplicaSet | ReplicaSet maintains replicas; PDB restricts voluntary disruptions to replicas | Believed to be same concept\nT7 | NodeDrain | Node drain triggers evictions; PDB can block or delay those evictions | Seen as a node-level setting\nT8 | Eviction API | Eviction API performs pod eviction; PDB is consulted during eviction | People think PDB is the API itself\nT9 | PodDisruptionBudget controller | Controller enforces PDB status; PDB is the resource definition | Confusion over controller vs resource\nT10 | PodDisruptionBudget admission | Admission checks evictions; PDB is a resource used by admission | Thought to be all-or-nothing gate<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if any cell says \u201cSee details below\u201d)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Why does Pod disruption budget PDB matter?<\/h2>\n\n\n\n<p>Business impact (revenue, trust, risk)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Availability protects revenue: improper maintenance causing downtime can directly hurt transactions or conversions.<\/li>\n<li>Customer trust: frequent or prolonged visible outages reduce confidence in SLA adherence.<\/li>\n<li>Risk management: PDBs serve as guardrails during upgrades to mitigate human error and automation glitches.<\/li>\n<\/ul>\n\n\n\n<p>Engineering impact (incident reduction, velocity)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reduces change-related incidents by preventing unsafe simultaneous pod evictions.<\/li>\n<li>Enables safer automated rollouts, allowing teams to move faster with fewer production incidents.<\/li>\n<li>Enables targeted exceptions, reducing noisy alerts during planned activities.<\/li>\n<\/ul>\n\n\n\n<p>SRE framing (SLIs\/SLOs\/error budgets\/toil\/on-call)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SLIs impacted: request success rate, request latency at p95\/p99, capacity availability.<\/li>\n<li>SLOs: PDBs support SLO adherence by limiting planned availability loss.<\/li>\n<li>Error budgets: use PDBs during SLO burn rate spikes to be conservative during mitigation.<\/li>\n<li>Toil reduction: automating PDB creation and lifecycle reduces manual steps during deployments.<\/li>\n<\/ul>\n\n\n\n<p>3\u20135 realistic \u201cwhat breaks in production\u201d examples<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Rolling upgrade without PDB: all replicas evicted concurrently causing request failures.<\/li>\n<li>Node autoscaler scales down nodes aggressively; without PDB, critical pods get evicted en masse.<\/li>\n<li>Human operator drains wrong node hosting most replicas of a critical service, causing partial outage.<\/li>\n<li>Chaos engineering experiment kills multiple pods; PDB absent or misconfigured leads to broader degradation.<\/li>\n<li>Cluster upgrade orchestrated by automation disables eviction APIs temporarily and misses PDB enforcement, increasing risk.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Where is Pod disruption budget PDB used? (TABLE REQUIRED)<\/h2>\n\n\n\n<p>ID | Layer\/Area | How Pod disruption budget PDB appears | Typical telemetry | Common tools\nL1 | Edge-network | Protects edge proxy pods during node maintenance | Request success rate, p95 latency | Ingress controllers, metrics\nL2 | Service | Limits disruptions to service replicas during deployments | Replica count, error rate, pod evictions | Deployments, GitOps\nL3 | App | Applied to stateless app replicas to preserve availability | Requests per pod, CPU, mem | HPA, CI\/CD\nL4 | Data | Used cautiously with stateful DB pods and leader election | Replica availability, leader changes | StatefulSets, operators\nL5 | IaaS | Interacts with node lifecycle actions like autoscaler | Node eviction attempts, scale events | Cloud autoscaler logs\nL6 | PaaS | Appears as cluster-managed PDBs for tenant workloads | Tenant availability metrics | Managed k8s control planes\nL7 | CI-CD | Created as part of deployment pipelines for safe rollout | Deployment progress, evictions | ArgoCD, Flux, pipelines\nL8 | Observability | Used to interpret eviction-related alerts and dashboards | Eviction counts, PDB status | Prometheus, Grafana\nL9 | Incident response | Used in runbooks to pause automated drains or adjust PDBs | Alert counts, SLO burn | Pager, incident tooling\nL10 | Security | Limits maintenance that could reduce security agent coverage | Agent pod availability | Pod security controls, scanners<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">When should you use Pod disruption budget PDB?<\/h2>\n\n\n\n<p>When it\u2019s necessary<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Critical customer-facing services where any removal of capacity risks SLO violation.<\/li>\n<li>Stateful services with limited replicas or leader-dependent behavior.<\/li>\n<li>During cluster maintenance, node upgrades, or automated autoscaling that could evict pods.<\/li>\n<\/ul>\n\n\n\n<p>When it\u2019s optional<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Non-critical batch processing that can tolerate temporary disruptions.<\/li>\n<li>Highly replicated stateless services with fast restart times and cheap replicas.<\/li>\n<\/ul>\n\n\n\n<p>When NOT to use \/ overuse it<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Over-constraining small clusters preventing autoscaler from reclaiming nodes.<\/li>\n<li>Applying strict PDBs to every service causing capacity fragmentation.<\/li>\n<li>Using PDBs instead of fixing root causes like slow pod startup or unhealthy readiness.<\/li>\n<\/ul>\n\n\n\n<p>Decision checklist<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If service SLO requires &gt;= X% availability and replicas &lt; 5 -&gt; Use PDB.<\/li>\n<li>If pods restart quickly and load balancer gracefully handles transient loss -&gt; Optional.<\/li>\n<li>If autoscaler needs node reclamation to reduce cost -&gt; Consider relaxed PDB or dynamic PDB logic.<\/li>\n<\/ul>\n\n\n\n<p>Maturity ladder: Beginner -&gt; Intermediate -&gt; Advanced<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Beginner: Create basic PDBs for tier-1 services with minAvailable set to N-1.<\/li>\n<li>Intermediate: Integrate PDB lifecycle with GitOps and deployment pipelines.<\/li>\n<li>Advanced: Automate dynamic PDB adjustments based on current cluster capacity, SLO burn rate, and cost signals.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How does Pod disruption budget PDB work?<\/h2>\n\n\n\n<p>Explain step-by-step<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Author defines PDB with a selector and minAvailable or maxUnavailable.<\/li>\n<li>PDB controller computes current healthy pods matching the selector and updates PDB status.<\/li>\n<li>When a voluntary eviction is attempted via eviction API (node drain, controller eviction), admission checks current PDB status.<\/li>\n<li>If eviction would violate minAvailable, admission rejects eviction or delays it; the caller receives an error.<\/li>\n<li>Controllers can retry evictions; operators typically retry after waiting or adjusting PDB.<\/li>\n<li>If controller increases replica count or new pods arrive, the PDB status updates and pending evictions may proceed.<\/li>\n<\/ul>\n\n\n\n<p>Components and workflow<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Resources: PodDisruptionBudget object, pods with labels, controllers creating evictions.<\/li>\n<li>Actors: kube-apiserver eviction admission, PDB controller, node drain\/kubectl, cluster autoscaler.<\/li>\n<li>Feedback loop: PDB status is updated and used as source-of-truth for eviction decisions.<\/li>\n<\/ul>\n\n\n\n<p>Data flow and lifecycle<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create PDB -&gt; PDB controller computes expectedAllowedDisruptions -&gt; Status set -&gt; Eviction request arrives -&gt; Admission queries PDB status -&gt; Eviction allowed or denied -&gt; Kubernetes continues.<\/li>\n<\/ul>\n\n\n\n<p>Edge cases and failure modes<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Stale PDB status due to API server lag causing temporary wrong eviction decisions.<\/li>\n<li>Evictions from controllers that bypass eviction API (rare; requires admin privileges) causing unexpected pod loss.<\/li>\n<li>Too-strict PDBs blocking autoscaler leading to excessive cost.<\/li>\n<li>PDB interacting with PodPriority: involuntary evictions can ignore PDB depending on priority and protection.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical architecture patterns for Pod disruption budget PDB<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Pattern: Basic protection for tier-1 deployments<\/li>\n<li>When to use: Simple services with 2\u20135 replicas.<\/li>\n<li>Pattern: PDB + HPA-aware rolling upgrades<\/li>\n<li>When to use: Auto-scaled services that need safe maintenance.<\/li>\n<li>Pattern: Dynamic PDB via operator<\/li>\n<li>When to use: Large clusters where PDBs adjust based on node capacity.<\/li>\n<li>Pattern: PDBs integrated into GitOps<\/li>\n<li>When to use: Teams practicing declarative operations and controlled deployments.<\/li>\n<li>Pattern: Canary + PDB<\/li>\n<li>When to use: Progressive rollouts where canaries must not be evicted early.<\/li>\n<li>Pattern: StatefulSet leader-aware PDB<\/li>\n<li>When to use: Databases or systems using leader election to keep quorum.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Failure modes &amp; mitigation (TABLE REQUIRED)<\/h3>\n\n\n\n<p>ID | Failure mode | Symptom | Likely cause | Mitigation | Observability signal\nF1 | Eviction blocked | Drains fail with error about PDB | PDB minAvailable too high | Lower PDB or scale replicas | Eviction denial logs\nF2 | Autoscaler stuck | Nodes not reclaimed | PDB prevents pod movement | Adjust PDB or set Pod disruption exemptions | Node scale events stalled\nF3 | Stale status | Evictions allowed incorrectly | API server or controller lag | Investigate control plane latency | PDB status update latency\nF4 | Overuse | Cluster fragmentation and wasted capacity | Too many strict PDBs | Audit and relax noncritical PDBs | Low node utilization\nF5 | Unexpected outage | Involuntary failure ignored PDB | Hardware\/network failure | Improve node redundancy | Increased involuntary evictions\nF6 | Leader election flaps | DB leaders repeatedly change | PDB prevents safe leader failover | Use dedicated PDB strategy for leaders | Election count metric\nF7 | Chaos test fails | Chaos experiment takes down service | PDB absent or mis-specified | Add PDB and test scenarios | Chaos failure rate\nF8 | Security agent loss | Agents evicted during maintenance | PDB not applied to agent pods | Apply PDB or run critical agents as static pods | Agent coverage metric<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Key Concepts, Keywords &amp; Terminology for Pod disruption budget PDB<\/h2>\n\n\n\n<p>Provide a glossary of 40+ terms:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Pod \u2014 Smallest deployable unit in Kubernetes \u2014 Hosts containers \u2014 Misunderstood as equivalent to a process<\/li>\n<li>PodDisruptionBudget \u2014 Kubernetes resource to limit voluntary evictions \u2014 Protects availability \u2014 Misconfigured minAvailable causes blocked actions<\/li>\n<li>minAvailable \u2014 PDB field specifying minimal pods to remain \u2014 Determines safety threshold \u2014 Setting too high blocks maintenance<\/li>\n<li>maxUnavailable \u2014 PDB field specifying maximal disruptions allowed \u2014 Alternative to minAvailable \u2014 Off-by-one errors common<\/li>\n<li>Eviction API \u2014 Subresource used to request pod eviction \u2014 Used by drains and autoscaler \u2014 Bypassing it leads to unexpected deletions<\/li>\n<li>Voluntary disruption \u2014 Planned pod removal like drain \u2014 Affects planned maintenance \u2014 Different from involuntary<\/li>\n<li>Involuntary disruption \u2014 Unplanned pod loss like node crash \u2014 PDB does not protect against this \u2014 Must plan for redundancy<\/li>\n<li>PDB controller \u2014 Component that computes allowed disruptions \u2014 Updates status \u2014 Can lag due to control plane load<\/li>\n<li>Selector \u2014 Label selector in PDB for matching pods \u2014 Determines scope \u2014 Wrong selectors skip intended pods<\/li>\n<li>Pod readiness \u2014 Indicates if pod can receive traffic \u2014 Influences PDB evaluation indirectly \u2014 Readiness misconfig causes downtime<\/li>\n<li>Pod liveness \u2014 Indicates if pod is alive \u2014 PDB does not act based on liveness probes \u2014 Liveness restarts may change counts<\/li>\n<li>ReplicaSet \u2014 Controller ensuring desired replica count \u2014 Works with PDB but not constrained by it \u2014 Can recreate pods that PDB blocks eviction for<\/li>\n<li>Deployment \u2014 Higher-level controller for rolling updates \u2014 Uses eviction APIs during rollout \u2014 PDBs affect deployment speed<\/li>\n<li>StatefulSet \u2014 Controller for stateful workloads with ordering \u2014 PDB must consider ordering and leader election \u2014 Misuse can break quorums<\/li>\n<li>Cluster autoscaler \u2014 Scales nodes based on pod placements \u2014 Interacts with PDB for safe scale-down \u2014 Blocked by strict PDBs<\/li>\n<li>GitOps \u2014 Declarative infrastructure practices \u2014 PDBs managed via GitOps improve consistency \u2014 Drift causes mismatches<\/li>\n<li>Rolling upgrade \u2014 Update strategy replacing pods gradually \u2014 PDB ensures safe minimum availability \u2014 Improper limits halt rollouts<\/li>\n<li>Canary deployment \u2014 Small subset of traffic for a new version \u2014 PDB ensures canaries survive maintenance \u2014 Canaries need separate PDB logic<\/li>\n<li>Blue-green deployment \u2014 Replacement strategy swapping environments \u2014 PDB may be unnecessary if switching traffic elsewhere \u2014 Requires capacity planning<\/li>\n<li>Leader election \u2014 Pattern for single-leader services \u2014 PDB must protect leader availability \u2014 Flapping causes outages<\/li>\n<li>Quorum \u2014 Minimum replicas for consensus systems \u2014 PDB should preserve quorum \u2014 Losing quorum causes data unavailability<\/li>\n<li>ReadinessGate \u2014 Mechanism to block readiness until external checks pass \u2014 Works with PDB for safe transitions \u2014 Misuse delays rollout unnecessarily<\/li>\n<li>Probes \u2014 Readiness or liveness checks \u2014 Vital for accurate PDB behavior \u2014 Misconfigured probes are common pitfalls<\/li>\n<li>Admission controller \u2014 Component that enforces policies during API requests \u2014 PDB relies on eviction admission \u2014 Custom admission can interfere<\/li>\n<li>PodPriority \u2014 Ranks pods for eviction order \u2014 Interacts with involuntary evictions \u2014 Priority can supersede PDB in some cases<\/li>\n<li>Node drain \u2014 Operation to evict pods from a node \u2014 PDB can block it \u2014 Drains require planning<\/li>\n<li>Eviction denial \u2014 Response from API indicating eviction blocked \u2014 Sign of PDB enforcement \u2014 Needs human or automated resolution<\/li>\n<li>AllowedDisruptions \u2014 Computed count of how many pods can be evicted \u2014 Derived by PDB controller \u2014 Miscalculations cause surprises<\/li>\n<li>Observability \u2014 Monitoring, logging, tracing \u2014 Essential to detect PDB impacts \u2014 Gaps cause delayed detection<\/li>\n<li>SLIs \u2014 Service Level Indicators like availability \u2014 PDB protects SLIs during planned changes \u2014 Wrong SLI selection misdirects effort<\/li>\n<li>SLOs \u2014 Service Level Objectives defining targets \u2014 PDB helps meet SLOs during maintenance \u2014 Overfitting PDB to SLO causes cost<\/li>\n<li>Error budget \u2014 Allowable SLO breach quota \u2014 Use to decide maintenance windows and PDB relaxation \u2014 Misuse can hide systemic issues<\/li>\n<li>Toil \u2014 Repetitive manual work \u2014 Automate PDB lifecycle for toil reduction \u2014 Manual PDB ops cause errors<\/li>\n<li>Chaos engineering \u2014 Fault injection practice \u2014 PDBs must be considered to keep chaos experiments safe \u2014 Ignoring PDB leads to catastrophic experiments<\/li>\n<li>Observability signal \u2014 Metric or log indicating state \u2014 PDB-specific signals include eviction denials \u2014 Missing signals mean blind spots<\/li>\n<li>Admission webhook \u2014 Extensible admission logic \u2014 May alter eviction behavior \u2014 Complex policies can conflict with PDB<\/li>\n<li>Static pod \u2014 Pods managed directly by kubelet \u2014 Not governed by PDB \u2014 Often used for critical agents to avoid eviction<\/li>\n<li>DaemonSet \u2014 Ensures one pod per node \u2014 PDB not applicable to daemonset pods \u2014 Use alternatives for agent protection<\/li>\n<li>Operator \u2014 Controller that implements application-specific logic \u2014 Can implement dynamic PDB logic \u2014 Complexity increases maintenance<\/li>\n<li>Cluster capacity \u2014 Total nodes and allocatable resources \u2014 PDB should be aware to avoid cost vs safety trade-offs \u2014 Capacity shortage forces choices<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How to Measure Pod disruption budget PDB (Metrics, SLIs, SLOs) (TABLE REQUIRED)<\/h2>\n\n\n\n<p>ID | Metric\/SLI | What it tells you | How to measure | Starting target | Gotchas\nM1 | Eviction denial rate | How often evictions are blocked | Count eviction API denials per hour | &lt; 1 per 24h for critical services | Denials may be spikes during maintenance\nM2 | AllowedDisruptions remaining | Current disruption headroom | Query PDB status.allowedDisruptions | &gt;=1 for planned change | Can be zero if misconfigured\nM3 | Voluntary eviction latency | Time from eviction request to completion | Time difference eviction-&gt;pod termination | &lt; 2m for noncritical | Controller retries affect metric\nM4 | Pod availability SLI | Fraction of successful requests served | Successful requests \/ total | 99.9% for tier1 (example) | Must define what counts as success\nM5 | Cluster drain failures | Drains failing due to PDB | Count failed drains per month | 0 expected for planned drains | Some failures expected during lots of changes\nM6 | PDB status update lag | Time to reflect actual pods in PDB status | Observe lastTransitionTime vs now | &lt; 30s control plane latency | Control plane load increases lag\nM7 | Node reclaim delays | Time autoscaler waits due to PDB | Time between desired node deletion and completion | &lt; 10m typically | Large clusters may need more tolerance\nM8 | Replica loss incidents | Incidents where replicas dropped below threshold | Count incidents per quarter | 0 for critical services | Hard to attribute without labels\nM9 | SLO burn due to maintenance | Portion of error budget consumed during planned ops | SLO error budget calculations during maintenance | Keep under 10% of budget | Requires accurate SLI mapping\nM10 | Chaos experiment impact | Failure rate during chaos tests with PDB | Measure requests failing during experiments | Pass\/fail by baseline | Experiments need control groups<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Best tools to measure Pod disruption budget PDB<\/h3>\n\n\n\n<h3 class=\"wp-block-heading\">Tool \u2014 Prometheus<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Pod disruption budget PDB: eviction counts, pod status, PDB status metrics exposed by controllers.<\/li>\n<li>Best-fit environment: Kubernetes clusters with metrics scraping.<\/li>\n<li>Setup outline:<\/li>\n<li>Enable kube-state-metrics.<\/li>\n<li>Scrape PDB and pod metrics.<\/li>\n<li>Create recording rules for eviction denials.<\/li>\n<li>Expose metrics to dashboards or alerting rules.<\/li>\n<li>Strengths:<\/li>\n<li>Flexible query language.<\/li>\n<li>Widely used in cloud-native stacks.<\/li>\n<li>Limitations:<\/li>\n<li>Requires maintenance and tuning.<\/li>\n<li>High cardinality metrics can be costly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tool \u2014 Grafana<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Pod disruption budget PDB: Visualizes Prometheus metrics into dashboards for PDB signals.<\/li>\n<li>Best-fit environment: Teams using Prometheus\/TSDB.<\/li>\n<li>Setup outline:<\/li>\n<li>Connect to Prometheus data source.<\/li>\n<li>Build executive, on-call, and debug dashboards.<\/li>\n<li>Configure panel thresholds and annotations.<\/li>\n<li>Strengths:<\/li>\n<li>Highly customizable dashboards.<\/li>\n<li>Alerting integrations.<\/li>\n<li>Limitations:<\/li>\n<li>Dashboards require curation.<\/li>\n<li>Not a metric source itself.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tool \u2014 kube-state-metrics<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Pod disruption budget PDB: Exposes PDB object state and counts for scraping.<\/li>\n<li>Best-fit environment: Kubernetes monitoring pipeline.<\/li>\n<li>Setup outline:<\/li>\n<li>Deploy kube-state-metrics.<\/li>\n<li>Ensure PDB metrics exposed are enabled.<\/li>\n<li>Map metrics to Prometheus recording rules.<\/li>\n<li>Strengths:<\/li>\n<li>Lightweight and Kubernetes-native.<\/li>\n<li>Limitations:<\/li>\n<li>Only exposes state; you need aggregator and storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tool \u2014 Cluster autoscaler logs\/metrics<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Pod disruption budget PDB: Node reclamation delays and blocked scale-down attempts due to PDB.<\/li>\n<li>Best-fit environment: Cloud clusters using autoscaler.<\/li>\n<li>Setup outline:<\/li>\n<li>Enable autoscaler metrics.<\/li>\n<li>Correlate blocked scale-down events with PDB metrics.<\/li>\n<li>Strengths:<\/li>\n<li>Direct insight into cost-related impacts.<\/li>\n<li>Limitations:<\/li>\n<li>Tool-specific metrics vary.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tool \u2014 Incident management (Pager, Ticketing)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Pod disruption budget PDB: Incidents attributed to PDB-related blocking and change failures.<\/li>\n<li>Best-fit environment: Teams managing SRE incidents.<\/li>\n<li>Setup outline:<\/li>\n<li>Tag incidents with PDB cause.<\/li>\n<li>Create runbook references.<\/li>\n<li>Use for postmortem analysis.<\/li>\n<li>Strengths:<\/li>\n<li>Human context and timeline.<\/li>\n<li>Limitations:<\/li>\n<li>Manual attribution may be incomplete.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Recommended dashboards &amp; alerts for Pod disruption budget PDB<\/h3>\n\n\n\n<p>Executive dashboard<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels:<\/li>\n<li>Cluster-level PDB headroom summary (number of PDBs with zero allowed disruptions) \u2014 shows business risk.<\/li>\n<li>SLO compliance trends highlighting maintenance windows \u2014 measures impact.<\/li>\n<li>Node scale events vs blocked events \u2014 cost implication.<\/li>\n<li>Why:<\/li>\n<li>Provides leadership visibility into availability risk and cost trade-offs.<\/li>\n<\/ul>\n\n\n\n<p>On-call dashboard<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels:<\/li>\n<li>Eviction denials with timestamps and affected services \u2014 quick triage.<\/li>\n<li>Pod availability SLI panels p95\/p99 latency and error rates \u2014 identify immediate user impact.<\/li>\n<li>PDB status per namespace and selector \u2014 determines who to notify.<\/li>\n<li>Why:<\/li>\n<li>Provides actionable data for remediation and routing.<\/li>\n<\/ul>\n\n\n\n<p>Debug dashboard<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels:<\/li>\n<li>Per-deployment PDB.allowedDisruptions and pod counts \u2014 root cause diagnosis.<\/li>\n<li>Eviction request logs and admission traces \u2014 track failed attempts.<\/li>\n<li>Autoscaler blocked events and node drain attempts \u2014 correlation with scaling.<\/li>\n<li>Why:<\/li>\n<li>Used by engineers to pinpoint misconfigurations and race conditions.<\/li>\n<\/ul>\n\n\n\n<p>Alerting guidance<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What should page vs ticket:<\/li>\n<li>Page: Eviction denials for critical services causing SLO burns or blocked rollouts during on-call hours.<\/li>\n<li>Ticket: Noncritical PDB denials or repeated small denials during maintenance windows.<\/li>\n<li>Burn-rate guidance:<\/li>\n<li>If SLO burn rate &gt; 2x baseline because of maintenance, page and pause further disruptive operations.<\/li>\n<li>Noise reduction tactics:<\/li>\n<li>Deduplicate alerts by service and namespace.<\/li>\n<li>Group alerts by root cause like &#8220;PDB blocked cluster drain&#8221;.<\/li>\n<li>Suppress alerts during approved maintenance windows or annotate incidents for suppressed alerts.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Implementation Guide (Step-by-step)<\/h2>\n\n\n\n<p>1) Prerequisites\n&#8211; Kubernetes cluster access with RBAC rights to create PDBs.\n&#8211; kube-state-metrics and metrics pipeline in place.\n&#8211; Owners and deployment processes documented.<\/p>\n\n\n\n<p>2) Instrumentation plan\n&#8211; Identify critical services and their owners.\n&#8211; Map SLIs and SLOs to services.\n&#8211; Decide on minAvailable or maxUnavailable per service.<\/p>\n\n\n\n<p>3) Data collection\n&#8211; Deploy kube-state-metrics.\n&#8211; Scrape PDB metrics and pod metrics into Prometheus.\n&#8211; Collect eviction API logs and controller events.<\/p>\n\n\n\n<p>4) SLO design\n&#8211; Define availability SLOs influenced by PDBs.\n&#8211; Build error budget rules around maintenance windows.<\/p>\n\n\n\n<p>5) Dashboards\n&#8211; Implement executive, on-call, and debug dashboards.\n&#8211; Add PDB-specific panels like allowedDisruptions and eviction denials.<\/p>\n\n\n\n<p>6) Alerts &amp; routing\n&#8211; Alert on eviction denials impacting critical services.\n&#8211; Route to service owner on-call, with escalation paths.<\/p>\n\n\n\n<p>7) Runbooks &amp; automation\n&#8211; Create runbooks for handling blocked drains, adjusting PDBs, and emergency overrides.\n&#8211; Automate PDB lifecycle via GitOps and CI pipelines.<\/p>\n\n\n\n<p>8) Validation (load\/chaos\/game days)\n&#8211; Perform canary and chaos experiments to verify PDB behavior.\n&#8211; Run game days simulating node drains and autoscaler events.<\/p>\n\n\n\n<p>9) Continuous improvement\n&#8211; Review PDB-related incidents monthly.\n&#8211; Reconcile PDB definitions with scaling and cost goals.<\/p>\n\n\n\n<p>Include checklists:\nPre-production checklist<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Owners assigned and contacted.<\/li>\n<li>kube-state-metrics and monitoring pipelines configured.<\/li>\n<li>PDB definitions reviewed and tested in staging.<\/li>\n<li>Runbooks written and accessible.<\/li>\n<li>Canary\/rollback strategy defined.<\/li>\n<\/ul>\n\n\n\n<p>Production readiness checklist<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Metrics and alerts active.<\/li>\n<li>SLO and error budget mappings validated.<\/li>\n<li>Escalation contacts and runbooks present.<\/li>\n<li>Automation for PDB changes gated via PR reviews.<\/li>\n<\/ul>\n\n\n\n<p>Incident checklist specific to Pod disruption budget PDB<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identify service and PDB in effect.<\/li>\n<li>Check PDB.allowedDisruptions and pod counts.<\/li>\n<li>Determine if eviction was voluntary or involuntary.<\/li>\n<li>Decide to relax PDB, scale replicas, or delay maintenance.<\/li>\n<li>Document decisions and update postmortem.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Use Cases of Pod disruption budget PDB<\/h2>\n\n\n\n<p>Provide 8\u201312 use cases:<\/p>\n\n\n\n<p>1) Canary-safe rollouts\n&#8211; Context: Progressive rollout using canaries.\n&#8211; Problem: Canary pods evicted during maintenance, losing test traffic.\n&#8211; Why PDB helps: Protects canary pods until evaluation complete.\n&#8211; What to measure: Canary survival rate, eviction denials.\n&#8211; Typical tools: Deployments, Service mesh metrics, PDB.<\/p>\n\n\n\n<p>2) Database quorum protection\n&#8211; Context: Distributed DB requiring quorum.\n&#8211; Problem: Losing nodes causes split-brain or unavailability.\n&#8211; Why PDB helps: Preserves quorum during planned actions.\n&#8211; What to measure: Leader changes, replica availability.\n&#8211; Typical tools: StatefulSet, operator, PDB.<\/p>\n\n\n\n<p>3) Node autoscaler safe-downscale\n&#8211; Context: Cost-driven autoscaler removes nodes.\n&#8211; Problem: Autoscaler evicts critical pods causing outages.\n&#8211; Why PDB helps: Prevents scale-down that would violate availability.\n&#8211; What to measure: Blocked scale-down events, node reclaim delays.\n&#8211; Typical tools: Cluster autoscaler, kube-state-metrics.<\/p>\n\n\n\n<p>4) Agent\/telemetry stability\n&#8211; Context: Security or telemetry agents must remain online.\n&#8211; Problem: Agents evicted leading to observability gaps.\n&#8211; Why PDB helps: Guarantees minimum agent coverage.\n&#8211; What to measure: Agent pod availability, telemetry gaps.\n&#8211; Typical tools: DaemonSets for agents, static pods, PDB for agents where appropriate.<\/p>\n\n\n\n<p>5) Maintenance window enforcement\n&#8211; Context: Planned maintenance requiring node drains.\n&#8211; Problem: Operators accidentally evict too many replicas.\n&#8211; Why PDB helps: Blocks unsafe simultaneous drains.\n&#8211; What to measure: Eviction denial counts, successful drains.\n&#8211; Typical tools: kubectl drain, maintenance runbooks, PDB.<\/p>\n\n\n\n<p>6) Multi-tenant cluster safety\n&#8211; Context: Several teams share cluster.\n&#8211; Problem: One tenant&#8217;s drains affect another&#8217;s services.\n&#8211; Why PDB helps: Tenants define PDBs to protect their workloads.\n&#8211; What to measure: Cross-namespace eviction impacts.\n&#8211; Typical tools: Namespaces, RBAC, PDBs per tenant.<\/p>\n\n\n\n<p>7) Blue\/green failover assurance\n&#8211; Context: Traffic switch between environments.\n&#8211; Problem: Evicting old environment causes partial outages during switch.\n&#8211; Why PDB helps: Ensures minimal capacity during transition.\n&#8211; What to measure: Traffic success rate during swap.\n&#8211; Typical tools: Ingress, feature flags, PDB.<\/p>\n\n\n\n<p>8) Chaos engineering safety net\n&#8211; Context: Controlled fault injection.\n&#8211; Problem: Experiments accidentally degrade critical services.\n&#8211; Why PDB helps: Caps the extent of planned disruptions.\n&#8211; What to measure: Experiment failure rate and SLO impact.\n&#8211; Typical tools: Chaos tools, PDB, incident logging.<\/p>\n\n\n\n<p>9) Rolling upgrade speed control\n&#8211; Context: Automating upgrade pipelines.\n&#8211; Problem: Too-aggressive parallelism causes outages.\n&#8211; Why PDB helps: Limits parallel evictions to safe band.\n&#8211; What to measure: Deployment duration vs SLO impact.\n&#8211; Typical tools: CI\/CD, PDB, controllers.<\/p>\n\n\n\n<p>10) Emergency migration coordination\n&#8211; Context: Preemptive node maintenance for security patch.\n&#8211; Problem: Orchestrating controlled pod movement under time pressure.\n&#8211; Why PDB helps: Ensures critical services remain online during migration.\n&#8211; What to measure: Migration success rate, SLA adherence.\n&#8211; Typical tools: Runbooks, PDB, orchestration scripts.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Scenario Examples (Realistic, End-to-End)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #1 \u2014 Kubernetes critical API service rolling upgrade<\/h3>\n\n\n\n<p><strong>Context:<\/strong> A user-facing API served by a Deployment with 4 replicas and p95 SLO.\n<strong>Goal:<\/strong> Perform a rolling upgrade without violating the SLO.\n<strong>Why Pod disruption budget PDB matters here:<\/strong> Prevents more than one replica being evicted concurrently, maintaining capacity.\n<strong>Architecture \/ workflow:<\/strong> Deployment -&gt; Replica pods behind service -&gt; PDB with minAvailable 3 -&gt; CI triggers rollout via GitOps.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create PDB: selector matching deployment and minAvailable: 3.<\/li>\n<li>Update GitOps manifest with new image and PDB.<\/li>\n<li>Trigger rollout and monitor allowedDisruptions.<\/li>\n<li>If eviction denial occurs, pause rollback or scale replicas.\n<strong>What to measure:<\/strong> Eviction denials, request success rate, deployment progress.\n<strong>Tools to use and why:<\/strong> GitOps for declarative change, Prometheus for metrics, Grafana dashboards.\n<strong>Common pitfalls:<\/strong> Wrong selector causing PDB not to apply; too-tight minAvailable blocking upgrades.\n<strong>Validation:<\/strong> Run staging rollout with similar PDB config and simulate node drain.\n<strong>Outcome:<\/strong> Upgrade completed with no SLO violation and predictable deployment time.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #2 \u2014 Serverless-managed PaaS function protection during node upgrades<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Managed Kubernetes offering serverless functions with per-tenant pods.\n<strong>Goal:<\/strong> Ensure tenant-critical functions maintain response SLO during control plane node upgrades.\n<strong>Why Pod disruption budget PDB matters here:<\/strong> Limits voluntary evictions during upstream node maintenance.\n<strong>Architecture \/ workflow:<\/strong> Functions managed as short-lived pods; platform operator applies PDBs per tenant during maintenance windows.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identify high-priority tenants and apply PDB with maxUnavailable 1.<\/li>\n<li>Coordinate maintenance start via platform orchestration.<\/li>\n<li>Monitor function cold-start impact and adjust concurrency.\n<strong>What to measure:<\/strong> Invocation success rate, cold start latency, eviction denials.\n<strong>Tools to use and why:<\/strong> Managed k8s control plane, platform orchestration, monitoring stack.\n<strong>Common pitfalls:<\/strong> Serverless autoscaling conflicting with PDB and causing resource pressure.\n<strong>Validation:<\/strong> Simulate node upgrades in staging with identical traffic patterns.\n<strong>Outcome:<\/strong> Node upgrades proceed with minimal user-visible impact and controlled degradation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #3 \u2014 Incident response: Postmortem after blocked maintenance caused outage<\/h3>\n\n\n\n<p><strong>Context:<\/strong> A scheduled maintenance was blocked due to PDB denials; team forced overrides causing downtime.\n<strong>Goal:<\/strong> Improve process to avoid future forced overrides and outages.\n<strong>Why Pod disruption budget PDB matters here:<\/strong> Denials are a signal that PDB configuration or process needs update.\n<strong>Architecture \/ workflow:<\/strong> PDBs defined per service, ops team drain nodes, denials occur and operator overrides.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Collect timeline from metrics and logs.<\/li>\n<li>Identify which PDBs caused denials and why.<\/li>\n<li>Update runbooks with escalation and replica scaling steps before maintenance.<\/li>\n<li>Implement preflight checks to verify allowedDisruptions &gt;=1.\n<strong>What to measure:<\/strong> Frequency of forced overrides, SLO impact, PDB mismatch occurrences.\n<strong>Tools to use and why:<\/strong> Incident tracker, monitoring, runbook automation.\n<strong>Common pitfalls:<\/strong> Lack of communication between teams owning PDBs and maintenance operators.\n<strong>Validation:<\/strong> Conduct a game day where preflight checks run and verify outcomes.\n<strong>Outcome:<\/strong> New process prevents manual overrides and reduces outage risk.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #4 \u2014 Cost\/performance trade-off with aggressive autoscaler<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Autoscaler aggressively downscales to save costs, causing retries and latency spikes for a service.\n<strong>Goal:<\/strong> Balance cost savings with availability by using PDBs strategically.\n<strong>Why Pod disruption budget PDB matters here:<\/strong> Prevents removal of nodes if it would evict too many replicas for a service.\n<strong>Architecture \/ workflow:<\/strong> Autoscaler considers pod eviction; PDBs per critical service block unsafe scale-down.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Audit critical services and assign PDBs with maxUnavailable tuned to cost\/availability tradeoff.<\/li>\n<li>Create cost-impact dashboard linking blocked scale-down events to billing.<\/li>\n<li>Implement dynamic PDB adjustments during high traffic windows.\n<strong>What to measure:<\/strong> Node reclaim delays, cost savings, SLO impact due to throttled autoscaler.\n<strong>Tools to use and why:<\/strong> Cloud billing, autoscaler metrics, monitoring stack.\n<strong>Common pitfalls:<\/strong> Too many strict PDBs prevent meaningful cost savings.\n<strong>Validation:<\/strong> Run cost simulation and load testing with different PDB settings.\n<strong>Outcome:<\/strong> Improved cost-performance balance with measurable availability guarantees.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Common Mistakes, Anti-patterns, and Troubleshooting<\/h2>\n\n\n\n<p>List 15\u201325 mistakes with:\nSymptom -&gt; Root cause -&gt; Fix (include at least 5 observability pitfalls)<\/p>\n\n\n\n<p>1) Symptom: Drains fail with PDB error -&gt; Root cause: minAvailable equals replica count -&gt; Fix: Set minAvailable lower or scale replicas first.\n2) Symptom: Autoscaler cannot reclaim nodes -&gt; Root cause: PDBs block scale-down -&gt; Fix: Relax PDBs for noncritical workloads or use scale-down exemptions.\n3) Symptom: Unexpected downtime during rollout -&gt; Root cause: No PDB and rollout parallelism too high -&gt; Fix: Create PDB and reduce max surge.\n4) Symptom: Eviction denials spike during maintenance -&gt; Root cause: Multiple teams with overlapping PDBs -&gt; Fix: Coordinate maintenance windows and centralize planning.\n5) Symptom: PDB not applying to pods -&gt; Root cause: Selector mismatch -&gt; Fix: Align labels and selectors; test with staging.\n6) Symptom: Metrics missing for PDB analysis -&gt; Root cause: kube-state-metrics not deployed -&gt; Fix: Deploy kube-state-metrics and scrape metrics.\n7) Symptom: High pod restart churn -&gt; Root cause: Liveness probe misconfigured causing churn rather than PDB enforcement -&gt; Fix: Correct probes and increase startupGracePeriod.\n8) Symptom: PDB status shows stale counts -&gt; Root cause: Control plane latency or API server overload -&gt; Fix: Investigate control plane resource usage and API throughput.\n9) Symptom: Observability gap during maintenance -&gt; Root cause: Telemetry agents got evicted -&gt; Fix: Protect agents via DaemonSet or PDB for agent pods where appropriate.\n10) Symptom: Slow eviction completion -&gt; Root cause: Pod terminationGracePeriod too long or preStop hooks blocking -&gt; Fix: Tune grace period and ensure preStop hooks are efficient.\n11) Symptom: PDBs causing capacity fragmentation -&gt; Root cause: Overuse of strict PDBs across many services -&gt; Fix: Audit PDBs and prioritize critical services only.\n12) Symptom: Confusing alerts about PDBs -&gt; Root cause: Poor alert deduplication and grouping -&gt; Fix: Group alerts by root cause and route to service owners.\n13) Symptom: PDB prevents canary from being replaced -&gt; Root cause: Canary uses same PDB as production replicas -&gt; Fix: Create separate PDBs for canaries with tailored limits.\n14) Symptom: Security agents missing on nodes -&gt; Root cause: Agents scheduled as pods without protection -&gt; Fix: Run agents as static pods or DaemonSets.\n15) Symptom: Incident postmortem lacks PDB context -&gt; Root cause: No tagging of incidents with PDB metadata -&gt; Fix: Include PDB references in incident templates.\n16) Symptom: Eviction allowed though PDB should block -&gt; Root cause: Eviction performed by privileged controller bypassing eviction API -&gt; Fix: Tighten RBAC and audit controllers.\n17) Symptom: Frequent leader elections -&gt; Root cause: PDB prevents safe leader replacement -&gt; Fix: Use leader-aware PDB strategy and protected leader scheduling.\n18) Symptom: Overlapping PDBs contradicting -&gt; Root cause: Multiple PDBs selecting same pods -&gt; Fix: Consolidate into one PDB per workload scope.\n19) Symptom: Alerts noisy during maintenance -&gt; Root cause: No maintenance window suppression -&gt; Fix: Use alert suppression and schedule-based silencing.\n20) Symptom: Lack of traceability for PDB changes -&gt; Root cause: PDBs managed ad-hoc without GitOps -&gt; Fix: Manage via GitOps and require PRs.\n21) Symptom: Difficulty attributing SLO burns -&gt; Root cause: Missing correlation between eviction events and SLO metrics -&gt; Fix: Add correlation tags in tracing\/logs.\n22) Symptom: Incorrect expectation of PDB blocking involuntary evictions -&gt; Root cause: Misunderstanding voluntary vs involuntary disruptions -&gt; Fix: Educate teams and document differences.\n23) Symptom: Monitoring dashboards not updated -&gt; Root cause: Missing recording rules for new metrics -&gt; Fix: Add recording rules and test dashboards.\n24) Symptom: Too many PDBs per namespace -&gt; Root cause: Over-segmentation for ease of ownership -&gt; Fix: Rationalize to service-level PDBs.\n25) Symptom: Observability PITFALL \u2014 missing eviction logs -&gt; Root cause: API server audit logs disabled -&gt; Fix: Enable API server audit logs for eviction events.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Best Practices &amp; Operating Model<\/h2>\n\n\n\n<p>Ownership and on-call<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Assign service owners responsible for PDB definitions and updates.<\/li>\n<li>Ensure PDB-related alerts route to the service on-call and cluster ops for escalations.<\/li>\n<\/ul>\n\n\n\n<p>Runbooks vs playbooks<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Runbooks: Step-by-step instructions for routine handling of PDB denials, including safe scaling and temporary relaxation.<\/li>\n<li>Playbooks: Higher-level decision guides for when to override PDBs during emergencies.<\/li>\n<\/ul>\n\n\n\n<p>Safe deployments (canary\/rollback)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use PDBs to protect minimum capacity while allowing gradual rollout.<\/li>\n<li>Incorporate canary-specific PDBs and automated rollback triggers if SLOs breach.<\/li>\n<\/ul>\n\n\n\n<p>Toil reduction and automation<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Manage PDBs declaratively via GitOps.<\/li>\n<li>Automate preflight checks verifying allowedDisruptions before running automations.<\/li>\n<\/ul>\n\n\n\n<p>Security basics<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ensure RBAC restricts who can create\/modify PDBs.<\/li>\n<li>Audit PDB changes via Git history and API server audits.<\/li>\n<\/ul>\n\n\n\n<p>Weekly\/monthly routines<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Weekly: Review PDB denials and blocked drains, assign follow-ups.<\/li>\n<li>Monthly: Audit PDBs for relevance, consolidate where appropriate, and review cost impacts.<\/li>\n<\/ul>\n\n\n\n<p>What to review in postmortems related to Pod disruption budget PDB<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Whether a PDB contributed to or mitigated the incident.<\/li>\n<li>Eviction logs and PDB state timeline.<\/li>\n<li>Owner contact and communication breakdowns.<\/li>\n<li>Recommendations on PDB tuning and process changes.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Tooling &amp; Integration Map for Pod disruption budget PDB (TABLE REQUIRED)<\/h2>\n\n\n\n<p>ID | Category | What it does | Key integrations | Notes\nI1 | Monitoring | Collects PDB and pod metrics | kube-state-metrics, Prometheus | Essential for observability\nI2 | Dashboarding | Visualizes PDB impacts | Prometheus, Grafana | Executive and on-call views needed\nI3 | CI\/CD | Applies PDBs as part of deployments | GitOps systems, pipelines | Declarative management preferred\nI4 | Autoscaler | Scales nodes up\/down respecting PDB | Cluster autoscaler, cloud APIs | Watch for blocked scale-downs\nI5 | Incident mgmt | Handles alerts and runbooks | Pager, ticketing systems | Tag incidents with PDB metadata\nI6 | Chaos engineering | Runs fault injection safely | Chaos tools, PDB-aware experiments | Use PDBs to limit blast radius\nI7 | Operators | Implements dynamic PDB logic | Custom operators, controllers | Advanced use for large clusters\nI8 | Audit | Tracks changes and events | API server audit logs, SIEM | Required for compliance\nI9 | Policy | Enforces PDB standards | Admission controllers, OPA\/Gatekeeper | Prevents risky PDBs\nI10 | Cost management | Shows cost impact of PDBs | Billing, autoscaler metrics | Correlate blocked scale-downs to cost<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Frequently Asked Questions (FAQs)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What exactly does a PDB protect against?<\/h3>\n\n\n\n<p>PDB protects against voluntary pod disruptions like node drains and eviction requests, not hardware or kernel failures.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can PDB prevent all types of outages?<\/h3>\n\n\n\n<p>No. It only limits voluntary evictions. Involuntary events like node hardware failure are outside its scope.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Which is better: minAvailable or maxUnavailable?<\/h3>\n\n\n\n<p>Both express the same constraint; pick whichever is clearer for your team. Use minAvailable for availability-focused thinking.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How does PDB interact with autoscaler?<\/h3>\n\n\n\n<p>Autoscaler checks PDB status when deciding to remove nodes; strict PDBs can block scale-downs and delay reclaiming nodes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can multiple PDBs target the same pod?<\/h3>\n\n\n\n<p>Yes, but multiple PDBs selecting the same pods can cause conflicting allowedDisruptions computations and is not recommended.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Does PodPriority override PDB?<\/h3>\n\n\n\n<p>PodPriority affects involuntary eviction ordering; PDB governs voluntary eviction counts. Priority doesn&#8217;t generally override PDB but influences other eviction paths.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to handle PDBs for stateful sets?<\/h3>\n\n\n\n<p>Protect quorum and leaders by designing PDBs that preserve sufficient replicas and consider leader-aware placement.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Should every service have a PDB?<\/h3>\n\n\n\n<p>No. Only services with availability requirements or those that would be harmed by concurrent evictions should have PDBs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What happens during cluster upgrades?<\/h3>\n\n\n\n<p>PDBs limit how many pods can be evicted during node upgrades; coordinate PDBs with upgrade plan.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to debug eviction denials?<\/h3>\n\n\n\n<p>Check PDB.allowedDisruptions, eviction logs, and kube-state-metrics to identify which PDB blocked the eviction.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Are PDBs audited automatically?<\/h3>\n\n\n\n<p>Not by default; enable API server audit logs and CI\/Git history to track changes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to test PDBs safely?<\/h3>\n\n\n\n<p>Use staging environments and chaos experiments with PDB-aware tooling to test scenarios.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can PDBs be automated?<\/h3>\n\n\n\n<p>Yes. Use operators or CI pipelines to create, update, and remove PDBs based on cluster context.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Do PDBs affect DaemonSets?<\/h3>\n\n\n\n<p>DaemonSets are per-node and typically not subject to PDB; use static pods or other protections for agents.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What\u2019s a common mistake teams make with PDBs?<\/h3>\n\n\n\n<p>Over-constraining many services causing inability to reclaim nodes and increased cost.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to correlate PDBs to SLO breaches?<\/h3>\n\n\n\n<p>Capture eviction events with timestamps and correlate with SLI metrics using traces and logs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Are there cloud-specific behaviors to consider?<\/h3>\n\n\n\n<p>Varies \/ depends for managed control planes; managed offerings may have their own maintenance semantics.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to choose starting targets for SLOs with PDBs?<\/h3>\n\n\n\n<p>Start with conservative SLOs informed by historical data and adjust after testing and analysis.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n\n\n<p>Pod Disruption Budgets are practical, policy-based safeguards that reduce the risk of planned maintenance and automated operations causing user-visible outages. They should be designed with SLOs, automation, and observability in mind. Balancing availability, cost, and velocity requires tested processes, clear ownership, and measured automation.<\/p>\n\n\n\n<p>Next 7 days plan (5 bullets)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Day 1: Inventory critical services and current PDBs; identify gaps.<\/li>\n<li>Day 2: Deploy kube-state-metrics and basic Prometheus rules for PDB metrics.<\/li>\n<li>Day 3: Create PDBs for the top 5 critical services and add to GitOps.<\/li>\n<li>Day 4: Build on-call dashboard and one alert for eviction denials on critical services.<\/li>\n<li>Day 5\u20137: Run a staging game day simulating node drains and validate runbooks; iterate on PDB settings.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Appendix \u2014 Pod disruption budget PDB Keyword Cluster (SEO)<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Primary keywords<\/li>\n<li>Pod disruption budget<\/li>\n<li>Kubernetes PDB<\/li>\n<li>PodDisruptionBudget<\/li>\n<li>PDB Kubernetes<\/li>\n<li>\n<p>minAvailable maxUnavailable<\/p>\n<\/li>\n<li>\n<p>Secondary keywords<\/p>\n<\/li>\n<li>eviction API<\/li>\n<li>allowedDisruptions<\/li>\n<li>kube-state-metrics PDB<\/li>\n<li>PDB best practices<\/li>\n<li>PDB monitoring<\/li>\n<li>PDB metrics<\/li>\n<li>PDB admission<\/li>\n<li>PDB controller<\/li>\n<li>PDB troubleshooting<\/li>\n<li>\n<p>PDB automation<\/p>\n<\/li>\n<li>\n<p>Long-tail questions<\/p>\n<\/li>\n<li>what is a pod disruption budget in kubernetes<\/li>\n<li>how does pod disruption budget work<\/li>\n<li>pod disruption budget examples for deployments<\/li>\n<li>how to monitor pod disruption budgets<\/li>\n<li>pod disruption budget vs readiness probe<\/li>\n<li>how to measure PDB impact on SLOs<\/li>\n<li>should I use PDB for statefulset<\/li>\n<li>pod disruption budget and cluster autoscaler interaction<\/li>\n<li>PDB allowedDisruptions meaning<\/li>\n<li>PDB eviction denied troubleshooting<\/li>\n<li>how to automate PDB creation with GitOps<\/li>\n<li>best practices for PDBs in production<\/li>\n<li>pod disruption budget failure modes<\/li>\n<li>PDB and chaos engineering safety<\/li>\n<li>PDB dynamic adjustment operator<\/li>\n<li>how to test pod disruption budget in staging<\/li>\n<li>what happens when PDB blocks drain<\/li>\n<li>PDB vs pod priority and preemption<\/li>\n<li>PDB for telemetry agents<\/li>\n<li>\n<p>minAvailable vs maxUnavailable examples<\/p>\n<\/li>\n<li>\n<p>Related terminology<\/p>\n<\/li>\n<li>readiness probe<\/li>\n<li>liveness probe<\/li>\n<li>ReplicaSet<\/li>\n<li>StatefulSet<\/li>\n<li>Deployment<\/li>\n<li>horizontal pod autoscaler<\/li>\n<li>cluster autoscaler<\/li>\n<li>kubelet<\/li>\n<li>kube-apiserver<\/li>\n<li>admission controller<\/li>\n<li>GitOps<\/li>\n<li>canary deployment<\/li>\n<li>blue-green deployment<\/li>\n<li>chaos engineering<\/li>\n<li>leader election<\/li>\n<li>quorum<\/li>\n<li>service level indicators<\/li>\n<li>service level objectives<\/li>\n<li>error budget<\/li>\n<li>node drain<\/li>\n<li>eviction denial<\/li>\n<li>allowed disruptions<\/li>\n<li>kube-state-metrics<\/li>\n<li>Prometheus<\/li>\n<li>Grafana<\/li>\n<li>runbook<\/li>\n<li>playbook<\/li>\n<li>incident response<\/li>\n<li>API server audit logs<\/li>\n<li>operator<\/li>\n<li>RBAC<\/li>\n<li>PDB controller<\/li>\n<li>PDB status<\/li>\n<li>voluntary disruption<\/li>\n<li>involuntary disruption<\/li>\n<li>eviction latency<\/li>\n<li>pod priority<\/li>\n<li>node reclaim delay<\/li>\n<li>maintenance window<\/li>\n<li>outage mitigation<\/li>\n<li>observability signal<\/li>\n<li>telemetry gaps<\/li>\n<li>autoscaler blocked events<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>&#8212;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[149],"tags":[],"class_list":["post-1990","post","type-post","status-publish","format-standard","hentry","category-terminology"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v26.5 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>What is Pod disruption budget PDB? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - SRE School<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"What is Pod disruption budget PDB? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - SRE School\" \/>\n<meta property=\"og:description\" content=\"---\" \/>\n<meta property=\"og:url\" content=\"https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/\" \/>\n<meta property=\"og:site_name\" content=\"SRE School\" \/>\n<meta property=\"article:published_time\" content=\"2026-02-15T11:53:47+00:00\" \/>\n<meta name=\"author\" content=\"Rajesh Kumar\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Rajesh Kumar\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"31 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/\",\"url\":\"https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/\",\"name\":\"What is Pod disruption budget PDB? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - SRE School\",\"isPartOf\":{\"@id\":\"https:\/\/sreschool.com\/blog\/#website\"},\"datePublished\":\"2026-02-15T11:53:47+00:00\",\"author\":{\"@id\":\"https:\/\/sreschool.com\/blog\/#\/schema\/person\/0ffe446f77bb2589992dbe3a7f417201\"},\"breadcrumb\":{\"@id\":\"https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/#breadcrumb\"},\"inLanguage\":\"en\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/sreschool.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"What is Pod disruption budget PDB? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide)\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/sreschool.com\/blog\/#website\",\"url\":\"https:\/\/sreschool.com\/blog\/\",\"name\":\"SRESchool\",\"description\":\"Master SRE. Build Resilient Systems. Lead the Future of Reliability\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/sreschool.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/sreschool.com\/blog\/#\/schema\/person\/0ffe446f77bb2589992dbe3a7f417201\",\"name\":\"Rajesh Kumar\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en\",\"@id\":\"https:\/\/sreschool.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/f901a4f2929fa034a291a8363d589791d5a3c1f6a051c22e744acb8bfc8e022a?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/f901a4f2929fa034a291a8363d589791d5a3c1f6a051c22e744acb8bfc8e022a?s=96&d=mm&r=g\",\"caption\":\"Rajesh Kumar\"},\"sameAs\":[\"http:\/\/sreschool.com\/blog\"],\"url\":\"https:\/\/sreschool.com\/blog\/author\/admin\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"What is Pod disruption budget PDB? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - SRE School","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/","og_locale":"en_US","og_type":"article","og_title":"What is Pod disruption budget PDB? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - SRE School","og_description":"---","og_url":"https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/","og_site_name":"SRE School","article_published_time":"2026-02-15T11:53:47+00:00","author":"Rajesh Kumar","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Rajesh Kumar","Est. reading time":"31 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/","url":"https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/","name":"What is Pod disruption budget PDB? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - SRE School","isPartOf":{"@id":"https:\/\/sreschool.com\/blog\/#website"},"datePublished":"2026-02-15T11:53:47+00:00","author":{"@id":"https:\/\/sreschool.com\/blog\/#\/schema\/person\/0ffe446f77bb2589992dbe3a7f417201"},"breadcrumb":{"@id":"https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/#breadcrumb"},"inLanguage":"en","potentialAction":[{"@type":"ReadAction","target":["https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/sreschool.com\/blog\/pod-disruption-budget-pdb\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/sreschool.com\/blog\/"},{"@type":"ListItem","position":2,"name":"What is Pod disruption budget PDB? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide)"}]},{"@type":"WebSite","@id":"https:\/\/sreschool.com\/blog\/#website","url":"https:\/\/sreschool.com\/blog\/","name":"SRESchool","description":"Master SRE. Build Resilient Systems. Lead the Future of Reliability","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/sreschool.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en"},{"@type":"Person","@id":"https:\/\/sreschool.com\/blog\/#\/schema\/person\/0ffe446f77bb2589992dbe3a7f417201","name":"Rajesh Kumar","image":{"@type":"ImageObject","inLanguage":"en","@id":"https:\/\/sreschool.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/f901a4f2929fa034a291a8363d589791d5a3c1f6a051c22e744acb8bfc8e022a?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f901a4f2929fa034a291a8363d589791d5a3c1f6a051c22e744acb8bfc8e022a?s=96&d=mm&r=g","caption":"Rajesh Kumar"},"sameAs":["http:\/\/sreschool.com\/blog"],"url":"https:\/\/sreschool.com\/blog\/author\/admin\/"}]}},"_links":{"self":[{"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/posts\/1990","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/comments?post=1990"}],"version-history":[{"count":0,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/posts\/1990\/revisions"}],"wp:attachment":[{"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/media?parent=1990"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/categories?post=1990"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/tags?post=1990"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}