Kubernetes Availability Control Definition

Kubernetes Availability Control Definition is the precise characterization of the PodDisruptionBudget (PDB) as the formal mechanism through which a workload owner constrains how much voluntary disruption a set of Pods may absorb at any one time, distinct from, and unable to prevent, involuntary disruption arising from hardware failure or unexpected node loss. A PodDisruptionBudget does not keep Pods running; it formally restricts the actions of other components, the cluster autoscaler, node drains, and other eviction-initiating operations, that would otherwise be free to disrupt as many matching Pods as scheduling allows.

The Formal Distinction: Voluntary vs. Involuntary Disruption

Voluntary Disruption

Voluntary disruption is formally defined as Pod termination initiated deliberately by an actor operating within the cluster's control, such as a node drain for maintenance, a cluster-autoscaler-initiated scale-down, or an administrator directly evicting a Pod. This category is, by definition, the only category a PodDisruptionBudget governs.

Involuntary Disruption

Involuntary disruption is formally defined as Pod termination arising from events outside any component's deliberate control, a node crashing, a kernel panic, a network partition isolating a node. A PodDisruptionBudget formally has no effect on this category; no configuration of it can prevent a hardware failure from removing Pods.

Formal Structure

minAvailable and maxUnavailable

A PodDisruptionBudget formally specifies exactly one of two mutually exclusive fields: minAvailable, the minimum number or percentage of matching Pods that must remain available after any voluntary disruption, or maxUnavailable, the maximum number or percentage of matching Pods that may be simultaneously unavailable due to voluntary disruption.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: codartium-api-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: codartium-api

Selector-Based Scope

A PodDisruptionBudget formally applies to the set of Pods matching its label selector, independent of which specific workload controller owns them; its scope is defined entirely by labels, the same mechanism Services use, rather than by any direct reference to a Deployment or StatefulSet.

Formal Enforcement Mechanism

The Eviction API

Voluntary disruption is formally required to be requested through the Eviction API rather than a direct delete of the Pod object; any component initiating a voluntary disruption, kubectl drain, the cluster autoscaler, correctly implemented custom automation, must issue an eviction request, which the API server formally checks against all applicable PodDisruptionBudgets before allowing it to proceed.

Rejection, Not Prevention

A PodDisruptionBudget formally causes an eviction request to be rejected, with the requesting component expected to retry later, rather than preventing the underlying operation, a node drain, from being initiated at all; the drain formally pauses at the protected Pod until the budget permits its eviction or the operator intervenes.

kubectl drain node-3 --ignore-daemonsets --delete-emptydir-data
kubectl get pdb -n codartium-team
kubectl describe pdb codartium-api-pdb -n codartium-team

Formal Status Fields

disruptionsAllowed

A PodDisruptionBudget's status.disruptionsAllowed field formally reports how many additional voluntary evictions could currently be accepted without violating the budget, computed continuously from the current count of healthy, matching Pods.

status:
  currentHealthy: 4
  desiredHealthy: 2
  disruptionsAllowed: 2

Interaction with the Cluster Autoscaler

A Formal Precondition for Node Removal

The Cluster Autoscaler is formally required to respect active PodDisruptionBudgets when evaluating whether a node can be safely removed; a node hosting a Pod whose eviction would violate its PodDisruptionBudget is formally excluded from scale-down consideration until that constraint no longer applies.

Why Availability Control Is Formally Scoped This Way

Restricting a PodDisruptionBudget's authority to voluntary disruption alone, rather than attempting to guarantee availability against all forms of failure, reflects a formal boundary of what the mechanism can actually control: voluntary operations originate from within the cluster's own automation and can therefore be paused or rejected, while involuntary failures, by definition, occur outside any component's ability to intercept them in advance.