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:
- Installing with
tridentctlwill create a
trident-installerpod 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 installagain to create the objects (CRDs, deployment, daemonset) all over and make sure it’s not stopped in between.
- 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
tridentctlwon’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.
- 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:
- 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.
- 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.
- 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:
- Install Trident.
- Modify a Trident install done through the operator.
- Uninstall Trident.
- 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
TridentProvisionerCR 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
TridentProvisionerCR triggers the installation, deleting the CR uninstalls Trident without removing the Custom Resources Trident uses (
TridentVolumesand 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
TridentProvisionerin the same namespace will reuse the backends and volumes created by the previous Trident instance.
TridentProvisionerdisplays a Status. The status indicates how the operator processes the
TridentProvisioner.When installing Trident, you will observe the status of the
TridentProvisionerchanging to “Installing” and then to “Installed” once it’s done. A list of possible statuses is provided here.
Get started today