volker.raschekandCopilot
6d68d44894
Bash / shellcheck (push) Successful in 7s
Bash / bash-unittest (push) Successful in 25s
changelog / changelog (push) Successful in 15s
Helm / helm-lint (push) Successful in 13s
Helm / helm-unittest (push) Successful in 20s
Markdown linter / markdown-lint (push) Successful in 18s
Markdown linter / markdown-link-checker (push) Successful in 52s
A HA `Cluster` is only actually highly available if its instances end up in different failure domains. Pod
anti-affinity alone cannot express that: it only keeps the instances off the same node, not off the same zone,
and `cloudnativePG.affinity` has no way to encode a skew budget. Without `topologySpreadConstraints` a three
instance cluster can legitimately be scheduled into a single availability zone, where a zone outage takes down
the primary and both replicas at once.
Both `affinity` and `topologySpreadConstraints` are rendered only when they are set. The CloudNativePG API
declares them as `omitempty`, so an empty `{}` or `[]` in the manifest would show up as a permanent diff against
the state the operator writes back.
Tolerations deliberately do not get a dedicated value. CloudNativePG has no `spec.tolerations`, it nests them
below `spec.affinity.tolerations`, so they are configured through `cloudnativePG.affinity` like `nodeSelector`
and the anti-affinity settings. A separate top-level value would only have to be folded back into the same place
and would silently conflict with a tolerations list set via `cloudnativePG.affinity`.
Co-authored-by: Copilot <copilot@github.com>