EAI-7854 Skip the keycloak CNPG PDB for a single instance

[pre]

A CloudNativePG Cluster with instances: 1 gets a <name>-primary PodDisruptionBudget at minAvailable: 1, which permits zero disruptions for as long as the cluster stays single-instance.

That PDB protects nothing. There is no second replica to keep serving, so the only thing it can do is refuse. What it refuses is kubectl drain on whichever node the pod happens to sit on, which stalls node maintenance until an operator disables it by hand on the live cluster, out of band from Git.

This came out of a maintenance window on app-install-test, where keycloak/keycloak-cnpg-1 was one of two drain blockers on the node being rebooted. The other was Longhorn's per-node instance-manager PDB, which turned out to be held open by the database pod: Longhorn refuses to release it while volumes are still attached to the node. Clearing the CNPG PDB let the drain evict the database pod, the volumes detached, and Longhorn released its own PDB on the next reconcile.

Change

enablePDB is now rendered on the Cluster, following instances unless set:

cnpg.instances	cnpg.enablePDB	rendered
1	unset	false
2+	unset	true
any	true	true
any	false	false

The default is derived rather than hardcoded, so a cluster scaled to two instances gets its PDB back without a second values change, and the field stays overridable in both directions.

Applied to both charts that render a keycloak-cnpg Cluster:

• sources/keycloak-old is the one wired up via root/values.yaml (path: keycloak-old). It already had a cnpg values block, so this extends it.
• sources/keycloak-config renders the same resource with a fully static manifest and had no values block beyond domain. The cnpg block is introduced there, keeping the two charts identical in behaviour so whichever one is wired up next does not reintroduce the blocker.

enablePDB is CNPG's own recommendation over the alternative. Patching nodeMaintenanceWindow.inProgress instead draws a warning from the operator:

Warning: Consider using `.spec.enablePDB` instead of the node maintenance window feature

It is also the only one of the two that survives ArgoCD. nodeMaintenanceWindow is templated by these charts, so ArgoCD owns it and selfHeal reverts a manual patch within the reconcile interval.

Verification

helm template across the matrix above, run separately for each chart, all five combinations rendering as expected with enablePDB typed !!bool and not a string:

default(instances=1)       enablePDB=false instances=1
explicit-true              enablePDB=true  instances=1
explicit-false             enablePDB=false instances=1
instances=2                enablePDB=true  instances=2
instances=2,pdb=false      enablePDB=false instances=2

For keycloak-old, cnpg.enabled=false still renders no Cluster at all, and helm lint passes.

keycloak-config does not render or lint cleanly on main either: templates/keycloak-realm-templates-cm.yaml fails to parse at line 2123, unchanged by this PR and untouched by it. The matrix above was produced with that one file moved aside; the rest of the chart, including the Cluster, renders correctly.

The rendered manifest was validated against the live CNPG v1.27.0 CRD on the app-install-test cluster with kubectl apply --dry-run=server, which reported configured and converges to the same state as the hand patch currently applied there.

Note on the sibling chart

sources/eai-infra/airm-cnpg is also single-instance with no enablePDB, so it carries the same latent drain blocker. aiwb-cnpg defaults to instances: 3 and is unaffected. Left alone here to keep this PR to the keycloak charts, but worth a follow-up.

[silokimmo]

We could have affinity rules like following:

  affinity:
    enablePodAntiAffinity: true
    topologyKey: {{ .Values.cnpg.affinity.topologyKey }}
    podAntiAffinityType: {{ .Values.cnpg.affinity.podAntiAffinityType }}

  With defaults:
  cnpg:
    affinity:
      topologyKey: kubernetes.io/hostname    # spread across nodes, not zones
      podAntiAffinityType: preferred         # don't block scheduling on single-node clusters

[pre]

We could have affinity rules like following:

yeah, although it should be a separate pull request.

[silokimmo]

LGTM - let's improve also affinity rules