OpenBAO HA (raft) pods hang at startup due to hardcoded service_registration "kubernetes" #2793

What happened

Deploying the OpenBAO app in HA mode (replicas: 3, raft storage), the pods never become Ready — they stay 0/1 Running: logs stop right after the config banner, bao status times out, and ==> OpenBao server started! is never reached.

Root cause

packages/apps/openbao/templates/openbao.yaml includes service_registration "kubernetes" {} in the HA raft config block (~line 64). At startup OpenBao's kubernetes service registration tries to reach the in-cluster API service VIP; where the pod can't reach it, startup blocks retrying and the listener never serves:

[WARN] service_registration.kubernetes: unable to set initial state due to
GET https://10.96.0.1:443/api/v1/namespaces/<ns>/pods/<pod> giving up after
11 attempt(s): nil response: ..., will retry

The standalone config block in the same template (~line 80) intentionally omits service_registration "kubernetes" {} (with a comment), but the HA path keeps it.

Impact

• HA OpenBAO is unusable where pods can't reach the API service VIP at startup.
• No way to disable it via the OpenBAO CR — the raft config is hardcoded in the template. Working around it requires suspending the HelmReleases and hand-patching the rendered configmap.

Suggested fix

• Make service_registration "kubernetes" optional for the HA/raft config (a value on the OpenBAO app), or drop it from the HA config as done for standalone — it's not required for OpenBao to function (only updates pod labels for the active/standby Services).
• Consider defaulting disable_mlock = true for the raft (integrated storage) config.

Workaround

Remove service_registration "kubernetes" {} from the rendered config (configmap <release>-config, key extraconfig-from-values.hcl) and restart the pods. Since it isn't exposed as a value, the OpenBAO HelmReleases must be suspended first.

Version

OpenBAO app chart (current); OpenBao v2.5.0.