Introducing the Trident Operator

The Trident Operator is now available with Trident 20.04! With the operator, users can install Trident 20.04 and take advantage of the self-healing features that it provides. This lays the foundation for automatically managing a Trident installation; the operator is responsible for installing, uninstalling and patching Trident.

Greenfield Only Please

The 20.04 release of the Trident Operator is for greenfield installs only. You must use tridentctl for upgrading pre-existing installations.

The Operator’s Scope 

To understand what the operator can do, here are some challenges that are experienced when working with tridentctl to manage Trident:

1. Installing with tridentctl will create a trident-installer pod that runs through the install process. What happens if the installation is interrupted? Since the installer pod did not run to completion, you will first need to uninstall Trident to undefine the partial state created by the incomplete Trident install. Then you will have to call tridentctl install again to create the objects (CRDs, deployment, daemonset) all over and make sure it’s not stopped in between.
2. When a Trident pod is deleted, the Trident deployment and daemonset make sure to create another pod. What if the deployment is removed by mistake? Trident cannot detect if the deployment is deleted. Installing with tridentctl won’t fix this either, since the installer will try to define objects that already exist. To fix this, the Trident deployment must be created manually.
3. To modify an existing Trident install, you must uninstall and reinstall Trident. Here’s an example: To enable debug logs on Trident (or) to change the logFormat (or) to install a custom Trident image you must uninstall and then use the required installer flags when installing Trident.

The Trident Operator solves all the problems mentioned above. To understand the motivation behind introducing the operator framework, an operator is designed to handle operations such as configuration, failure recovery and updates from one version to another without requiring human intervention. Operators abstract the operational considerations for an application and handle its lifecycle. 

Trident’s operator ensures that: 

1. Trident installs with the operator are performed declaratively. The operator does not re-create objects that already exist and continue from where it left off.
2. Changes made to break a Trident install are automatically rectified; if the Trident deployment is deleted, the operator creates it again. It handles failure recovery.
3. Modifying existing installs is simple. You can patch an install to pass additional arguments and the operator will update the install for you, creating new pods and deleting the old ones.

What can you do with the operator today? The operator can: 

1. Install Trident.
2. Modify a Trident install done through the operator.
3. Uninstall Trident.
4. Update Trident automatically if the Kubernetes version changes to a supported version or if the operator version changes.

You will still need to use tridentctl for operations such as creating backends and updating them. Moving forward, these will also be configurable through the operator. 

Meet the TridentProvisioner

Once the Trident Operator is setup, initiating a Trident install is done using the TridentProvisioner Custom Resource. The deploy/crds/ directory contains sample definitions of TridentProvisoner CRs. The documentation covers the list of parameters that you can configure. Once the operator is deployed, it looks for a TridentProvisioner CR to begin installing Trident.

• The namespace of the TridentProvisioner is where Trident will be installed. The operator and the TridentProvisioner can be in different namespaces. 
• At any given point of time, there will only be one active TridentProvisioner CR in a k8s cluster. As you already know, there should only be one instance of Trident in a cluster. The operator ensures that only the first valid CR is active even if multiple CRs are created.
• Since the TridentProvisioner CR triggers the installation, deleting the CR uninstalls Trident without removing the Custom Resources Trident uses (TridentBackends, TridentVolumes and so on). Instead of deleting the CR, it is recommended to patch the CR and set spec.uninstall=true. The operator acts on this spec update and uninstalls Trident while keeping the CRs Trident uses. Creating a TridentProvisioner in the same namespace will reuse the backends and volumes created by the previous Trident instance.
• Each TridentProvisioner displays a Status. The status indicates how the operator processes the TridentProvisioner. When installing Trident, you will observe the status of the TridentProvisioner changing to “Installing” and then to “Installed” once it’s done. A list of possible statuses is provided here.

Get started today

Download the 20.04 installer from our Github repository. The documentation describes how you can use the operator to install Trident. Reach out to us on our Slack channel! 

Bala RameshBabu

Bala is a Technical Marketing Engineer who focuses on Trident, NetApp's dynamic storage provisioner for Kubernetes and Docker. With a background in OpenStack, he focuses on open-source solutions and DevOps workflows. When not at work, you can find him in a soccer field or reading biographies