Skip to content

Upgrades

Upgrading Wazuh is a single field change. The operator turns it into an ordered, rollout-aware upgrade rather than swapping all images at once.

How to upgrade

kubectl patch wazuhcluster demo -n wazuh-demo --type=merge \
  -p '{"spec":{"version":"4.14.5"}}'

Watch it progress:

kubectl get wazuhcluster -n wazuh-demo -w   # PHASE returns to Ready

What the operator does

  1. The new version flows into every component image (<registry>/wazuh-<component>:<version>).
  2. The indexer is updated first. The reconcile waits for the StatefulSet to roll out at the new revision — it checks observedGeneration, updatedReplicas, and currentRevision == updateRevision, not just readyReplicas. Old-revision pods that are still Ready do not let the upgrade race ahead.
  3. Then the manager master and workers roll (one pod at a time), then the dashboard.
  4. status.observedVersion only advances once every component is on the new version, so the VERSION column always reflects what is actually running.

This indexer → manager → dashboard ordering matches Wazuh's recommended upgrade direction and keeps the indexer ahead of the components that read from and write to it.

Pods keep their PVCs across the rollout, so /var/ossec/etc, logs, API configuration and indexer data are preserved — the same guarantee as Wazuh's manual Kubernetes upgrade.

Config changes also roll pods

The Wazuh images read configuration only at startup. The operator stamps a wazuh.bnerd.com/config-checksum annotation (a hash of the rendered config) onto each pod template, so any config change — including replica-count changes that alter the indexer's cluster.initial_master_nodes — triggers a rolling restart automatically. The checksum is stable for unchanged config, so steady-state reconciles cause no churn.

  1. Snapshot the indexer (manual) and confirm status.phase: Ready.
  2. Bump spec.version; watch the cluster return to Ready.
  3. Verify indexer cluster health and that agents reconnect via the dashboard.
  4. Upgrade agents separately, after the manager is on the new version.

Limitations

  • Downgrades are not supported (Wazuh/OpenSearch do not support them).
  • Cross-major migrations that require a reindex are not orchestrated; plan them manually. For new deployments the operator always issues 4.8+-style certificates, so the pre-4.8.0 certificate-recreation step does not apply.
  • No automated pre-upgrade backup yet — take an indexer snapshot before major upgrades.

See Day-2 Operations for scaling and other limitations.