Trident follows a quarterly release cadence, delivering 4 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. Users are always encouraged to upgrade Trident at least once a year in order to take advantage of the great new features Trident has to offer.
Upgrading to a Trident release that is more than a year ahead (5 releases ahead and above) will require you to perform a multi-step upgrade.
This section walks you through the upgrade process to move to the latest release of Trident.
Determining your upgrade candidate¶
Trident recommends upgrading to the
YY.MM release from the
and any in between; for example, to perform a direct upgrade to
20.07 it is
recommended to do so from
19.07 and above (including dot releases such as
19.07.1). If you are working with an earlier release ( <
must perform a multi-step upgrade. This will require you to first move to the
most recent release that fits your four-release window.
If you are running
18.07 and seek to upgrade to the
20.07 release, then:
- You must first upgrade from
19.07. Refer to the documentation of the respective release to obtain specific instructions for upgrading.
- Upgrade from
20.07using the instructions provided below.
All upgrades for versions
19.04 and earlier will require the migration of
Trident’s metadata from it’s own etcd to CRD objects. Make sure you check the
documentation of the release to understand how the upgrade will work.
If you are running Kubernetes 1.17 or later, and are looking to upgrade to
20.07.1 or above, it is important you provide
StorageClasses used by Trident. StorageClasses can be deleted and recreated
without disrupting pre-existing volumes. This is a requirement for
enforcing Security Contexts
for SAN volumes. The sample-input
directory contains examples, such as
For more information, take a look at the Known issues tab.
Understanding your upgrade paths¶
When upgrading, users have two distinct paths:
- Using the Trident Operator.
We will examine both here.
CSI Volume Snapshots is now a feature that is GA, beginning with Kubernetes 1.20. When upgrading 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.
Which one do I choose?¶
This is an important question. Based on how you choose to install and use Trident, there could be a number of good reasons to choose one over the other.
Trident Operator upgrades¶
There are multiple reasons to want to use the Trident Operator, as detailed here.
You can use the Trident Operator to upgrade as long as you are:
- Running CSI Trident (
- Using a CRD-based Trident release (
- not performing a customized install (using custom YAMLs). To take a look at the customization that can be done with an operator install, check out the Customizing your deployment section.
You can upgrade from an install done using the operator or
Do not use the operator to upgrade Trident if you are using an etcd based
Trident release (
19.04 or earlier).
For a complete list of prerequisites, click here.
To get started with upgrading using the operator, head on over to Upgrading with the Trident Operator.
If you are not interested in what the Trident Operator has to offer (or) you have
a customized install that cannot be supported by the operator, you can always
choose to upgrade using
tridentctl. This is the preferred method of upgrades
for Trident releases
19.04 and earlier.
To upgrade using
tridentctl, jump to Upgrading with tridentctl.