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.
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 metadata: name: myfavoritepv annotations: volume.beta.kubernetes.io/storage-class: performance spec: accessModes: - ReadWriteOnce resources: requests: 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 metadata: name: myfavoritepv spec: accessModes: - ReadWriteOnce resources: requests: 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
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: standard annotations: storageclass.kubernetes.io/is-default-class: "true" provisioner: netapp.io/trident parameters: 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
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
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!