Upgrading to 0.13.x
This guide explains how to upgrade from 0.12.x to 0.13.x.
Before you begin
Section titled “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 and remove the Deployments of backups, the operator, and other components.
Checklist
Section titled “Checklist”Follow the steps in this checklist to upgrade to 0.13.x.
Pause backups
Section titled “Pause backups”Pause all backups to prevent any changes to the backup data by setting the .spec.enabled field to false.
#!/usr/bin/shfor 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#!/usr/bin/fishfor 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}}'endReplace [NAMESPACE] with the namespace where the backups are located.
Pause existing operator
Section titled “Pause existing operator”Pause the existing operator by setting the .spec.replicas field to 0.
$ kubectl scale deployment kannika-operator -n kannika-system --replicas=0This 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:
operator: replicaCount: 0Upgrade CRDs
Section titled “Upgrade CRDs”Install the new Custom Resource Definitions (CRDs) for 0.13.x.:
Using kubectl
Section titled “Using kubectl”$ kubectl apply -f https://docs.kannika.io/refs/0.13.0/crd/kannika-crd-v1alpha.ymlUsing Helm
Section titled “Using Helm”$ helm install kannika-crd oci://quay.io/kannika/charts/kannika-crd \ --version 0.13.0Install application with updated Helm values
Section titled “Install application with updated Helm values”This version of Kannika Armory introduces some important changes to the platform regarding Kubernetes namespaces and RBAC resources.
Configure custom security Secret
Section titled “Configure custom security Secret”It is now possible to provide a custom security Secret for the Kannika Armory components instead of using the default generated one. This is useful when integrating with an external secret management system or when you want to have more control over the security credentials.
api: config: security: enabled: true username: <username> password: <password> secret: create: false name: custom-kannika-api-security usernameKey: custom-username-key passwordKey: custom-password-keyInstall the new version of Kannika Armory
Section titled “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.13.0 \ --values values.yamlEnable backups again
Section titled “Enable backups again”Once you have completed the upgrade process,
enable backups again by setting the .spec.enabled field to true.
#!/usr/bin/shfor 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#!/usr/bin/fishfor 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}}'endReplace [NAMESPACE] with the namespace where the backups are located.
Verify the installation
Section titled “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 consoleVerify 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.