Upgrading Veeam Kasten

Note

Currently, upgrades are only supported across a maximum of four versions (e.g., 2.0.10 -> 2.0.14). If your Veeam Kasten version is further behind the latest, a step upgrade process is recommended where you can use the [--version] flag with helm upgrade to control the version jumps. At least 50% free space is required in catalog storage also.

Upgrade Assistant

You can verify the available free space for the catalog and access your recommended upgrade path by navigating to the System Information page from the Settings menu in the navigation sidebar or by using Veeam Kasten Primer for Upgrades resource.

Upgrading Helm-Installed Veeam Kasten

To upgrade to the latest Veeam Kasten release, unless you have installed Veeam Kasten via the a public cloud marketplace, you should run the following command assuming you installed in the kasten-io namespace with the release name k10. If you do not remember your release name, you can easily discover that via the use of helm list --namespace=kasten-io.

Note

If Generic Storage Backup is being used for backing the applications and if a new version of Kanister-tools image is available, additional steps may need to be performed for updating the Kanister sidecar image manually. Follow steps mentioned in Update Kanister Sidecar Image section.

$ helm repo update && \
    helm get values k10 --output yaml --namespace=kasten-io > k10_val.yaml && \
    helm upgrade k10 kasten/k10 --namespace=kasten-io -f k10_val.yaml

Known Issues: Helm 3 has known bugs with upgrade (e.g., #6850). If you run into errors along the lines of

Error: UPGRADE FAILED: rendered manifests contain a new resource that already exists. Unable to continue with update: existing resource conflict: kind: Deployment, namespace: kasten-io, name: prometheus-server

Please use the following as a workaround and then run the above upgrade commands.

$ kubectl --namespace=kasten-io delete deployment prometheus-server

Updating Kanister Sidecar Image for Applications using Generic Storage Backup

After releasing a new version of Veeam Kasten, a new Sidecar container may be published. In such cases, the Kanister Sidecar image needs to be updated for applications using Generic Storage Backup. Generic Storage Backup . If the Sidecar injection was enabled while installing/upgrading Veeam Kasten using the Helm option described in Generic Storage Backup. the application pods having the Kanister Sidecar injected in them can be restarted. This will pull the latest Kanister tools image for the application.

Alternatively, to refrain from the restarting the application, one of the below methods can be followed to update the Kanister Sidecar image in the application pods.

1. Manual update of the Kanister Sidecar Image: Manually update the Kanister Sidecar image in all the application deployments where the Kanister Sidecar is injected. This can be done by changing the image for kanister-sidecar container in the application deployment.

$ kubectl set image deployment/<deployment_name> kanister-sidecar=<image_name>:<version>

Note

Executing this updates the deployment and causes the pods to restart. The restart behavior depends on the deployment strategy.

2. Removing the Sidecar manually: Once the Kanister Sidecar is removed, mutating webhook will inject the Sidecar with the new image automatically. This can be done by any of the methods mentioned below:

   2.1 Use Kasten tools to remove the Sidecar.

   Note

   This should be done in a planned maintenance window.

   $ ./k10tools k10genericbackup uninject all -n <namespace>

   2.2 Fetch the YAML manifest for the deployment and manually remove the Kanister Sidecar

   $ kubectl get deployment <deployment_name> -o yaml > deployment.yaml

   Identify the section in the YAML file that defines the containers in the deployment. Delete the definition of the unwanted Sidecar container.

   containers:
   - args:
   - tail -f /dev/null
   image: gcr.io/kasten-images/kanister-tools:108
   imagePullPolicy: IfNotPresent
   name: kanister-sidecar
   resources: {}
   terminationMessagePath: /dev/termination-log
   terminationMessagePolicy: File
   volumeMounts:
   - mountPath: /data/data
       name: data
   - mountPath: /tmp/kopia-cache
       name: kopia-cache-volume
   dnsPolicy: ClusterFirst

   Apply the modified deployment as below

   $ kubectl apply -f deployment.yaml -n <namespace_name>

Upgrading on the Google Cloud Marketplace

If you have installed Veeam Kasten via the Google Cloud Marketplace, please follow the instructions here .

Upgrading on the AWS Marketplace

If you have installed Veeam Kasten via the AWS Container Marketplace or AWS Marketplace for Containers Anywhere, please follow the marketplace upgrade instructions.

Upgrading an Operator Installed Veeam Kasten

Upgrading a Veeam Kasten installation made by a Veeam Kasten Operator requires updating the Veeam Kasten Operator. Ref: Red Hat documentation for upgrading installed Operators.

The process of upgrading the Veeam Kasten Operator depends on how update was configured during install - Automatic or Manual.

The Operator update approval strategy can be changed anytime after install from the Subscription tab of the Operator.

For an Automatic update, the Veeam Kasten Operator and Operand (which is the Veeam Kasten install) are both automatically updated any time a new Veeam Kasten Operator is published.

For a Manual update, the cluster administrator must approve the update when it shows up for the installation to begin. Ref: Red Hat documentation for manually approving a pending Operator upgrade.

The Veeam Kasten operators are published with a maximum supported OpenShift version. This will cause warnings to appear when trying to upgrade a cluster beyond the maximum supported version.

warning

Upgrading the cluster beyond the Veeam Kasten maximum supported OpenShift version may cause unpredictable Veeam Kasten behavior and will result in losing Kasten support.

Examples of warning messages for cluster upgrade: