Upgrading to 0.15.x

This guide explains how to upgrade from 0.14.x to 0.15.x.

Caution

A Kannika Armory version sometimes contain changes that prepare existing resources for an upcoming release, such as new annotations and labels.

Make sure you always upgrade in steps and never skip a version.

Before you begin

Before you begin the upgrade process, ensure that you have a backup of your data.

The upgrade process will not touch the actual backup data, but might change the resource definitions.

Breaking changes

Minimum Kubernetes version

The minimum required version of Kubernetes has been increased from 1.28 to 1.30. Make sure your cluster is running Kubernetes 1.30 or later before upgrading.

Restore filters

The flat restoreFromDateTime and restoreUntilDateTime fields on the Restore CRD are now deprecated in favor of the new nested config.filters structure. The old fields are still supported as a fallback, but we recommend migrating to the new structure.

See the Restore filters documentation for more details.

Checklist

Follow the steps in this checklist to upgrade to 0.15.x.

• Verify Kubernetes version is 1.30+
• Pause backups
• Pause existing operator
• Upgrade CRDs
• Install application with updated Helm values
• Enable backups again
• Verify the installation

Verify Kubernetes version

Ensure your cluster is running Kubernetes 1.30 or later:

$ kubectl version

Pause backups

Pause all backups to prevent any changes to the backup data by setting the .spec.enabled field to false.

Shell

#!/usr/bin/sh
for backup_name in $(kubectl get backups -n [NAMESPACE] -o custom-columns='NAME:.metadata.name' --no-headers)
do
kubectl patch --type merge backup -n [NAMESPACE] "$backup_name" -p '{"spec":{"enabled": false}}'
done

Fish

#!/usr/bin/fish
for backup_name in (kubectl get backups -n [NAMESPACE] -o custom-columns='NAME:.metadata.name' --no-headers)
kubectl patch --type merge backup -n [NAMESPACE] $backup_name -p '{"spec":{"enabled": false}}'
end

Replace [NAMESPACE] with the namespace where the backups are located.

Pause existing operator

Pause the existing operator by setting the .spec.replicas field to 0.

$ kubectl scale deployment kannika-operator -n kannika-system --replicas=0

This will ensure no changes are made to the existing resources while the upgrade is in progress.

If you are using a Helm chart to manage the operator, you can set the operator.replicaCount field to 0 in the Helm values file:

values.yaml

operator:
  replicaCount: 0

Upgrade CRDs

Install the new Custom Resource Definitions (CRDs) for 0.15.x.:

Using kubectl

$ kubectl apply -f https://docs.kannika.io/refs/0.15.0/crd/kannika-crd-v1alpha.yml

Using Helm

$ helm install kannika-crd oci://quay.io/kannika/charts/kannika-crd \
  --version 0.15.0

Install application with updated Helm values

This release adds new optional Helm values for global logging configuration. See Logging configuration for details.

Install the new version of Kannika Armory

Install the new version of Kannika Armory using Helm:

$ helm upgrade --install kannika oci://quay.io/kannika/charts/kannika \
  --create-namespace \
  --namespace kannika-system \
  --version 0.15.0 \
  --values values.yaml

Installation Learn how to install Kannika Armory

Enable backups again

Once you have completed the upgrade process, enable backups again by setting the .spec.enabled field to true.

Shell

#!/usr/bin/sh
for backup_name in $(kubectl get backups -n [NAMESPACE] -o custom-columns='NAME:.metadata.name' --no-headers)
do
kubectl patch --type merge backup -n [NAMESPACE] "$backup_name" -p '{"spec":{"enabled": true}}'
done

Fish

#!/usr/bin/fish
for backup_name in (kubectl get backups -n [NAMESPACE] -o custom-columns='NAME:.metadata.name' --no-headers)
kubectl patch --type merge backup -n [NAMESPACE] $backup_name -p '{"spec":{"enabled": true}}'
end

Replace [NAMESPACE] with the namespace where the backups are located.

Verify the installation

Verify that the upgrade was successful by checking the logs of the Kannika Armory components:

$ kubectl logs -n kannika-system -l app.kubernetes.io/name=kannika-operator # or operator
$ kubectl logs -n kannika-system -l app.kubernetes.io/name=kannika-api      # or api
$ kubectl logs -n kannika-system -l app.kubernetes.io/name=kannika-console  # or console

Verify that the backups are running as expected:

$ kubectl get backups -n [NAMESPACE]
$ kubectl get schemaregistrybackups -n [NAMESPACE]

If you encounter any issues during the upgrade process, do not hesitate to contact us on Slack.