Deploy a sample application and verify that the CSI driver is working
You can test the CSI driver functionality with a sample application. This topic shows one example, but you can also do the following:
-
Deploy a sample application that uses the external snapshotter to create volume snapshots. For more information, see Volume Snapshots
on GitHub. -
Deploy a sample application that uses volume resizing. For more information, see Volume Resizing
on GitHub.
This procedure uses the Dynamic volume provisioning
-
Clone the Amazon EBS Container Storage Interface (CSI) driver
GitHub repository to your local system. git clone https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/deploy/kubernetes/overlays/stable/ecr/kustomization.yaml
-
Navigate to the
dynamic-provisioning
example directory.cd aws-ebs-csi-driver/examples/kubernetes/dynamic-provisioning/
-
Deploy the
ebs-sc
storage class,ebs-claim
persistent volume claim, andapp
sample application from themanifests
directory.kubectl apply -f manifests/
-
Describe the
ebs-sc
storage class.kubectl describe storageclass ebs-sc
The example output is as follows.
Name: ebs-sc IsDefaultClass: No Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{},"name":"ebs-sc"},"provisioner":"ebs.csi.aws.com","volumeBindingMode":"WaitForFirstConsumer"} Provisioner: ebs.csi.aws.com Parameters: <none> AllowVolumeExpansion: <unset> MountOptions: <none> ReclaimPolicy: Delete VolumeBindingMode: WaitForFirstConsumer Events: <none>
Note The storage class uses the
WaitForFirstConsumer
volume binding mode. This means that volumes aren't dynamically provisioned until a pod makes a persistent volume claim. For more information, see Volume Binding Modein the Kubernetes documentation. -
Watch the pods in the default namespace. After a few minutes, the
app
pod's status changes toRunning
.kubectl get pods --watch
Enter
Ctrl
+C
to return to a shell prompt. -
List the persistent volumes in the default namespace. Look for a persistent volume with the
default/ebs-claim
claim.kubectl get pv
The example output is as follows.
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-
37717cd6-d0dc-11e9-b17f-06fad4858a5a
4Gi RWO Delete Bound default/ebs-claim ebs-sc 30s -
Describe the persistent volume. Replace
pvc-
with the value from the output in the previous step.37717cd6-d0dc-11e9-b17f-06fad4858a5a
kubectl describe pv pvc-
37717cd6-d0dc-11e9-b17f-06fad4858a5a
The example output is as follows.
Name: pvc-
37717cd6-d0dc-11e9-b17f-06fad4858a5a
Labels: <none> Annotations: pv.kubernetes.io/provisioned-by: ebs.csi.aws.com Finalizers: [kubernetes.io/pv-protection external-attacher/ebs-csi-aws-com] StorageClass: ebs-sc Status: Bound Claim: default/ebs-claim Reclaim Policy: Delete Access Modes: RWO VolumeMode: Filesystem Capacity: 4Gi Node Affinity: Required Terms: Term 0: topology.ebs.csi.aws.com/zone in [region-code
] Message: Source: Type: CSI (a Container Storage Interface (CSI) volume source) Driver: ebs.csi.aws.com VolumeHandle:vol-0d651e157c6d93445
ReadOnly: false VolumeAttributes: storage.kubernetes.io/csiProvisionerIdentity=1567792483192
-8081-ebs.csi.aws.com Events: <none>The Amazon EBS volume ID is the value for
VolumeHandle
in the previous output. -
Verify that the pod is writing data to the volume.
kubectl exec -it app -- cat /data/out.txt
The example output is as follows.
Wed May 5 16:17:03 UTC 2021 Wed May 5 16:17:08 UTC 2021 Wed May 5 16:17:13 UTC 2021 Wed May 5 16:17:18 UTC 2021 ...
-
After you're done, delete the resources for this sample application.
kubectl delete -f manifests/