Upgrading to 0.10.x
This guide explains how to upgrade from 0.9.x to 0.10.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 recreate the Deployments of backups, the operator, and other components.
Checklist
Section titled “Checklist”Follow the steps in this checklist to upgrade to 0.10.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.
Upgrade CRDs
Section titled “Upgrade CRDs”Install the new Custom Resource Definitions (CRDs) for 0.10.x.:
Using kubectl
Section titled “Using kubectl”$ kubectl apply -f https://docs.kannika.io/refs/0.10.1/crd/kannika-crd-v1alpha.ymlUsing Helm
Section titled “Using Helm”$ helm install kannika-crd oci://quay.io/kannika/charts/kannika-crd \ --version 0.10.1Update resources
Section titled “Update resources”Update the existing resources to use the new fields and features available in 0.10.x.
Migrate Restores to use the new topics field
Section titled “Migrate Restores to use the new topics field”The topics field has been introduced in 0.9.x to simplify the configuration of topic mappings in a restore,
and replaces the deprecated .spec.config.mapping field.
apiVersion: kannika.io/v1alphakind: Restorespec: source: source sink: sink config: mapping: source.topic: target: target.topic topics: - source: source.topic target: target.topicThe .spec.config.mapping field has been removed in 0.10.
Migrate Backups to segmentRolloverTriggers
Section titled “Migrate Backups to segmentRolloverTriggers”The partitionRolloverTriggers field has been renamed to segmentRolloverTriggers in 0.9.x.
apiVersion: kannika.io/v1alphakind: Backupspec: source: source sink: sink partitionRolloverTriggers: # ... segmentRolloverTriggers: # ...The .spec.partitionRolloverTriggers has been removed in 0.10.
Install application with updated Helm values
Section titled “Install application with updated Helm values”Configure the schema registry image
Section titled “Configure the schema registry image”The operator.config.schemaRegistryBackup.image field has been removed in favour of a new operator.config.schemaRegistryImage.
In case you require a specific image for the Schema Registry Backup component,
e.g. when using a private registry or a custom image,
you can configure the image in the Helm chart:
operator: config: schemaRegistryBackup: repository: quay.io/kannika/schema-registry-backup tag: 0.9.0 schemaRegistryImage: repository: quay.io/kannika/schema-registry-backup tag: 0.10.1Configure operator for SchemaRegistryRestore
Section titled “Configure operator for SchemaRegistryRestore”New operator.config.schemaRegistryRestore settings are available for the new SchemaRegistryRestore resource.
In case you require specific settings for all pods running a SchemaRegistryBackup resource (security context, resource requirements, etc.), you can configure default pod settings in the Helm chart:
operator: config: schemaRegistryRestore: pod: resources: requests: memory: "64Mi" cpu: "250m" limits:9 collapsed lines
memory: "128Mi" cpu: "500m" # securityContext: ... # nodeSelector: ... # tolerations: ... # affinity: ... # serviceAccountName # container: ... # imagePullSecrets: ...Install 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.10.1 \ --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$ kubectl logs -n kannika-system -l app.kubernetes.io/name=kannika-api$ kubectl logs -n kannika-system -l app.kubernetes.io/name=kannika-consoleVerify that the backups are running as expected:
$ kubectl get backups -n [NAMESPACE]If you encounter any issues during the upgrade process, do not hesitate to contact us on Slack.