Let me introduce the all new CSI Trident, now available with Trident 19.07 Alpha! The Container Storage Interface (CSI) provides a standard to enable provisioners to talk with multiple orchestrators. This is a community effort driven by the Cloud Native Computing Foundation (CNCF) Storage Special Interest Group (SIG). With CSI, Kubernetes community has released components which are not a part of the Kubernetes core that can interact with components implemented by the storage vendors to make storage integration more seamless. The Kubernetes implementation of CSI has been promoted to GA in the Kubernetes v1.13 release.  

With the Trident 19.07 Alpha release, Trident now fully adheres to the latest CSI 1.1 specification; hence the name “CSI Trident”There are quite a few benefits in abiding by the this standard. CSI Trident can now fix issues or add features without touching the Kubernetes core. It can also absorb any standardized future changes or features efficiently.  

This blog covers CSI Trident’s install, implementation and usage. 

Before we start, please Note 

1. Trident’s 19.07 Alpha release is only for preview and for greenfield deployments. Do not deploy in a production environment or upgrade from a current Trident version.
2. The CSI Trident Alpha version is supported on Kubernetes version 1.13 and 1.14.
3. When installing CSI Trident Alpha on Kubernetes version 1.13, make sure to set  “CSIDriverRegistry”  and “CSINodeInfo” feature-gates as true . These gates are enabled by default in Kubernetes version    1.14. 

  • Are there any special install procedures for CSI Trident? 

 There are no special install procedures required for installing CSI Trident Alpha on Kubernetes version 1.14Just install Trident 19.07 Alpha build using the normal “tridentctl install -n <namespace>” command and Trident will be installed with the required CSI Kubernetes sidecar containers.  

 However, for Kubernetes version 1.13, “--csi” option needs to be used along with the “tridentctl install –n <namespace>” command to install CSI Trident Alpha or else non-CSI Trident will be deployed. 

  •  New CSI Trident…uhm!!! Does this mean Trident experience and functionalities have changed?  

Not at all. Even though the CSI Trident has been plumbed under the hood to adhere to CSI spec, from the user's point of view, there are no changes as far as the experience and functionalities are concerned.  

  •  How does volume provisioning happen with CSI Trident? 

The Kubernetes external-provisioner sidecar, constantly inspects the Kubernetes API for any Persistent Volume Claim (PVC) objects. Once a PVC is discovered, the external provisioner uses the information from the PVC (such as volume size, annotations, etc.), passes the information and delegates the volume creation to the CSI driver. Once the volumes are created, the Kubernetes volume metadata will have the type field of the volumes set as “csi”. The external-attacher sidecar will be responsible for monitoring the VolumeAttachment objects to attach the newly created volume to a specified node. In the CSI implementation, its CSI Trident who is responsible for attaching the volumes to the cluster hosts on demand, not kubelet. 

Fig1: CSI Trident Alpha Implementation Block Diagram                 

  • Is it possible to do a volume clone, volume resize and a volume import using the CSI Trident? 

CSI Trident will support volume resizing and volume cloning feature. The commands to do these volume operations remains the same. However, the volume import feature is not supported in CSI Trident Alpha release 

  • Are there any new features that have been released as a part of CSI Trident? 

Yes, on-demand volume snapshotting and creating Persistent Volumes from Snapshots has been introduced as a part of CSI Trident Alpha. For creating Persistent Volumes from snapshot, ensure that the VolumeSnapshotDataSource feature-gate has been enabled. For more information on this feature, refer to the blog On demand snapshots with CSI Trident.

  • How do provision a volume through CSI Trident? 

As mentioned before there is no difference in the experience and functionality of CSI Trident. The steps for provisioning a volume through CSI Trident remains the same as before. However, as a reminder, we will briefly discuss the steps to provision a volume using CSI Trident.  

  1. Add the required backend. Create the backend json file with the required parameters and create the backend using the  “tridentctl create backend” command.
  2. Create a StorageClass to associate a provisioner. Please note while creating the StorageClass, make sure to set the provisioner as “csi.trident.netapp.io” . Create the StorageClass using the “kubectl create command  
$ cat sc-nas.yaml apiVersion: storage.k8s.io/v1  
kind: StorageClass   metadata:
  name: silver
provisioner: csi.trident.netapp.io
  backendType: "ontap-nas" 
  Use the “kubectl get sc” command to check the created StorageClass. $ kubectl get sc
NAME     PROVISIONER             AGE
silver   csi.trident.netapp.io   27h 

3. Generate a PersistentVolumeClaim to provision a volume through CSI Trident. Set the required size and the storageclass  as “silver” which has been created in the previous step. Use the “kubectl create” command to create the PVC. 

$ cat pvc-nas.yaml
kind: PersistentVolumeClaim
apiVersion: v1
  name: persistent-volume-claim-nas
  - ReadWriteOnce
      storage: 10Gi
  storageClassName: silver

 Use the “kubectl get pvc” command to check the created PersistentVolumeClaim.

$ kubectl get pvc persistent-volume-claim-nas
NAME                       STATUS         VOLUME                     CAPACITY   ACCESS MODES STORAGECLASS   AGE

persistent-volume-claim-nas Bound  pvc-6fab5b79-96a8-....fa163e72c017   10Gi       RWO         silver     26h


4. Now let's explore the PersistentVolume that is bound to the PersistentVolumeClaim. Looking at the yaml output of the PersistentVolume describe, it is possible to see that volume is a “csi” volume and not a “nfs” or an “iscsi” volume. Examine the driver name and the volume attributes in the yaml output.. 

$ kubectl get pv NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM             STORAGECLASS   REASON   AGE
pvc-6fab5b79-96a8-11e9-b513-fa163e72c017   10Gi       RWO            Delete           Bound    default/persistent-volume-claim-nas    silver                  25h 

$ kubectl get pv pvc-6fab5b79-96a8-11e9-b513-fa163e72c017 -o yaml
apiVersion: v1
kind: PersistentVolume
    pv.kubernetes.io/provisioned-by: csi.trident.netapp.io
  creationTimestamp: "2019-06-24T17:49:42Z"
  - kubernetes.io/pv-protection
  - external-attacher/csi-trident-netapp-io
  name: pvc-6fab5b79-96a8-11e9-b513-fa163e72c017
  resourceVersion: "10045"
  selfLink: /api/v1/persistentvolumes/pvc-6fab5b79-96a8-11e9-b513-fa163e72c017
  uid: 7246470e-96a8-11e9-b513-fa163e72c017
  - ReadWriteOnce
    storage: 10Gi
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: persistent-volume-claim-nas
    namespace: default
    resourceVersion: "8926"
    uid: 6fab5b79-96a8-11e9-b513-fa163e72c017
    driver: csi.trident.netapp.io
    fsType: ext4
      backendUUID: 18011307-9c21-4658-bf3f-a6c4b02d4aaa
      internalName: KOLLY_pvc_6fab5b79_96a8_11e9_b513_fa163e72c017
      name: pvc-6fab5b79-96a8-11e9-b513-fa163e72c017
      protocol: file
      storage.kubernetes.io/csiProvisionerIdentity: 1561393383642-8081-csi.trident.netapp.io
    volumeHandle: pvc-6fab5b79-96a8-11e9-b513-fa163e72c017
  persistentVolumeReclaimPolicy: Delete
  storageClassName: silver
  volumeMode: Filesystem
  phase: Bound 

 5. Mount the volume in a pod. Spin up a ngnix pod that mounts the PV under /usr/share/nginx/html. 

$ cat task-pv-pod.yaml
kind: Pod
apiVersion: v1
  name: task-pv-pod
  - name: task-pv-storage
      claimName: persistent-volume-claim-nas
  - name: task-pv-container
    image: nginx
    - containerPort: 80
      name: "http-server"
     - mountPath: "/usr/share/nginx/html"
       name: task-pv-storage 

If you do a “kubectl describe” on the pod, you will be able to see that the pod has come up and the volume attach has succeeded. One of the main points to note here is that CSI Trident is responsible for attaching the volumes to the cluster hosts on demand and not kubelet. 

Type    Reason                  Age   From                      Message
----    ------                  ----  ----                      -------
Normal  Scheduled               23s   default-scheduler         Successfully assigned default/task-pv-pod to scspa0803274002
Normal  SuccessfulAttachVolume  23s   attachdetach-controller   AttachVolume.Attach succeeded for volume "pvc...17"
Normal  Pulling                 15s   kubelet, scspa0803274002  Pulling image "nginx"
Normal  Pulled                  14s   kubelet, scspa0803274002  Successfully pulled image "nginx"
Normal  Created                 14s   kubelet, scspa0803274002  Created container task-pv-container
Normal  Started                 14s   kubelet, scspa0803274002  Started container task-pv-container 

 Lots more to come.... 

In this blog we have briefly discussed the new CSI Trident implementation which has been released along with 19.07 Alpha version. Please use a non-production cluster to test, experiment, validate, and/or break as much as possible…and we would love to hear your feedback! As we wait for the next main release, please watch out, there is more to come. 

We know you will have more questions about things which concern you. We haven’t covered every possible scenario, and probably never will, so please reach out to us on ourSlack team, GitHub issues. We’re happy to help! 

About Jacob Andathethu

A dynamic professional with over 13 years of experience working in Data Storage Industry [NetApp and Dell-EMC]
Currently working as a Technical Marketing Engineer for Open Ecosystem Products in NetApp (Docker,Docker Swarm,Kubernetes, OpenShift).

Pin It on Pinterest