Skip to main content

Understand the operator upgrade workflow

Contributors juliantap netapp-aruldeepa

Before using the Trident operator to upgrade Trident, you should understand the background processes that occur during upgrade. This includes changes to the Trident controller, controller Pod and node Pods, and node DaemonSet that enable rolling updates.

Trident operator upgrade handling

One of the many benefits of using the Trident operator to install and upgrade Trident is the automatic handling of Trident and Kubernetes objects without disrupting existing mounted volumes. In this way, Trident can support upgrades with zero downtime, or rolling updates. In particular, the Trident operator communicates with the Kubernetes cluster to:

  • Delete and recreate the Trident Controller deployment and node DaemonSet.

  • Replace the Trident Controller Pod and Trident Node Pods with new versions.

    • If a node is not updated, it does not prevent remaining nodes from being updated.

    • Only nodes with a running Trident Node Pod can mount volumes.

Tip For more information about Trident architecture on the Kubernetes cluster, refer to Trident architecture.

Operator upgrade workflow

When you initiate an upgrade using the Trident operator:

  1. The Trident operator:

    1. Detects the currently installed version of Trident (version n).

    2. Updates all Kubernetes objects including CRDs, RBAC, and Trident SVC.

    3. Deletes the Trident Controller deployment for version n.

    4. Creates the Trident Controller deployment for version n+1.

  2. Kubernetes creates Trident Controller Pod for n+1.

  3. The Trident operator:

    1. Deletes the Trident Node DaemonSet for n. The operator does not wait for Node Pod termination.

    2. Creates the Trident Node Daemonset for n+1.

  4. Kubernetes creates Trident Node Pods on nodes not running Trident Node Pod n. This ensures there is never more than one Trident Node Pod, of any version, on a node.