VK Cloud logo
Support

Working with persistent volumes

Persistent volumes (PVs) can be connected to simple demo applications in various ways. Next, Persistent Volume Claims (PVCs) will be used to connect them. An Ingress resource will be created to test the functionality of the applications and the volumes connected to them.

Before you begin

  1. Create a Kubernetes cluster of the latest version, if not done so already.

    When creating the cluster:

    • Select the Assign external IP option.
    • Create one group of worker nodes with virtual machine type STD3-2-8 in the MS1 availability area with total computing resources: 2 vCPU, 8 GB RAM (or more). This is necessary to be able to schedule all the required objects.

    For example, you can create one group of nodes with virtual machine type STD3-2-8.

    Other cluster parameters are at your discretion.

  2. Make sure that the NGINX Ingress add-on (ingress-nginx) is installed in a cluster with default parameters. It will be required to provide access to demo applications.

  3. Make sure that you can connect to the cluster using kubectl.

  4. Install curl if the utility is not already installed.

1. Create demo applications and connect PVs to them

The following will demonstrate how to create several NGINX-based web applications to display web pages written to the PVs connected to those applications. The NGINX nginxdemos/nginx-hello image is used, which displays web pages from the /usr/share/nginx/html directory, so all PVs will be mounted in the application pods via this path.

You can create one or more demo applications, depending on which way you want to connect the PVs.

Connecting block storages

Block stores are connected to the cluster with Cinder CSI.

When using this type of storage:

  • only one pod can access storage (multiple pods cannot use block storage at the same time);
  • as a consequence, the ReadWriteOnce mode must be used to access the storage.

This example will create:

  1. A dynamic PVC that will create a permanent volume based on the given parameters.

  2. A coffee application as a single pod deployment, and its corresponding service.

    For this application there will also be an initialization container (initContainer) which will write the web page to the PV.

To connect a PV using dynamic PVC:

  1. Examine the connection features:

    1. The required storage size is specified in the spec.resources.requests.storage parameter of the PersistentVolumeClaim resource. In this example it is 1 GB.
    2. For the PersistentVolumeClaim resource, specify the storage class in the spec.storageClassName parameter. The storage class must use the same availability zone as the worker node on which the pod (application) will reside. Otherwise, an attempt to connect a PV corresponding to the PVC to the pod on that node will fail. In this example, the pod will be placed on a group of worker nodes in the MS1 availability zone and use the csi-ceph-hdd-ms1 storage class from the same zone.
    3. The storage access mode is set in the spec.accessModes parameter for the PersistentVolumeClaim resource.
    4. ReclaimPolicy Delete is used for PV (it follows from selected storage class). When the PVC is deleted, the disk corresponding to the PV will automatically be deleted.

  2. Create a manifest for the coffee application.

  3. Apply this manifest to the cluster to create all necessary resources:

    kubectl apply -f ./coffee.yaml

Connecting file storages

File storages are connected to the cluster using a PV that is configured to use the existing storage via the required protocol, such as NFS.

When using this type of storage:

  • Multiple pods can access the storage at once;
  • as a consequence, the ReadWriteMany mode must be used to access the storage.

This example will create:

  1. NFS file storage in the Cloud Servers service.
  2. A PV corresponding to this storage.
  3. Static PVC using an already created PV.
  4. Application milkshake as a StatefulSet of two pods, as well as the corresponding services.

To connect an NFS PV using a static PVC:

  1. Create file storage.

    When creating it, specify:

    • Name of file storage: any name, such as storage-milkshake.
    • Storage size: `10 GB'.
    • Protocol: NFS.
    • Network: network and subnet where the Kubernetes cluster is located. This information can be found on the cluster page.
    • File storage network: existing network. If a suitable network is not on the list, select Create new network.

  2. View information about the created file storage.

    Save the value of the Connection point parameter.

  3. Examine the specifics of the connection:

    1. The storage sizes specified in the spec.capacity.storage and spec.resources.requests.storage parameters for the PersistentVolumeClaim resource must match the size of the created file storage. In this example it's 10 GB.

    2. For the PersistentVolumeClaim resource, use an empty value in the storageClassName storage class parameter.

    3. For the PersistentVolume resource:

      1. The storage access mode is specified in the spec.accessModes parameter for the PersistentVolume resource.
      2. The spec.mountOptions parameter set must contain an nfsvers entry with version 4.0.

    4. Instead of an initialization container to write a web page to a PV, a single-run Kubernetes task (job) is used. This approach works because in this case all pods will have access to the same PV.

    5. ReclaimPolicy Retain is used for the PV because the Recycle policy will not allow instant removal of the volume when it becomes unnecessary. Clearing a volume of data takes a long time. The Delete policy is not used so that you can monitor the state of the storage manually and not accidentally delete it.

  4. Create a manifest for the milkshake application.

    For the PersistentVolume resource, specify:

    • IP address from the Connection point of the file storage as the value of the spec.nfs.server parameter.
    • Data after the IP address (/shares/...) as a value of the spec.nfs.path parameter.

  5. Apply this manifest to the cluster to create all necessary resources:

    kubectl apply -f ./milkshake.yaml

2. Check the functionality of demo applications and PVs

  1. Create a manifest for the Ingress resource through which application requests will go.

  2. Apply this manifest to the cluster to create all necessary resources:

    kubectl apply -f ./cafe-ingress.yaml

  3. Define the public IP address of the Ingress controller.

  4. Check the availability of the applications with curl using the IP address of the Ingress controller.

    Run the command:

    curl --resolve cafe.example.com:80:<Ingress IP address> http://cafe.example.com/tea

    A response should be displayed:

    The tea pod says Hello World to everyone! This file is located on the statically claimed PV.

Delete unused resources

A running cluster consumes computing resources and is charged accordingly. If you no longer need the Kubernetes resources you created to test persistent volumes, delete them:

  1. Delete the resources described in the manifests:

    kubectl delete -f ./cafe-ingress.yamlkubectl delete -f ./milkshake.yamlkubectl delete -f ./juice.yamlkubectl delete -f ./coffee.yamlkubectl delete -f ./tea.yaml

  2. Remove unused storage:

    1. The disk used by the tea application.

    2. The NFS repository used by the milkshake application.

    All other Cinder stores created with dynamic PVCs will be deleted automatically.

  3. Stop the cluster you created to use it later or delete it permanently.

Was this article helpful?
Was this article helpful?
Did you find a mistake in the article? Select it and click
Ctrl+Enter
Privacy Policy