Upgrade Astra Trident
Astra Trident follows a quarterly release cadence, delivering four major releases every calendar year. Each new release builds on top of the previous releases, providing new features and performance enhancements as well as bug fixes and improvements. We encourage you to upgrade at least once a year to take advantage of the new features in Astra Trident.
Select a version
Astra Trident versions follow a date-based
YY.MM naming convention, where "YY" is the last two digits of the year and "MM" is the month. Dot releases follow a
YY.MM.X convention, where "X" is the patch level. You will select the version to upgrade to based on the version you are upgrading from.
You can perform a direct upgrade to any target release that is within a four-release window of your installed version. For example, you can upgrade to 23.01 from 22.01 (including any dot releases, such as 22.01.1) directly.
If you have an earlier release, you should perform a multi-step upgrade using the documentation of the respective release for specific instructions. This requires you to first upgrade to the most recent release that fits your four-release window. For example, if you are running 18.07 and want to upgrade to the 20.07 release, then follow the multi-step upgrade process as given below:
First upgrade from 18.07 to 19.07.
Then upgrade from 19.07 to 20.07.
Select an upgrade option
There are two options to upgrade Astra Trident. Generally, you will use the same option you used for the initial installation, however you can move between installation methods.
|CSI Volume Snapshots is now a feature that is GA, beginning with Kubernetes 1.20. When upgrading Astra Trident, all previous alpha snapshot CRs and CRDs (Volume Snapshot Classes, Volume Snapshots and Volume Snapshot Contents) must be removed before the upgrade is performed. Refer to this blog to understand the steps involved in migrating alpha snapshots to the beta/GA spec.
Changes to the operator
The 21.01 release of Astra Trident introduces some key architectural changes to the operator, namely the following:
The operator is now cluster-scoped. Previous instances of the Trident operator (versions 20.04 through 20.10) were namespace-scoped. An operator that is cluster-scoped is advantageous for the following reasons:
Resource accountability: The operator now manages resources associated with an Astra Trident installation at the cluster level. As part of installing Astra Trident, the operator creates and maintains several resources by using
ownerReferenceson cluster-scoped resources can throw up errors on certain Kubernetes distributors such as OpenShift. This is mitigated with a cluster-scoped operator. For auto-healing and patching Trident resources, this is an essential requirement.
Cleaning up during uninstallation: A complete removal of Astra Trident would require all associated resources to be deleted. A namespace-scoped operator might experience issues with the removal of cluster-scoped resources (such as the clusterRole, ClusterRoleBinding and PodSecurityPolicy) and lead to an incomplete clean-up. A cluster-scoped operator eliminates this issue. Users can completely uninstall Astra Trident and install afresh if needed.
TridentProvisioneris now replaced with
TridentOrchestratoras the Custom Resource used to install and manage Astra Trident. In addition, a new field is introduced to the
TridentOrchestratorspec. Users can specify that the namespace Trident must be installed/upgraded from using the
spec.namespacefield. You can take a look at an example here.