Troubleshoot a cluster

Use conditions, events, workloads, and dependency checks to isolate an OpenBao failure before recovery.

Updated 9 August 2026 · 2 min read

On this page

Diagnose the failing boundary before changing the resource. status.phase is a summary; condition reason and message, Kubernetes Events, and the affected Pod or Job logs contain the actionable detail.

Collect evidence

inspect

Capture status, events, and workloads

kubectl -n <namespace> get openbaocluster <name> -o yaml
kubectl -n <namespace> describe openbaocluster <name>
kubectl -n <namespace> get pods,pvc,services,networkpolicies -l openbao.org/cluster=<name> -o wide
kubectl -n <namespace> get jobs -l openbao.org/cluster=<name>
kubectl -n <namespace> get events --sort-by=.lastTimestamp

Get logs from the failing container or Job, including the previous container when a Pod restarts:

inspect

Read current and previous logs

kubectl -n <namespace> logs <pod-name> -c openbao
kubectl -n <namespace> logs <pod-name> -c openbao --previous
kubectl -n <namespace> logs job/<job-name>

Route by condition

SignalCheck next
TLSReady=FalseReferenced Secrets, certificate SANs and chain, expiry, and Pod x509 errors
ACMEIntegrationReady=FalseDirectory trust, shared cache, TLS-ALPN reachability on 443, and Gateway passthrough
GatewayIntegrationReady=FalseGateway and GatewayClass prerequisites; inspect Route status separately
APIServerNetworkReady=FalseAPI service CIDR and endpoint IPs required by the CNI’s pre- or post-NAT enforcement
BackupConfigurationReady=FalseOpenBao auth, storage identity, Secret references, and Hardened Job egress
CloudUnsealIdentityReady=FalseWorkload ServiceAccount binding, cloud permission, credentials, and KMS reachability
NodeSecurityCapabilityMismatch=TrueRequested AppArmor or other node hardening is unavailable on scheduled nodes
OpenBaoSealed=TrueRecover a sealed cluster
OpenBaoLeader=False or no active leaderRecover from no leader
Degraded=True with break glassRecover a failed rollback

Observed OpenBaoInitialized, OpenBaoSealed, and OpenBaoLeader conditions come from OpenBao service-registration labels on Pods. Confirm critical incidents with bao status from a reachable Pod.

Check common integration boundaries

For External TLS, confirm the Secret names and keys match the selected configuration. For ACME with a private root, confirm the configured CA bundle. Public ACME also requires external port 443 to reach OpenBao end to end; the operator cannot prove the public firewall path.

For Gateway API, TLS termination in front of an ACME listener is not equivalent to TLS passthrough. Check the actual Route attachment and backend policy, not only GatewayIntegrationReady.

For Kubernetes API egress, some CNIs enforce NetworkPolicy after destination NAT. Add spec.network.apiServerEndpointIPs when the service VIP is allowed but the control-plane endpoint is still blocked. See Configure network policy and Expose OpenBao.

Escalate deliberately

Move to recovery when you have identified a seal dependency, leadership failure, failed rollback, or need for snapshot restore. Do not use restore as a generic diagnostic action: it overwrites current OpenBao state.

If you need to stop operator changes while preserving evidence, use a bounded cluster pause. A pause does not stop Kubernetes controllers or prove the workload is healthy.

Search the handbook

Try “install”, “threat model”, or “compatibility”.