Happy (belated) New Year, and welcome to 2018, Pub readers! Over the last few months, despite the holidays, our engineers toiled at their keyboards to bring some of the most exciting things ever to Trident. We are very proud to announce that 18.01 is available now!
The elephant in the room: NetApp Docker Volume Plugin (nDVP) is no more!
Ok, that’s a bit hyperbolic. nDVP still exists, but its status as a standalone project is being deprecated. We have merged the two projects to create a single, unified one which encompasses the capabilities associated with both. There’s a number of reasons why we did this, but the most important ones are:
- This is a natural evolution toward a fully composable storage orchestration platform with intelligence that expands from the core of your clusters all the way to the edge.
- One integration is easier to understand! Now, regardless of the container platform you choose, Trident is the answer.
- A single repository means less overhead for the developers, which translates into a more efficient use of time and more functionality for you!
Trident is now our sole point of integration with the containers ecosystem. It can be deployed in the traditional manner, for integrating with Kubernetes, or it can be deployed just like the Docker volume plugin: as a plugin or as a standalone daemon on a Docker host. Trident will automatically determine which mode it should be operating in depending on how it’s instantiated.
This change is huge, and we know that there are going to be a lot of questions. Look for another blog post very soon which deep dives into the changes that have happened!
nDVP has stopped at the 17.10.2 release, but you have some time to confidently transition to Trident. Trident is designed to be a drop-in replacement but be aware that there will be no further development on the standalone nDVP code base. You should migrate to Trident as soon as is reasonable. If you have any questions, concerns, or issues please reach out to us!
So many copies, so easy: PVC cloning
Cloning happens at the storage array using the platform’s native capabilities. Supported by ONTAP and SolidFire, the clones happen instantly, with the full performance of the original, and consume no additional capacity until changes are made.
Volume Access Groups are so 2017
Until the 18.01 release, each host which could potentially be connecting to a SolidFire volume needed to have its IQN added to a volume access group. This is less graceful, and arguably less secure, than relying on the CHAP mechanism for authenticating the host and enabling access to the volume.
Kubernetes 1.7 added the ability to use CHAP authentication for iSCSI PVs. To support this, we now offer the ability to use CHAP authentication for SolidFire backend devices, making the process of adding and removing hosts in your Kubernetes cluster much, much easier…in fact, you only need to set the
UseCHAP configuration option to
true. Trident will manage everything else!
The three things mentioned above have the largest impact, but there are many other changes in this release which are very important:
- Use a hostname when adding ONTAP backends. Previously, an IP was required for data LIFs when creating ONTAP backends. You now have the option of using a hostname or an IP address for the data LIF. This can be useful if the IP address could potentially change for any reason, e.g. SVM-DR. Note that IP addresses are still required for SolidFire and E-Series backends.
- Specify mount options for backends. Mount options were deemed a stable feature in Kubernetes 1.8 and able to be specified in the storage class. This feature allows the administrator to control options such as NFS version, file system type (for iSCSI), and more to customize and tailor the connection for specific applications and conditions. Trident 18.01 adds support for mount options in the storage class definition.
YAML1234578apiVersion: storage.k8s.io/v1kind: StorageClassmetadata:name: ontapnasudpprovisioner: netapp.io/tridentparameters:backendType: "ontap-nas"
- etcd v3 support. Previously, the Trident installer deployed a single node etcd v2 cluster, along with a persistent volume, to hold the metadata needed for operating. We now use etcd v3 by default. Additionally, if you’re using the etcd instance deployed by the Trident installer, the upgrade process will also upgrade the etcd instance to version 3 automatically.
If you’re interested in how to connect your Trident instance to an external etcd v3 instance, including using certificates for encrypting data in-flight and at rest, we’ve added a whole section to our documentation to cover this.
As a bonus, during the development of this feature we created a set of example scripts to automate the process of creating an etcd v3 cluster, with security enabled and configured, along with making the modifications to the Trident deployment to take advantage of the external cluster, to give you a head start. Be sure to read the documentation and check out the scripts in the installer bundle at
Goodbye 2017, Hello 2018
Did you know Trident turned one year old December 23rd, 2017? During that year, we’ve seen explosive adoption as you, our customers, partners, and community, have led the pack in Kubernetes adoption. You’re doing some amazing things. And 2018 is going to be even better: we look forward to making even more amazing things happen together, with Trident as our sole container plugin across the portfolio of NetApp products and capabilities. There are so many exiting things happening, and we’re less than 30 days in!