Clarify why the two PDBs use different budget fields
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
parent
187e88e5cd
commit
935ffec3b8
|
|
@ -653,8 +653,14 @@ The PDB is only relaxed in two scenarios:
|
||||||
* If a cluster is scaled down to `0` instances (e.g. for draining nodes)
|
* If a cluster is scaled down to `0` instances (e.g. for draining nodes)
|
||||||
* If the PDB is disabled in the configuration (`enable_pod_disruption_budget`)
|
* If the PDB is disabled in the configuration (`enable_pod_disruption_budget`)
|
||||||
|
|
||||||
The PDBs are still in place: the primary PDB with `MinAvailable` set to `0` and the
|
The PDBs are still in place but fully relaxed: the primary PDB with `MinAvailable`
|
||||||
critical operations PDB with `MaxUnavailable` set to `100%`. Disabling PDBs
|
set to `0` and the critical operations PDB with `MaxUnavailable` set to `100%`.
|
||||||
|
The two PDBs intentionally use different budget fields matching their purposes:
|
||||||
|
the primary PDB guarantees a minimum count of always-present pods
|
||||||
|
(`MinAvailable`), while the critical operations PDB freezes disruptions for
|
||||||
|
whatever pods currently carry the `critical-operation=true` label - a
|
||||||
|
usually-empty set, which `MaxUnavailable: 0` expresses without producing an
|
||||||
|
unsatisfiable budget while idle. Disabling PDBs
|
||||||
helps avoiding blocking Kubernetes upgrades in managed K8s environments at the
|
helps avoiding blocking Kubernetes upgrades in managed K8s environments at the
|
||||||
cost of prolonged DB downtime. See PR [#384](https://github.com/zalando/postgres-operator/pull/384)
|
cost of prolonged DB downtime. See PR [#384](https://github.com/zalando/postgres-operator/pull/384)
|
||||||
for the use case.
|
for the use case.
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue