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

Garrett introduced us to PVC cloning when the first beta of 18.01 was released in December last year. By adding a single line to the PVC definition, we can quickly and easily create clones:

kind: PersistentVolumeClaim
apiVersion: v1
  name: prod-clone
    trident.netapp.io/cloneFromPVC: prod
    - ReadWriteOnce
      storage: 1Gi
  storageClassName: gold

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.

If you’re interested in doing clone splits, that option is supported as well using the annotation (trident.netapp.io/splitOnClone) in the PVC or by providing the option in the backend configuration.

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!

    "version": 1,
    "storageDriverName": "solidfire-san",
    "Endpoint": "https://<user>:<password>@<mvip>/json-rpc/7.0",
    "SVIP": "<svip>:3260",
    "TenantName": "<tenant>",
    "UseCHAP": true,
    "Types": [...]

Other Changes

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.
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
      name: ontapnasudp
    provisioner: netapp.io/trident
    mountOptions: ["rw", "nfsvers=3", "proto=udp"]
      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 trident-installer/extras/external-etcd.

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!

As always, if you have any questions about Trident, please reach out to us! The comments below, our Slack team, or the GitHub issues page are all great ways to get directly in contact with us!

Andrew Sullivan on GithubAndrew Sullivan on Twitter
Andrew Sullivan
Technical Marketing Engineer at NetApp
Andrew has worked in the information technology industry for over 10 years, with a rich history of database development, DevOps experience, and virtualization. He is currently focused on storage and virtualization automation, and driving simplicity into everyday workflows.

Pin It on Pinterest