NetApp Trident: a storage orchestrator that speaks CSI to NetApp backends

The problem: stateful containers need storage that behaves predictably

A stateless container is easy to schedule. A stateful one is not, because the volume it writes to has to survive the container, land on a system that supports the workload's access pattern, and be created and deleted according to a policy that the application does not control.

Trident is NetApp's answer to that, described in the project description as a storage orchestrator for containers. It has been designed from the ground up to help you meet your containerized applications' persistence demands using industry-standard interfaces, such as the Container Storage Interface, CSI.

The audience is the storage and platform team behind a Kubernetes cluster, not the application developer. The application developer sees a PersistentVolumeClaim and does not know Trident exists. The platform team installs Trident, defines a StorageClass, and gets dynamic provisioning with NetApp's own data management features behind it.

The governance detail is worth noting at the outset, because it is unusual for a vendor storage product. Trident is a fully supported open source project maintained by NetApp, published under the Apache-2.0 licence with the source in the open, the documentation under NetApp's own docs site, and the support policy described on NetApp's support site under the Trident's Release and Support Lifecycle tab. So the code is inspectable and the support commitment is a contract, not a community best effort.

The last push was on 2026-10-19, with releases v26.06.2 from 2026-10-08, v26.06.1 from 2026-08-19 and v26.06.0 from 2026-06-30, so the version numbering follows a date based scheme rather than semantic versioning.

The design: CSI as the contract, not a NetApp API

The architectural decision that makes Trident reusable is that its interface to Kubernetes is the Container Storage Interface, an industry standard, rather than a NetApp specific API.

Trident deploys in Kubernetes clusters as pods and provides dynamic storage orchestration services for Kubernetes workloads. In practice that means the CSI side of the contract: the plugin registers as a storage driver, answers the provisioning and attach calls Kubernetes makes, and the application only ever sees a claim.

The go.mod confirms how wide the surface is. The container storage interface spec at version 1.13.0, the kubernetes-csi csi-lib-utils and csi-proxy client, the go-openapi stack for the generated API layer, gorilla/mux for routing, and then the cloud SDKs for each backend: the Azure SDK for Go with the armnetapp resource manager, the AWS SDK v2 with the fsx and secretsmanager services, and the Google Cloud netapp client. The CSI Proxy dependency is the piece that lets a container mount a volume that lives on a file or NFS backend rather than on a block device, which is what makes NetApp file services usable through the same interface.

The dependency list also shows the internal structure of the project, because the module name is github.com/netapp/trident and the packages are grouped by concern: storage drivers, storage classes, storage attributes, an object layer, a persistent store for the controller's own metadata, an operator, a control plane, a core library, a command line, and testing and mocks directories.

The backends: NetApp's own platforms, on premises and in the cloud

Trident enables containerized applications to quickly and easily consume persistent storage from NetApp's broad portfolio, and the portfolio is what defines the product.

The on-premises platforms are ONTAP, in its AFF, FAS, Select and Cloud variants, and Element, which covers HCI and SolidFire. The cloud services are Azure NetApp Files, Google Cloud NetApp Volumes and Amazon FSx for ONTAP. Each of these has a matching driver in the storage_drivers/ directory of the repository, and each has the cloud SDK in the dependency list.

That list is the honest boundary of the project. Trident is not a general purpose Kubernetes storage provisioner that happens to work well with NetApp. It is NetApp's provisioner, and the set of backends is the set of platforms NetApp sells. An organisation whose volumes live on a different array has a different product to evaluate, and the open source nature of the code does not change the driver set.

There is a second dimension to the choice, which is how the storage is consumed rather than where it lives. NetApp's portfolio spans both block and file, and the CSI Proxy in the dependency list is what bridges the two, so a file-backed volume can be presented to a pod that expects a block device. For a team running a mix of file workloads and databases, that is often the reason to pick Trident over a driver that only speaks block.

The dependency on hpe-storage/common-host-libs, which is an older and less obvious entry in the list, reflects the same kind of practical compatibility work that a storage driver accumulates.

Data protection: snapshots, backups, replication and cloning

The second half of the feature description is about what happens after the volume exists.

Trident features also address data protection, disaster recovery, portability, and migration use cases for Kubernetes workloads leveraging NetApp's industry leading data management technology for snapshots, backups, replication, and cloning.

That sentence is doing a lot of work, and it is worth unpacking because it is the part that distinguishes a storage orchestrator from a provisioner. A provisioner creates volumes. A data platform lets you snapshot a volume, replicate it to another system, clone it, and restore it, which for a container workload is often the difference between an application that survives a region failure and one that does not.

The mechanism is NetApp's own data management technology, not something Trident implements. That is the trade of the design, and it cuts both ways. You get mature snapshot and replication semantics without reimplementing them, and the operations are NetApp operations, so the tooling, the documentation and the support all exist. What you do not get is a storage-neutral abstraction, and if you later move to a different array, the data protection story has to be rebuilt.

The repository layout backs up the same picture. There is a persistent_store/ directory, which is where the controller keeps its own metadata about what it has provisioned, and a cosi/ directory, a command line, an operator and a control plane. The controller is a stateful service, which is the operational reality of an orchestrator that provisions on demand.

Running the controller locally, and the privileges it asks for

The docker-compose.yml in the repository is the quickest way to see the shape of the deployment, and it is instructive because of what it mounts.

  trident:
    image: netapp/trident
    ports:
     - "${PORT}:${PORT}"
    volumes:
     - /var/run/docker/plugins:/var/run/docker/plugins
     - /dev:/dev
    privileged: true
    tty: true

The orchestrator binary is trident_orchestrator, and it takes the bind address, the port, the etcd v2 endpoint and the Kubernetes API server address on the command line. The etcd service in the same file is a standalone instance, mounted from the ETCD_DIR volume, which tells you that Trident keeps its state in a key-value store rather than in a relational database.

The privileges are the part a security reviewer should look at. The container is privileged, it mounts the Docker plugin socket and the whole of /dev, and it is given a tty. That is what a storage orchestrator needs in order to mount filesystems into the pods it provisions, and it is also a large amount of host access for a control plane.

The project ships a trident-installer/ directory, a helm/ directory with a chart, a deploy/ directory and a tridentctl command line, so the production deployment path is Helm rather than Compose. The Compose file is for development, where you point the orchestrator at a test cluster and a local etcd.

The build machinery, and what the Makefile tells you about the project

The Makefile is long, and the parameter block at the top is a good description of how the project is built and released.

The platforms are derived from the host unless you ask for all of them:

PLATFORMS ?= $(shell uname -s -m | tr '[:upper:]' '[:lower:]' | sed -e 's# #/#' -e 's/x86_64/amd64/' -e 's/aarch64/arm64/')

The container registry, the buildx output mode and the Go toolchain are all variables, with the Go image pinned to golang:1.26 and the Helm image to alpine/helm:3.16.1, and the golangci-lint version pinned to v2.12.2 with mockgen at v0.6.0. The go.mod agrees on the language version, go 1.26.0.

The details that matter for a contributor are the ones that talk about the surrounding tools. GOPROXY and GOFLAGS are overridable, GO_CMD selects the go binary, and there is a GIT_HOOKS_DIR variable pointing at the hooks directory from git rev-parse, which is how the project installs its own hooks. There is a .golangci.yml for the linter, a renovate.json for dependency updates, and a Jenkinsfile with a Dockerfile and a Dockerfile.Windows, so the image build covers both platforms.

There is also a code-generator-kubernetes-1.18.2.tar.gz in the repository root, which is a hint about the shape of the project: there is generated code, and the generated code is checked in, and the generator has its own versioned distribution. That is common in CSI drivers, where the code for each Kubernetes API version is generated from the published API.

Licence, support and where Trident is the wrong tool

The licence is Apache-2.0, with the LICENSE file at the root of the repository and a NOTICE.txt alongside it, plus separate NOTICE files for the ACP and ASUP modules. Apache-2.0 with a NOTICE file is the pattern you would expect for a vendor project that has to carry third party attributions, and it is the same terms under which most of the CSI ecosystem ships.

The support model is the more interesting part and it is a genuine difference from a community driver. Trident is fully supported by NetApp, with a support policy documented on NetApp's support site under the Trident's Release and Support Lifecycle, and the badges in the project description point at that policy and at the official documentation. In practice that means a Trident deployment is covered by the same support arrangement as the storage behind it, which for an enterprise is the main reason to choose it over an unsupported driver that does the same job.

Where Trident is the wrong tool is straightforward. If your storage is not in NetApp's portfolio, there is no driver for it, and the open source licence does not change that. If you are running a bare cluster with a simple cloud block store and a single CSI driver would do, Trident's data management features are more machinery than the problem needs, and you are taking on a control plane with its own state store and its own upgrade path. And if you need a driver that the community maintains on a schedule you control, a vendor-governed lifecycle is a different kind of dependency, because the version you run and the version that is supported are two different questions.

The judgement is that Trident is a good choice when the answer is yes to two questions: the storage is NetApp's, and the support arrangement matters more than the licence. Check the release and support lifecycle page for the version you are about to run, and read the deployment documentation for the backend you use, because the driver configuration differs per platform.

Editorial conclusion

Adopt Trident if you run Kubernetes on NetApp storage and want the CSI driver that NetApp supports, with snapshots, backups, replication and cloning behind one control plane. Do not adopt it if your storage is not in NetApp's portfolio, and do not adopt it as a generic storage provisioner, because the driver set is the product. Before you deploy it, read the release and support lifecycle page for your version, since the project is versioned and supported by NetApp rather than by the community, and plan the control plane as a stateful deployment, since it keeps its own metadata store.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. NetApp/trident on GitHub
4. README
5. Releases