Upgrade

«««< HEAD These pages provide best practices and tutorials for upgrading the AIStor server on Linux or Kubernetes infrastructure.

All AIStor software, including Key Manager, supports non-disruptive upgrades with zero downtime.

Using or upgrading AIStor Key Manager requires a valid MinIO Commercial License. If necessary, you can download the current license from SUBNET.

Key Manager supports backing up the cluster state. This backs up the cluster’s key database.

Taking a backup of the cryptographic key database prior to upgrading a Key Manager cluster serves as a protective measure against unexpected or undesired upgrade outcomes.

To back up the cluster’s current state, run the following command:

minkms backup --api-key KEY-VALUE

On success, this creates a compressed backup file using gzip and outputs the name of the file. The filename resembles YYYYMMDD_HHMMSS_kms.db.gzip.

To disable compression of the backup, add --compress off to the command.

If needed, you can restore a cluster’s state from a backup with minkms restore.

Key Manager runs a testing and validation suite as part of all releases. However, no testing suite can account for your production environment’s unique combinations and permutations of hardware, software, and workloads.

You should always validate any Key Manager upgrade in a non-critical environment such as Dev, QA, or Staging before applying the upgrade to production deployments, or any other environment containing critical data. Upgrading a production environment without first validating in a less critical environment is done at your own risk.

If your Key Manager deployment is significantly behind the latest stable release – 6+ months or more - consider creating an issue on SUBNET for additional support and guidance during the upgrade procedure.

Key Manager requires only one node to be available for read operations, which is the bulk of requests to Key Manager.

For Linux installations, the upgrade procedure requires two steps repeated for all hosts in the cluster:

1. Download and install the latest available binary
2. Use minkms --version to validate that all nodes have the same binary version
3. Restart the process using systemctl restart minkms on all nodes

Once all nodes in the cluster restart with the new binary, use journalctl -uf minkms to verify that all nodes started and resumed internode operations successfully.

For Kubernetes installations, the upgrade procedure depends on the target resource.

1. Take a backup of the existing Helm configuration using the helm get values command

2. Use the kubectl get all -n keymanager-operator command to verify the health and status of resources in the namespace

3. Update the helm repo using helm repo update minio

4. Update the aistor-keymanager-operator chart using helm upgrade. If you deployed the operator using a custom values.yaml, include that file using the -f flag:

   helm upgrade minio/aistor-keymanager-operator \
     -f keymanager-operator-values.yaml
   

5. Check resources in the keymanager-operator namespace to ensure all pods and services start normally.

For upgrading a Key Manager deployment:

1. Take a backup of the existing Helm configuration using the helm get values command

2. Use the kubectl get all -n NAMESPACE command to verify the health and status of resources in the key manager namespace

3. Update the helm repo using helm repo update minio

4. Update the aistor-keymanager chart using helm upgrade. If you deployed the operator using a custom values.yaml, include that file using the -f flag:

   helm upgrade minio/aistor-keymanager \
     -f keymanager-values.yaml
   

5. Check resources in the Key Manager namespace to ensure all pods and services start normally.

408c061 (CR responses + upgrade docs)