Volumes

    Cluster administrators configure PersistentVolumes using storage classes. In other words, to create a PersistentVolumeClaim in a project, your cluster must have an available storage class. If no customized storage class is configured when you install KubeSphere, OpenEBS is installed in your cluster by default to provide Local Persistent Volumes. However, it does not support dynamic volume provisioning. In a production environment, it is recommended you configure storage classes in advance to provide persistent storage services for your apps.

    This tutorial demonstrates how to create a volume, mount a volume and use volume features from its details page.

    • You need to create a workspace, a project and a user (). The user must be invited to the project with the role of operator. For more information, see .

    • If you want to dynamically provision a volume, you need to configure a storage class that supports dynamic provisioning.

    All the volumes that are created on the Volumes page are PersistentVolumeClaim objects. KubeSphere binds a PersistentVolumeClaim to a PersistentVolume that satisfies the request you set for the PersistentVolumeClaim, such as capacity and access mode. When you create an application workload, you can select the desired volume and mount it to your workload.

    1. Log in to the web console of KubeSphere as project-regular and go to a project. Click Volumes under Storage from the navigation bar, and you see all volumes that have been mounted to workloads in the project.

    2. To create a volume, click Create on the Volumes page.

    3. On the Storage Settings page, select a method to create a volume.

      • From Storage Class. You can configure storage classes both and after the installation of KubeSphere.

      • From Volume Snapshot. To use a snapshot to create a volume, you must create a volume snapshot first.

      Select From Storage Class in this example. For more information about how to create a volume by snapshot, see .

    4. Select a storage class from the drop-down list. This tutorial uses , a standard storage class provided by QingCloud Platform. You can select your own storage class.

    5. Depending on the storage class you select, you may see different access modes in this section as some PersistentVolumes only support specific access modes. In total, there are three access modes.

      • ReadWriteOnce: The volume can be mounted as read-write by a single node.
      • ReadOnlyMany: The volume can be mounted as read-only by many nodes.
      • ReadWriteMany: The volume can be mounted as read-write by many nodes.
    6. Under Volume Capacity, specify the size of the volume. Click Next to continue.

    7. On the Advanced Settings page, you can add metadata to the volume, such as Labels and Annotations. They can be used as identifiers to search for and schedule resources.

    8. Click Create to finish creating a volume.

    9. For some volumes, you can see the status reach Bound from Pending immediately after they are created as they are provisioned dynamically. For volumes that remain in the Pending status, they will turn to Bound once they are mounted to a workload. The difference is decided by the storage class of the volume.

      For example, if you install KubeSphere with the default storage class (OpenEBS), you can only create local volumes, which means dynamic provisioning is not supported. This is specified by the volumeBindingMode field which is set to WaitForFirstConsumer.

    When you create application workloads, such as Deployments, and DaemonSets, you can mount volumes to them.

    Note

    This tutorial does not explain how to create workloads. For more information, see related guides in Application Workloads.

    On the Volume Settings page, you can see there are different volumes that you can mount to your workload.

    • Add Volume Template (Only available to ): A volume template is used to dynamically create a PVC. Mount the PVC of the StorageClass type to the Pod by setting the name, storage class, access mode, capacity and path, which are all indicated by the field .

    • Mount Volume: Support emptyDir volumes and PVCs.

      In Mount Volume, there are 3 kinds of volumes:

      • Existing Volume: Use a PVC to mount.

      • Temporary Volume: Use an emptyDir volume to mount.

        The temporary storage volume represents emptyDir, which is first created when a Pod is assigned to a node, and exists as long as that Pod is running on that node. An emptyDir volume offers an empty directory from which containers in the Pod can read and write. Depending on your deployment environment, an emptyDir volume can be stored on any medium that is backing the node, which could be a disk or SSD. When the Pod is removed from the node for any reason, the data in the emptyDir is deleted forever.

      • HostPath Volume: Use a hostPath volume to mount.

        A HostPath volume mounts a file or directory from the host node’s filesystem into your Pod. This is not something that most Pods will need, but it offers a powerful escape hatch for some applications. For more information, refer to .

    • Mount ConfigMap or Secret: Support key-value pairs of ConfigMaps or .

      A Secret volume is used to provide sensitive information, such as passwords, OAuth tokens, and SSH keys, for Pods. Secret volumes are backed by tmpfs (a RAM-backed filesystem) so they are never written to non-volatile storage.

      A is used to store configuration data in the form of key-value pairs. The ConfigMap resource provides a way to inject configuration data into Pods. The data stored in a ConfigMap object can be referenced in a volume of type configMap and then consumed by containerized applications running in a Pod. ConfigMaps are often used in the following cases:

      • Set the value of environment variables.
      • Set command parameters in containers.
      • Create a configuration file in volumes.

    After a volume is created, you can see detailed information of it, edit it, or leverage volume features. To view volume details, click a volume on the Volumes page.

    On the details page, you can click Edit Information to change its basic information. Click More and you can edit its YAML file or delete this volume.

    To delete a volume, make sure the volume is not mounted to any workload. To unmount a volume, go to the details page of a workload. From the More drop-down list, click Edit Settings. Select Volumes from the pop-up window, and click the dustbin icon to unmount it.

    If the status of a volume remains Terminating for a long time after you clicked Delete, manually delete it by using the following command:

    From the More drop-down menu, there are three additional options provided by KubeSphere based on the underlying storage plugin, also known as Storage Capability. Volume features include:

    • Clone: Create a same volume.
    • Expand: Increase the size of a volume. Keep in mind that you cannot reduce the size of a volume on the console due to possible data loss.

    For more information about Storage Capability, see Design Documentation.

    Note

    Some in-tree or special CSI plugins may not be covered by . If KubeSphere does not display the correct features in your cluster, you can make adjustments according to .

    KubeSphere retrieves metric data of PVCs with Filesystem mode from Kubelet to monitor volumes including capacity usage and inode usage.