Local storage mounts files or directories from a host node's file system into pods running in an Enterprise Distributed Application Service (EDAS) Kubernetes cluster. This gives containers direct access to the host's file system for high-speed file I/O without network overhead -- useful for reading host-level logs, sharing temporary data between containers, or accessing node-specific configuration files.
How local storage works
In a Container Service for Kubernetes (ACK) cluster managed by EDAS, local storage uses Kubernetes hostPath volumes to mount host file system paths into containers.
EDAS supports two local storage types:
| Type | Kubernetes volume | Use case | Data lifecycle |
|---|---|---|---|
| Local File of Host | hostPath | Access specific files or directories on the host node, such as system logs or node-level configuration | Data persists on the host independently of the pod lifecycle |
| emptyDir | emptyDir | Share temporary data between containers in the same pod, such as scratch space, caches, or inter-container data exchange | Created when the pod starts on a node. Deleted permanently when the pod is removed from the node |
hostPath volumes expose the host file system to containers, which presents security risks. A container with host file system access could read privileged credentials (such as kubelet credentials) or exploit the container runtime socket for container escape. If you need persistent storage, use a local PersistentVolume instead. When you must use hostPath, restrict the mount to read-only whenever possible.
Prerequisites
Before you begin, make sure that you have:
An EDAS account with access to the EDAS console
A Kubernetes cluster (ACK) registered in EDAS
An available namespace and region for your application
Add local storage to a new application
Log on to the EDAS console. In the left-side navigation pane, choose Application Management > Applications.
In the top navigation bar, select a region. In the upper part of the page, select a namespace. In the upper-left corner, click Create Application.
In the Basic Information step, set the following parameters and click Next.
Parameter Description Cluster Type Select Kubernetes Clusters Application Runtime Environment Select the runtime that matches your application. See Application runtime options In the Configurations step, configure the environment information, basic information, deployment method, and resource parameters. Click Next.
In the Advanced Settings step, expand Local Storage and configure the volume type:
To mount a host path, see Local File of Host parameters.
To create an ephemeral shared volume, see emptyDir parameters.
Click Create Application.
On the Creation Completed page, review the settings in the Basic Information, Configurations, and Advanced Settings sections. Click Create Application to confirm.
On the Application Overview page, click View Details. On the Change List page, monitor the deployment progress. After the change completes, check the Basic Information section on the Application Overview page. A running pod indicates a successful deployment.
Update local storage for an existing application
The application restarts after you save these changes. Perform this operation during off-peak hours.
Log on to the EDAS console. In the left-side navigation pane, choose Application Management > Applications.
In the top navigation bar, select a region. In the upper part of the page, select a namespace. From the Cluster Type drop-down list, select Container Service or Serverless Kubernetes Cluster.
Find the target application and click its name.
On the Overview or Basic information page, choose Deploy > Deploy in the upper-right corner.
On the Select Deployment Mode page, select a deployment mode and click Start Deployment.
Configure the environment and deployment package, then expand Local Storage and set the volume parameters:
To mount a host path, see Local File of Host parameters.
To create an ephemeral shared volume, see emptyDir parameters.
Click OK.
Local storage parameters
Local File of Host parameters
The Local File of Host option maps to a Kubernetes hostPath volume. It mounts a file or directory from the host node into the container.
The type field controls whether Kubernetes validates or creates the path on the host before mounting:
| File type | Value | Behavior |
|---|---|---|
| Default | Empty string | Mounts the path without validation. No checks are performed before mounting |
| (Create) File Directory | DirectoryOrCreate | If the path does not exist, creates an empty directory with permission 0755. The directory inherits the kubelet's group and ownership |
| File Directory | Directory | A directory must already exist at the path. The container fails to start if the directory does not exist |
| (Create) File | FileOrCreate | If the path does not exist, creates an empty file with permission 0644. The file inherits the kubelet's group and ownership |
| File | File | A file must already exist at the path. The container fails to start if the file does not exist |
| Socket | Socket | A UNIX socket must already exist at the path. The container fails to start if the socket does not exist |
| CharDevice | CharDevice | A character device must already exist at the path (Linux nodes only). The container fails to start if the device does not exist |
| BlockDevice | BlockDevice | A block device must already exist at the path (Linux nodes only). The container fails to start if the device does not exist |
FileOrCreate does not create the parent directory. If the parent directory of the target file does not exist, the pod fails to start. To avoid this issue, first mount the parent directory using DirectoryOrCreate, then mount the file.
Additional parameters for Local File of Host:
| Parameter | Description |
|---|---|
| Mount Path | The path inside the container where the host file or directory is mounted |
| Host Path | The path on the host node to mount into the container |
| Mount Mode | Access mode for the volume. Valid values: Read/Write and Read-only. Use Read-only whenever possible to reduce security risks |
| subPathExpr | A field-reference expression used to construct a subdirectory name within the volume. Useful for giving each container or pod instance its own directory |
emptyDir parameters
An emptyDir volume is created when a pod is assigned to a node. All containers in the pod can read from and write to the same emptyDir volume, making it suitable for scratch space, caches, or inter-container data exchange. When the pod is removed from the node for any reason (including crash, scale-down, or redeployment), the data in the emptyDir volume is permanently deleted.
| Parameter | Description |
|---|---|
| Mount Mode | Access mode for the volume. Valid values: Read/Write and Read-only |
| Mount Path | The path inside the container where the emptyDir volume is mounted |
| subPathExpr | A field-reference expression used to construct a subdirectory name within the volume. Useful for giving each container or pod instance its own directory |
Verify the configuration
After the deployment completes, verify that local storage is configured correctly using either method:
Check change records
In the left-side navigation pane of the application details page, click Change Records. If the Change Status column shows Success, the storage configuration is active.
Check pod status
On the Application Overview page, click Running Pods (Click View) next to Running Status. In the Pod section, check the Status column. A green dot indicates the pod is running and the configuration is in effect.
Production considerations
Keep the following in mind when using local storage in production:
Security:
hostPathvolumes bypass container isolation boundaries. Restrict mount paths to the minimum required scope and use Read-only mount mode whenever possible. Avoid mounting sensitive paths such as/,/etc, or/var/run.Pod scheduling:
hostPathdata is tied to a specific node. If a pod is rescheduled to a different node, it cannot access data from the previous host. For data that must persist across node changes, use alocalPersistentVolume or network-attached storage.Disk pressure:
hostPathvolume usage is not tracked by Kubernetes ephemeral storage management. Monitor disk usage on host nodes to prevent disk pressure caused by container writes tohostPathmounts.emptyDir size:
emptyDirvolumes consume node disk space (or memory if backed bytmpfs). A single pod writing large amounts of data toemptyDircan cause disk pressure on the node.Data loss:
emptyDirdata is deleted when the pod is removed. Do not store data that must survive pod restarts inemptyDirvolumes.
Application runtime options
Select the runtime environment based on your application type and packaging format.
| Runtime | Option | Use when |
|---|---|---|
| Java | Custom | Deploying with a custom container image |
| Java | Java | Deploying a Dubbo or Spring Boot application with a JAR package. Set Java Environment after selection |
| Java | Tomcat | Deploying a Dubbo or Spring application with a WAR package. Set Java Environment and Container Version after selection |
| Java | EDAS-Container (HSF) | Deploying a High-speed Service Framework (HSF) application with a WAR or FatJar package. Set Java Environment, Pandora Version, and Ali-Tomcat Version after selection |
| PHP | PHP | Running a PHP application on Apache HTTP Server |
| Multi-language | Node.js, C++, Go, and Other Languages | Deploying with a custom container image |