Upgrade on Kubernetes using Helm

This procedure upgrades a Helm deployment of Anchore Enterprise to a newer release within the same major version. Before you begin, review Prepare for the Upgrade.

Database column encryption is optional and off by default, so it is not a prerequisite for this upgrade. To enable it, supply a key — either anchoreConfig.database.encryption.currentKey in your values file, or ANCHORE_DB_ENCRYPTION_KEY_CURRENT in your own secret if you use useExistingSecrets: true. You can do this during this upgrade or at any later point. See Encrypting Database Secrets at Rest.

A Helm pre-upgrade hook initiates a Kubernetes job that scales down all active Anchore Enterprise pods and handles the Anchore Enterprise database upgrade.

The Helm upgrade is marked as successful only upon the job’s completion. This process causes the Helm client to pause until the job finishes and new Anchore Enterprise pods are initiated. To monitor the upgrade, you can follow the logs of the upgrade jobs:

kubectl get jobs -n ${NAMESPACE}
kubectl logs -f job/<JOB_NAME> -n ${NAMESPACE}

These jobs are automatically removed after a subsequent successful Helm upgrade.

An alternative post-upgrade hook is available to perform Anchore Enterprise upgrades without forcing all pods to terminate prior to running the upgrade. To enable the post-upgrade hook, set upgradeJob.usePostUpgradeHook=true in your values file.

1. View both the Helm Chart Release Notes for any necessary steps prior to upgrading and also review the Anchore Enterprise Release Notes

2. Update the Helm repository to get the latest chart version.

   helm repo update
   

3. Upgrade Anchore Enterprise using the Helm chart.

   export NAMESPACE=anchore
   export RELEASE=my-release
   
   helm upgrade ${RELEASE} -n ${NAMESPACE} anchore/enterprise -f anchore_values.yaml
   

4. Review the helm upgrade command output

5. Once upgraded, you can review the new state of your Anchore Enterprise install to verify the new version is running using the regular system status command.

   anchorectl system status
   

Rebuild an In-Cluster CloudNativePG Image

If you run PostgreSQL in-cluster with CloudNativePG (CNPG) and built your pg_cron image on the plain ghcr.io/cloudnative-pg/postgresql:17 tag, rebuild it on a current base. That tag points to a Debian 11 (bullseye) image that CNPG no longer updates, and the PostgreSQL APT repository no longer serves pg_cron packages for Debian 11, so the image can no longer be rebuilt. This is separate from the Anchore Enterprise upgrade, so you can do it before or after running helm upgrade.

1. Move built-in Barman Cloud backups to the plugin first. Check whether your cluster uses CNPG’s built-in barmanObjectStore backups:

   kubectl get cluster anchore-pg -n anchore -o jsonpath='{.spec.backup.barmanObjectStore}'
   

   If this prints anything, migrate to the Barman Cloud Plugin before you change images. The new base image does not include the Barman Cloud tools that built-in backups run, so WAL archiving would fail and PostgreSQL would keep WAL files until the volume fills. Empty output means no action is needed.

2. Rebuild the image with the Dockerfile in Run PostgreSQL In-Cluster with CloudNativePG, and push it under a new tag, such as 17-trixie. Do not push over the tag your cluster already uses.

3. Point the cluster at the new tag. CNPG updates running instances only when imageName changes, so an image pushed under the existing tag is never rolled out. Set imageName in cnpg-cluster.yaml to the new tag, then apply it:

   kubectl apply -f cnpg-cluster.yaml
   kubectl get cluster anchore-pg -n anchore -w
   

   CNPG restarts the instances one at a time, primary last. With a single instance, the database is unavailable while its pod restarts.

4. Reindex if you changed the collation. The new base moves PostgreSQL from Debian 11 to Debian 13, which ships a newer glibc. A cluster created as shown in the deployment guide uses the C collation, which this change does not affect. Check yours:

   kubectl exec -it anchore-pg-1 -n anchore -- \
     psql -U postgres -d anchore -c "SELECT datcollate FROM pg_database WHERE datname = 'anchore';"
   

   If the result is anything other than C, run REINDEX DATABASE anchore; during a maintenance window after the rollout.