Kubernetes 1.6 was introduced not too long ago, and it includes some significant updates for those taking advantage of dynamic provisioning using Trident. Even though 1.6 is now a version behind (1.7 was released just last week), the changes to storage classes were extensive. We are very happy to announce that Trident 17.07 is available now and incorporates full support for Kubernetes 1.6 with a wide array of enhancements and fixes.

Storage Classes Are Out of Beta

Arguably the most significant storage related change to happen in Kubernetes 1.6 was that dynamic provisioning is now officially a stable feature, so you should now feel confident deploying clusters using this feature.

Both the StorageClass and PersistentVolumeClaim objects have changed slightly as a result. The beta annotations will continue to work in 1.6 and 1.7, but you should take this opportunity to migrate to the attribute nomenclature now used since the beta annotation will be deprecated in the future.

To illustrate the change, here is a PVC using the beta annotation nomenclature:

apiVersion: storage.k8s.io/v1beta1
kind: PersistentVolumeClaim
  name: myfavoritepv
    volume.beta.kubernetes.io/storage-class: performance
    - ReadWriteOnce
      storage: 1Gi

You’ll notice in the above highlighted line that we used the annotation "volume.beta.kubernetes.io/storage-class" to specify that the PV should be created using the "performance" storage class. This worked in 1.4 and 1.5, and continues to work in 1.6 and 1.7. However, as of 1.6, with storage classes coming out of beta and into stable status, there is a new way of specifying the storage class:

apiVersion: v1
kind: PersistentVolumeClaim
  name: myfavoritepv
  - ReadWriteOnce
      storage: 1Gi
  storageClassName: performance

Notice that the "storageClassName" is now a part of the spec definition, but otherwise functions the same.

Dynamically Provisioned PVs Default to "delete" Reclaim Policy as of Kubernetes 1.6

As the title implies, any PV created dynamically, by any provisioner, will default to the "delete" reclaim policy. This means that once the PV is released by the application, Kubernetes will ask the provisioner to destroy the underlying volume. If this is not the behavior you would like, changing the default behavior for volumes created by Trident is very easy, just set the trident.netapp.io/reclaimPolicy attribute on the storage class to the value you want.

Using a Default Storage Class

Default storage classes, new in Kubernetes 1.6, make it super easy for your users to take advantage of persistence without having to worry about the infrastructure at all. Simply define a storage class and identify it as the default, and any PVC that does not specify a storage class will use it.

And don’t worry, with a dynamic provisioner like Trident, you can still easily support more than one storage class at a time, allowing you to provide a catalog of storage options for users that need something a bit different from the default to meet the demands of their application.

For example, perhaps you default to a "performance" class, but you still want to offer "extreme" and "archive" classes that further optimize for performance or cost, respectively. Creating a default storage class is very simple, just add an annotation setting the storage.kubernetes.io/is-default-class to true.

kind: StorageClass
apiVersion: storage.k8s.io/v1
  name: standard
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: netapp.io/trident
  backendType: "ontap-nas"
  media: "hybrid"

To list the storage classes available, and view the default, users can simply list the storage classes using this command:

$ kubectl get sc
NAME                    TYPE
archive                 netapp.io/trident
extreme                 netapp.io/trident   
performance             netapp.io/trident
standard    (default)   netapp.io/trident

There are some caveats if you have existing PVCs which do not have a storage class specified, be sure to read this blog post for full details on the behavior which Kubernetes will apply to existing PVs and PVCs with and without an assigned storage class.

iSCSI Compatibility for ONTAP and E-Series

Several significant iSCSI issues that we reported (#40941, #41041, and #39202) were fixed upstream and incorporated into Kubernetes 1.6, allowing us to officially recommend and support iSCSI deployments for ONTAP and E-Series platforms using that protocol. This didn’t require any changes to Trident, but is an important change affecting compatibility for NetApp platforms.

Improved Trident Install and Uninstall

We heard from a number of users that the Trident install and uninstall processes were too complicated and difficult to use. So, we fixed it! Trident 17.07 introduces a greatly simplified install process which manages the creation and management of the Kubernetes resources needed by Trident. In addition to the pods and PV needed for Trident, this includes:

  • A dedicated namespace
  • A service account
  • RBAC roles

If you encounter an error during the install process and need to repeat, the install script will also manage cleaning up any existing objects automatically. And, if you’re uninstalling Trident from your Kubernetes cluster, the uninstall script will remove the objects if requested.

Last, but not least, all of this works with OpenShift too! This means that the OpenShift install process is just as simple and easy as with Kubernetes.

Simplified Trident Management using tridentctl

Extending the ease of use found in the Trident install and uninstall scripts, we’ve also added a much simpler way of managing Trident itself: tridentctl. The utility gives the administrator the ability to interact with Trident using the same paradigm as kubectl, so it’s familiar and super easy to understand what’s happening.

Just as you would expect, tridentctl has a set of commands which are very similar to kubectl:

Previously, managing Trident was done using the REST interface directly. With tridentctl that has all been simplified further, and we have changed the Trident deployment to no longer expose the REST interface by default. For example, adding a new backend is now as easy as this:

tridentctl create backend -f myBackendConfig.json


This is just a subset of the other fixes and enhancements in this release, so please be sure to see the full change log. Congratulations to the team on another fantastic release!

If you have any questions about Trident or the changes in the 17.07 release, please leave us a comment below, reach out using Slack, or open an issue using GitHub.

About Andrew Sullivan

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