Eviction API requests pass through a PDB budget gate to selected Pods. Direct deletion, normal rolling updates and failures bypass or are not prevented by that gate. Ready does not prove application quorum.

A PodDisruptionBudget limits eviction-based disruption

A PodDisruptionBudget limits eviction-based disruption for a selected group of Pods. It can help preserve serving capacity or quorum during maintenance, but cannot guarantee either. Its protection depends on the caller using the Eviction API, the selector identifying the intended members, and Ready conditions meaning something useful for the application. ...

April 10, 2027 · 4 min · XB Field Notes
Six eligible hostname domains each contain one matching peer, while three of nine replicas remain Pending under required hostname anti-affinity with mutually selected peers.

Pod anti-affinity spreads peers away from each other

Pod anti-affinity expresses where a Pod should avoid selected peers. A hostname topology can reduce shared-node exposure; a zone topology can address a broader failure domain. The rule does not create extra capacity or prove application availability. It shapes placement, while replication, readiness, storage, and failure recovery remain separate responsibilities. ...

March 18, 2027 · 5 min · XB Field Notes
Readiness failure closes ordinary Service routing eligibility while liveness failure can restart the container inside the same Pod.

Readiness changes routing eligibility; liveness restarts a container

Readiness and liveness answer different operational questions. Readiness asks whether this container should contribute to a Pod that accepts ordinary Service traffic now. Liveness asks whether restarting this container is the configured recovery action. Both can use HTTP, but sharing a protocol does not make their meanings interchangeable. Define the action you want before choosing the condition that triggers it. ...

January 13, 2027 · 6 min · XB Field Notes
A counted A-503 attempt leads to B-200 and final success, with a separate exclusion-to-live-traffic path and no periodic-probe implication.

Passive upstream health follows failed traffic, not a probe timer

nginx passive upstream health uses outcomes of real requests to decide whether a peer should temporarily stop receiving traffic. max_fails sets an unsuccessful-attempt threshold, while fail_timeout supplies both the counting interval and the unavailability period. These settings do not schedule periodic application probes. Active checks require a supported checking capability and configuration beyond this passive request-outcome policy. ...

January 5, 2027 · 6 min · XB Field Notes