Upgrading Trident

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.

Important

Upgrading to a Trident release that is more than a year ahead (5 releases ahead and later) 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 YY-1.MM release and any in between; for example, to perform a direct upgrade to 21.07 it is recommended to do so from 20.07 and later (including dot releases such as 20.07.1). If you are working with an older version of Trident ( < YY-1.MM), you 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 19.07 and seek to upgrade to the 21.07 release, then:

  1. You must first upgrade from 19.07 to 20.07. Refer to the documentation of the respective release to obtain specific instructions for upgrading.
  2. Upgrade from 20.07 to 21.07 using the instructions provided below.

Important

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.

Warning

When upgrading Trident, it is important you provide parameter.fsType in 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 storage-class-basic.yaml.templ, and storage-class-bronze-default.yaml. For more information, take a look at the Known issues tab.

Understanding your upgrade paths

When upgrading, users have two distinct paths:

  1. Using the Trident Operator.
  2. Using tridentctl.

We will examine both here.

Warning

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:

  1. Running CSI Trident (19.07 and later).
  2. Using a CRD-based Trident release (19.07 and later).
  3. 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 tridentctl.

Warning

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.

tridentctl upgrades

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.