Upgrading K10

Note

Currently, upgrades are only supported across a maximum of four versions (e.g., 2.0.10 -> 2.0.14). If your K10 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 check catalog free space and see your recommended upgrade path under Settings -> Support in the UI or by using K10 Primer for Upgrades.

Upgrading Helm-Installed K10

To upgrade to the latest K10 release, unless you have installed K10 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.

$ 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

Upgrading on the Google Cloud Marketplace

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

Upgrading on the AWS Marketplace

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

Upgrading an Operator installed K10

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

The process of upgrading the K10 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 K10 Operator and Operand (which is the K10 install) are both automatically updated any time a new K10 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 K10 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 K10 maximum supported OpenShift version may cause unpredictable K10 behavior and will result in losing Kasten support.

Examples of warning messages for cluster upgrade: