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.
You can verify the available free space for the catalog and access your
recommended upgrade path by navigating to the
System Information page from
Settings menu in the navigation sidebar or by using
K10 Primer for Upgrades resource.
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
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.
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: