Last modified December 11, 2020
Using persistent volumes with the EBS CSI driver on AWS
The Container Storage Interface (CSI) has been promoted to general availability (GA) in Kubernetes v1.13 and is becoming the standard to replace the current Kubernetes
in-tree storage plugin to handle volumes for different providers.
The aws-ebs-csi-driver-app, offered via our App Platform in the Giant Swarm Playground catalog, provides a CSI interface to manage the lifecycle of Amazon EBS volumes.
Installing the EBS CSI driver
To install the EBS CSI driver you will need to follow these steps:
- Access the web interface and select the cluster on which you want to install the EBS CSI driver.
- Open the Apps tab.
- Click the Install App button
- Select the Giant Swarm Playground catalog.
- Select the App named aws-ebs-csi-driver-app.
- Click the Configure & Install button. Make sure that the correct cluster is selected.
- Click the Install App button.
Once you installed the
aws-ebs-csi-driver-app from Giant Swarm Playground catalog, your Kubernetes cluster will have a storage class
The storage class offers volume encryption and allows resizing by default.
Creating persistent volumes
The most straight forward way to create a persistent volume is to create a PersistentVolumeClaim resource with the storage class
ebs-csi, which will automatically create a corresponding
PersistentVolume (PV) resource for you.
Alternatively, to be able to set more specific parameters on your PV, you can first create a PersistentVolume resource and then claim that PV using a
Under the hood, the EBS CSI driver will take care that a corresponding EBS volume with the correct parameters is created.
The EBS volume and its data will persist as long as the corresponding PV resource exists. Deleting the PV resource will also delete the corresponding EBS volume, which means that all stored data will be lost at that point.
Using persistent volumes in a pod
Once you have a PersistentVolumeClaim you can claim it as a volume in your pods.
Note that an EBS volume can only be used by a single pod at the same time. Thus, the access mode of your PVC can only be
Under the hood the EBS volume stays detached from your nodes as long as it is not claimed by a pod. As soon as a pod claims it, it gets attached to the EC2 instance of the node that holds the pod.
First we create a PVC:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-claim spec: accessModes: - ReadWriteOnce storageClassName: ebs-csi resources: requests: storage: 5Gi
Note that the access mode, while being fixed with EBS, still needs to be defined as
ReadWriteOnce in the manifest (see the
Further, we need to define the storage class
ebs-csi because it is not the default storage class (default
Now we can create a Pod that uses our PVC:
kind: Pod apiVersion: v1 metadata: name: mypod spec: containers: - name: myfrontend image: nginx volumeMounts: - mountPath: "/var/www/html" name: mypd volumes: - name: mypd persistentVolumeClaim: claimName: my-claim
Now we have an NGINX pod which serves the content of our EBS volume.
Increasing storage capacity of a volume
Starting with Kubernetes v1.16, CSI volumes can be expanded by simply editing the claim (the
PersistentVolumeClaim resource) and requesting a larger size. This will trigger an update of the associated
PersistentVolume resource and the underlying EBS volume.
PersistentVolumeClaim resource in use is enabled by default with Kubernetes v1.15, so there is no need to delete and recreate a pod.
Note: You can only resize volumes formatted with one of the file systems XFS, Ext3, or Ext4.
Warning: Expanding EBS volumes is a time-consuming operation. Also, there is a per-volume quota of 1 modification every 6 hours.
Deleting persistent volumes
The reclaim policy, which tells the cluster what to do with the volume after it has been released of its claim, is set to
Delete. Thus, deleting the
PersistentVolume resource will also delete the respective EBS volume. Similarly, by default if you delete a
PersistentVolumeClaim resource, the respective
PersistentVolume and EBS volume will get deleted.
Note that deleting a pod that is using persistent volumes might not automatically also delete its storage, so in most cases you will have to manually delete the
PersistentVolumeClaim resources to clean up.