Deploying Persistent Volume Claims with the Linode Block Storage CSI Driver
Traducciones al EspañolEstamos traduciendo nuestros guías y tutoriales al Español. Es posible que usted esté viendo una traducción generada automáticamente. Estamos trabajando con traductores profesionales para verificar las traducciones de nuestro sitio web. Este proyecto es un trabajo en curso.
What is the Linode Block Storage CSI Driver?
The Container Storage Interface (CSI) defines a standard that storage providers can use to expose block and file storage systems to container orchestration systems. Linode’s Block Storage CSI driver follows this specification to allow container orchestration systems, like Kubernetes, to use Block Storage Volumes to persist data despite a Pod’s lifecycle. A Block Storage Volume can be attached to any Linode to provide additional storage.
Before You Begin
This guide assumes you have a working Kubernetes cluster running on Linode. You can deploy a Kubernetes cluster on Linode in the following ways:
Use the Linode Kubernetes Engine (LKE) to deploy a cluster. LKE is Linode’s managed Kubernetes service. You can deploy a Kubernetes cluster using:
Use kubeadm to manually deploy a Kubernetes cluster on Linode. You can follow the Getting Started with Kubernetes: Use kubeadm to Deploy a Cluster on Linode guide to do this.
The Block Storage CSI Driver supports Kubernetes version 1.13 or higher. To check the version of Kubernetes you are running, you can issue the following command:
After deploying your cluster with kubeadm, to continue with this guide, you’ll need to install the CSI driver using the instructions in the Installing the Linode Block Storage CSI Driver guide.
NoteUsing either the Linode Kubernetes Engine or Terraform methods above will install both the Linode Block Storage CSI Driver and the
linodesecret token as part of their deployment methods automatically.
Create a Persistent Volume Claim
The instructions in this section will create a Block Storage volume billable resource on your Linode account. A single volume can range from 10 GiB to 10,000 GiB in size and costs $0.10/GiB per month or $0.00015/GiB per hour. If you do not want to keep using the Block Storage volume that you create, be sure to delete it when you have finished the guide.
If you remove the resources afterward, you will only be billed for the hour(s) that the resources were present on your account. Consult the Billing and Payments guide for detailed information about how hourly billing works and for a table of plan pricing.
A Persistent Volume Claim (PVC) consumes a Block Storage Volume. To create a PVC, create a manifest file with the following YAML:
- File: pvc.yaml
1 2 3 4 5 6 7 8 9 10 11
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc-example spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: linode-block-storage-retain
NoteIn order to retain your Block Storage Volume and its data, even after the associated PVC is deleted, you must use the
linode-block-storage-retainStorageClass. If, instead, you prefer to have your Block Storage Volume and its data deleted along with its PVC, use the
linode-block-storageStorageClass. See the Delete a Persistent Volume Claim for steps on deleting a PVC.
This PVC represents a Block Storage Volume. Because Block Storage Volumes have a minimum size of 10 gigabytes, the storage has been set to
10Gi. If you choose a size smaller than 10 gigabytes, the PVC will default to 10 gigabytes.
Currently the only mode supported by the Linode Block Storage CSI driver is
ReadWriteOnce, meaning that it can only be connected to one Kubernetes node at a time.
To create the PVC in Kubernetes, issue the
create command and pass in the
kubectl create -f pvc.yaml
After a few moments your Block Storage Volume will be provisioned and your Persistent Volume Claim will be ready to use.
You can check the status of your PVC by issuing the following command:
kubectl get pvc
You should see output like the following:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE pvc-example Bound pvc-0e95b811652111e9 10Gi RWO linode-block-storage-retain 2m
Now that you have a PVC, you can attach it to a Pod.
Attach a Pod to the Persistent Volume Claim
Now you need to instruct a Pod to use the Persistent Volume Claim. For this example, you will create a Pod that is running an ownCloud container, which will use the PVC.
To create a Pod that will use the PVC:
Create a manifest file for the Pod and give it the following YAML:
- File: owncloud-pod.yaml
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
apiVersion: v1 kind: Pod metadata: name: owncloud labels: app: owncloud spec: containers: - name: owncloud image: owncloud/server ports: - containerPort: 8080 volumeMounts: - mountPath: "/mnt/data/files" name: pvc-example volumes: - name: pvc-example persistentVolumeClaim: claimName: pvc-example
This Pod will run the
owncloud/serverDocker container image. Because ownCloud stores its files in the
owncloud-pod.yamlmanifest instructs the ownCloud container to create a mount point at that file path for your PVC.
volumessection of the
owncloud-pod.yaml, it is important to set the
claimNameto the exact name you’ve given your PersistentVolumeClaim in its manifest’s metadata. In this case, the name is
createcommand to create the ownCloud Pod:
kubectl create -f owncloud-pod.yaml
After a few moments your Pod should be up and running. To see the status of your Pod, issue the
kubectl get pods
You should see output like the following:
NAME READY STATUS RESTARTS AGE owncloud 1/1 Running 0 2m
To list the contents of the
/mnt/data/filesdirectory within the container, which is the mount point for your PVC, issue the following command on your container:
kubectl exec -it owncloud -- /bin/sh -c "ls /mnt/data/files"
You should see output similar to the following:
admin avatars files_external index.html lost+found owncloud.db owncloud.log
These files are created by ownCloud, and those files now live on your Block Storage Volume. The
admindirectory is the directory for the default user, and any files you upload to the
adminaccount will appear in this folder.
To complete the example, you should be able to access the ownCloud Pod via your browser. To accomplish this task, you will need to create a Service.
Create a Service manifest file and copy in the following YAML:
- File: owncloud-service.yaml
1 2 3 4 5 6 7 8 9 10 11 12
kind: Service apiVersion: v1 metadata: name: owncloud spec: selector: app: owncloud ports: - protocol: TCP port: 80 targetPort: 8080 type: NodePort
The service manifest file will use the
NodePortmethod to get external traffic to the ownCloud service. NodePort opens a specific port on all cluster nodes and any traffic that is sent to this port is forwarded to the service. Kubernetes will choose the port to open on the nodes if you do not provide one in your service manifest file. It is recommended to let Kubernetes handle the assignment. Kubernetes will choose a port in the default range,
Alternatively, you could use the
LoadBalancerservice type, instead of NodePort, which will create Linode NodeBalancers that will direct traffic to the ownCloud Pods. Linode’s Cloud Controller Manager (CCM) is responsible for provisioning the Linode NodeBalancers. For more details, see the Kubernetes Cloud Controller Manager for Linode repository.
Create the service in Kubernetes by using the
createcommand and passing in the
owncloud-service.yamlfile you created in the previous step:
kubectl create -f owncloud-service.yaml
To retrieve the port that the ownCloud Pod is listening on, use the
describecommand on the newly created Service:
kubectl describe service owncloud
You should see output like the following:
Name: owncloud Namespace: default Labels: <none> Annotations: <none> Selector: app=owncloud Type: NodePort IP: 10.106.101.155 Port: <unset> 80/TCP TargetPort: 8080/TCP NodePort: <unset> 30068/TCP Endpoints: 10.244.1.17:8080 Session Affinity: None External Traffic Policy: Cluster Events: <none>
NodePort. In this example the port is
Get a list of your cluster’s nodes. You will need this to find one of your node’s external IP addresses.
kubectl get nodes
You will see a similar output:
NAME STATUS ROLES AGE VERSION example-cluster-master-1 Ready master 104m v1.17.0 example-cluster-node-1 Ready <none> 103m v1.17.0 example-cluster-node-2 Ready <none> 104m v1.17.0 example-cluster-node-3 Ready <none> 103m v1.17.0
Describe any one of your nodes in order to retrieve its external IP address. The node which you select does not matter, however, ensure that you do not use your cluster’s master.
kubectl describe nodes example-cluster-node-1 | grep 'ExternalIP'
The output will include your node’s external IP address:
The IP address of the node in this example is
192.0.2.0. Your ownCloud instance in this example would be accessible from
Navigate to the IP address of the node, including the NodePort you looked up in a previous step. You will be presented with the ownCloud log in page. You can log in with the username
adminand the password
Upload a file. You will use this file to test the Persistent Volume Claim.
The Persistent Storage Claim has been created and is using your Block Storage Volume. To prove this point, you can delete the ownCloud Pod and recreate it, and the Persistent Storage Claim will continue to house your data:
kubectl delete pod owncloud kubectl create -f owncloud-pod.yaml
Once the Pod has finished provisioning you can log back in to ownCloud and view the file you previously uploaded.
You have successfully created a Block Storage Volume tied to a Persistent Volume Claim and have mounted it with a container in a Pod.
Delete a Persistent Volume Claim
To delete the Block Storage PVC created in this guide:
First, delete the ownCloud Pod. This command will also result in your Block Storage Volume being detached from the cluster.
kubectl delete pods owncloud
Then, delete the persistent volume claim:
kubectl delete pvc pvc-example
If you used the
linode-block-storage-retainStorageClass when creating your PVC, this command will delete the PVC, however, your Block Storage Volume and its data will persist in a detached state. To permanently remove the Block Storage Volume from your Linode Account, see How to Delete a Block Storage Volume.
If, instead, you used the
linode-block-storageStorageClass when creating your PVC, this command will delete the PVC along with your Block Storage Volume and its data.
You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.
This page was originally published on