Help Center/ Cloud Container Engine/ User Guide/ Old Console/ Storage (CSI)/ Using Local Disks as Storage Volumes
Updated on 2024-11-11 GMT+08:00

Using Local Disks as Storage Volumes

You can mount a file directory of the host where a container is located to a specified container path (the hostPath mode in Kubernetes) for persistent data storage. Alternatively, you can leave the source path empty (the emptyDir mode in Kubernetes), and a temporary directory of the host will be mounted to the mount point of the container for temporary storage.

Using Local Volumes

CCE supports four types of local volumes.

  • hostPath: mounts a file directory of the host where the container is located to the specified mount point of the container. For example, if the container needs to access /etc/hosts, you can use a hostPath volume to map /etc/hosts.
  • emptyDir: stores data temporarily. An emptyDir volume is first created when a pod is assigned to a node, and exists as long as that pod is running on that node. When a container pod is terminated, EmptyDir will be deleted and the data is permanently lost.
  • ConfigMap: A ConfigMap can be mounted as a volume, and all contents stored in its key are mounted onto the specified container directory. A ConfigMap is a type of resource that stores configuration information required by a workload. Its content is user-defined. For details about how to create a ConfigMap, see Creating a ConfigMap. For details about how to use a ConfigMap, see Using a ConfigMap.
  • Secret: You can store sensitive information such as passwords, in secrets and mount them as files for use by pods. A secret is a type of resource that holds sensitive data, such as authentication and key information. All content is user-defined. For details about how to create a secret, see Creating a Secret. For details about how to use a secret, see Using a Secret.

The following describes how to mount these four types of volumes.

hostPath

You can mount a path on the host to a specified container path. A hostPath volume is usually used to store workload logs permanently or used by workloads that need to access internal data structure of the Docker engine on the host.

  1. Log in to the CCE console.
  2. When creating a workload, click Data Storage in the Container Settings. Click the Local Volumes tab and click .
  3. Set parameters for adding a local volume, as listed in Table 1.

    Table 1 Setting parameters for mounting a hostPath volume

    Parameter

    Description

    Storage Type

    Select HostPath.

    Host Path

    Path of the host to which the local volume is to be mounted, for example, /etc/hosts.

    NOTE:

    Host Path cannot be set to the root directory /. Otherwise, the mounting fails. Mount paths can be as follows:

    • /opt/xxxx (excluding /opt/cloud)
    • /mnt/xxxx (excluding /mnt/paas)
    • /tmp/xxx
    • /var/xxx (excluding key directories such as /var/lib, /var/script, and /var/paas)
    • /xxxx (It cannot conflict with the system directory, such as bin, lib, home, root, boot, dev, etc, lost+found, mnt, proc, sbin, srv, tmp, var, media, opt, selinux, sys, and usr.)

    Do not set this parameter to /home/paas, /var/paas, /var/lib, /var/script, /mnt/paas, or /opt/cloud. Otherwise, the system or node installation will fail.

    Add Container Path

    Configure the following parameters:

    1. subPath: Enter a subpath, for example, tmp.

      A subpath is used to mount a local disk so that the same data volume is used in a single pod. If this parameter is left blank, the root path is used by default.

    2. Container Path: Enter the path of the container, for example, /tmp.
      This parameter indicates the container path to which a data volume will be mounted. Do not mount the volume to a system directory such as / or /var/run; this action may cause container errors. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that there are no files affecting container startup in the directory. Otherwise, such files will be replaced, resulting in failures to start the container and create the workload.
      NOTICE:

      When the container is mounted to a high-risk directory, you are advised to use an account with minimum permissions to start the container; otherwise, high-risk files on the host machine may be damaged.

    3. Permission
      • Read-only: You can only read the data volumes mounted to the path.
      • Read/Write: You can modify the data volumes mounted to the path. Newly written data is not migrated if the container is migrated, which may cause a data loss.

    Click Add Container Path to add multiple settings. Then, click OK.

emptyDir

emptyDir applies to temporary data storage, disaster recovery, and runtime data sharing. It will be deleted upon deletion or transfer of workload pods.

  1. Log in to the CCE console.
  2. When creating a workload, click Data Storage in the Container Settings. Click the Local Volumes tab and click .
  3. Set the local volume type to emptyDir and set parameters for adding a local volume, as described in Table 2.

    Table 2 Setting parameters for mounting an emptyDir volume

    Parameter

    Description

    Storage Type

    Select emptyDir.

    Medium

    • Default: Data is stored in hard disks, which is applicable to a large amount of data with low requirements on reading and writing efficiency.
    • Memory: Selecting this option can improve the running speed, but the storage capacity is subject to the memory size. This mode applies to scenarios where the data volume is small and the read and write efficiency is high.
    NOTE:
    • If you select Memory, any files you write will count against your container's memory limit. Pay attention to the memory quota. If the memory usage exceeds the threshold, OOM may occur.
    • If Memory is selected, the size of an emptyDir volume is 50% of the pod specifications and cannot be changed.
    • If Memory is not selected, emptyDir volumes will not occupy the system memory.

    Add Container Path

    Configure the following parameters:

    1. subPath: Enter a subpath, for example, tmp.

      A subpath is used to mount a local disk so that the same data volume is used in a single pod. If this parameter is left blank, the root path is used by default.

    2. Container Path: Enter the path of the container, for example, /tmp.
      This parameter indicates the container path to which a data volume will be mounted. Do not mount the volume to a system directory such as / or /var/run; this action may cause container errors. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that there are no files affecting container startup in the directory. Otherwise, such files will be replaced, resulting in failures to start the container and create the workload.
      NOTICE:

      When the container is mounted to a high-risk directory, you are advised to use an account with minimum permissions to start the container; otherwise, high-risk files on the host machine may be damaged.

    3. Permission
      • Read-only: You can only read the data volumes mounted to the path.
      • Read/Write: You can modify the data volumes mounted to the path. Newly written data is not migrated if the container is migrated, which may cause a data loss.

    Click Add Container Path to add multiple settings. Then, click OK.

ConfigMap

The data stored in a ConfigMap can be referenced in a volume of type ConfigMap. You can mount such a volume to a specified container path. The platform supports the separation of workload codes and configuration files. ConfigMap volumes are used to store workload configuration parameters. Before that, you need to create ConfigMaps in advance. For details, see Creating a ConfigMap.

  1. Log in to the CCE console.
  2. When creating a workload, click Data Storage in the Container Settings. Click the Local Volumes tab and click .
  3. Set the local volume type to ConfigMap and set parameters for adding a local volume, as shown in Table 3.

    Table 3 Setting parameters for mounting a ConfigMap volume

    Parameter

    Description

    Storage Type

    Select ConfigMap.

    Option

    Select the desired ConfigMap name.

    A ConfigMap must be created in advance. For details, see Creating a ConfigMap.

    Add Container Path

    Configure the following parameters:

    1. subPath: Enter a subpath, for example, tmp.
      • A subpath is used to mount a local volume so that the same data volume is used in a single pod.
      • The subpath can be the key and value of a ConfigMap or secret. If the subpath is a key-value pair that does not exist, the data import does not take effect.
      • The data imported by specifying a subpath will not be updated along with the ConfigMap/secret updates.
    2. Container Path: Enter the path of the container, for example, /tmp.
      This parameter indicates the container path to which a data volume will be mounted. Do not mount the volume to a system directory such as / or /var/run; this action may cause container errors. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that there are no files affecting container startup in the directory. Otherwise, such files will be replaced, resulting in failures to start the container and create the workload.
      NOTICE:

      When the container is mounted to a high-risk directory, you are advised to use an account with minimum permissions to start the container; otherwise, high-risk files on the host machine may be damaged.

    3. Set the permission to Read-only. Data volumes in the path are read-only.

    Click Add Container Path to add multiple settings. Then, click OK.

Secret

You can mount a secret as a volume to the specified container path. Contents in a secret are user-defined. Before that, you need to create a secret. For details, see Creating a Secret.

  1. Log in to the CCE console.
  2. When creating a workload, click Data Storage in the Container Settings. Click the Local Volumes tab and click .
  3. Set the local volume type to Secret and set parameters for adding a local volume, as shown in Table 4.

    Table 4 Setting parameters for mounting a secret volume

    Parameter

    Description

    Storage Type

    Select Secret.

    Secret

    Select the desired secret name.

    A secret must be created in advance. For details, see Creating a Secret.

    Add Container Path

    Configure the following parameters:

    1. subPath: Enter a subpath, for example, tmp.
      • A subpath is used to mount a local volume so that the same data volume is used in a single pod.
      • The subpath can be the key and value of a ConfigMap or secret. If the subpath is a key-value pair that does not exist, the data import does not take effect.
      • The data imported by specifying a subpath will not be updated along with the ConfigMap/secret updates.
    2. Container Path: Enter the path of the container, for example, /tmp.
      This parameter indicates the container path to which a data volume will be mounted. Do not mount the volume to a system directory such as / or /var/run; this action may cause container errors. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that there are no files affecting container startup in the directory. Otherwise, such files will be replaced, resulting in failures to start the container and create the workload.
      NOTICE:

      When the container is mounted to a high-risk directory, you are advised to use an account with minimum permissions to start the container; otherwise, high-risk files on the host machine may be damaged.

    3. Set the permission to Read-only. Data volumes in the path are read-only.

    Click Add Container Path to add multiple settings. Then, click OK.

Mounting a hostPath Volume Using kubectl

You can use kubectl to mount a file directory of the host where the container is located to a specified mount path of the container.

  1. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
  2. Run the following commands to configure the hostPath-pod-example.yaml file, which is used to create a pod.

    touch hostPath-pod-example.yaml

    vi hostPath-pod-example.yaml

    Mount the hostPath volume for the Deployment. The following is an example:

    apiVersion: apps/v1 
    kind: Deployment 
    metadata: 
      name: hostpath-pod-example 
      namespace: default 
    spec: 
      replicas: 1 
      selector: 
        matchLabels: 
          app: hostpath-pod-example 
      template: 
        metadata: 
          labels: 
            app: hostpath-pod-example 
        spec: 
          containers: 
          - image: nginx
            name: container-0 
            volumeMounts: 
            - mountPath: /tmp 
              name: hostpath-example 
          imagePullSecrets:
            - name: default-secret
          restartPolicy: Always 
          volumes: 
          - name: hostpath-example 
            hostPath: 
              path: /tmp/test
    Table 5 Local disk storage dependency parameters

    Parameter

    Description

    mountPath

    Mount path of the container. In this example, the volume is mounted to the /tmp directory.

    hostPath

    Host path. In this example, the host path is /tmp/test.

    spec.template.spec.containers.volumeMounts.name and spec.template.spec.volumes.name must be consistent because they have a mapping relationship.

  3. Run the following command to create the pod:

    kubectl create -f hostPath-pod-example.yaml

  4. Verify the mounting.

    1. Query the pod name of the workload (hostpath-pod-example is used as an example).
      kubectl get po|grep hostpath-pod-example

      Expected outputs:

      hostpath-pod-example-55c8d4dc59-md5d9   1/1     Running   0          35s
    2. Create the test1 file in the container mount path /tmp.
      kubectl exec hostpath-pod-example-55c8d4dc59-md5d9 -- touch /tmp/test1
    3. Verify that the file is created in the host path /tmp/test/.
      ll /tmp/test/

      Expected outputs:

      -rw-r--r--  1 root root    0 Jun  1 16:12 test1
    4. Create the test2 file in the host path /tmp/test/.
      touch /tmp/test/test2
    5. Verify that the file is created in the container mount path.
      kubectl exec hostpath-pod-example-55c8d4dc59-md5d9 -- ls -l /tmp

      Expected outputs:

      -rw-r--r-- 1 root root 0 Jun  1 08:12 test1
      -rw-r--r-- 1 root root 0 Jun  1 08:14 test2