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.14. Just 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 I 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.
- Add the required backend. Create the backend json file with the required parameters and create the backend using the “tridentctl create backend” command.
- 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
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 metadata: name: persistent-volume-claim-nas spec: accessModes: - ReadWriteOnce resources: requests: 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 metadata: annotations: pv.kubernetes.io/provisioned-by: csi.trident.netapp.io creationTimestamp: "2019-06-24T17:49:42Z" finalizers: - 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 spec: accessModes: - ReadWriteOnce capacity: storage: 10Gi claimRef: apiVersion: v1 kind: PersistentVolumeClaim name: persistent-volume-claim-nas namespace: default resourceVersion: "8926" uid: 6fab5b79-96a8-11e9-b513-fa163e72c017 csi: driver: csi.trident.netapp.io fsType: ext4 volumeAttributes: 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 status: 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 metadata: name: task-pv-pod spec: volumes: - name: task-pv-storage persistentVolumeClaim: claimName: persistent-volume-claim-nas containers: - name: task-pv-container image: nginx ports: - containerPort: 80 name: "http-server" volumeMounts: - 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.
Events: 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 our Slack team, GitHub issues. We’re happy to help!