What Are the Differences Among CCE Storage Classes in Terms of Persistent Storage and Multi-node Mounting?
Container storage provides storage for container workloads. It supports multiple storage classes. A pod can use any amount of storage.
Currently, CCE supports local, EVS, SFS, SFS Turbo, and OBS volumes.
The following table lists the differences among these storage classes.
Storage Class |
Persistent Storage |
Automatic Migration with Containers |
Multi-node Mounting |
---|---|---|---|
Local volumes |
Supported |
Not supported |
Not supported |
EVS volumes |
Supported |
Supported |
Not supported |
OBS volumes |
Supported |
Supported |
Supported. This type of volumes can be shared among multiple nodes or workloads. |
SFS volumes |
Supported |
Supported |
Supported. This type of volumes can be shared among multiple nodes or workloads. |
SFS Turbo volumes |
Supported |
Supported |
Supported. This type of volumes can be shared among multiple nodes or workloads. |
Selecting a Storage Class
You can use the following types of storage volumes when creating a workload. You are advised to store workload data on EVS volumes. If you store workload data on a local volume, the data cannot be restored when a fault occurs on the node.
- Local volumes: Mount the file directory of the host where a container is located to a specified container path (corresponding to hostPath in Kubernetes). Alternatively, you can leave the source path empty (corresponding to emptyDir in Kubernetes). If the source path is left empty, a temporary directory of the host will be mounted to the mount point of the container. A specified source path is used when data needs to be persistently stored on the host, while emptyDir is used when temporary storage is needed. A ConfigMap is a type of resource that stores configuration data required by a workload. Its contents are user-defined. A secret is a type of resource that holds sensitive data, such as authentication and key information. Its contents are user-defined.
- EVS volumes: Mount an EVS volume to a container path. When the container is migrated, the mounted EVS volume is migrated together. This storage class is applicable when data needs to be stored permanently.
- SFS volumes: Create SFS volumes and mount them to a container path. The file system volumes created by the underlying SFS service can also be used. SFS volumes are applicable to persistent storage for frequent read/write in multiple workload scenarios, including media processing, content management, big data analysis, and workload analysis.
- OBS volumes: Create OBS volumes and mount them to a container path. OBS volumes are applicable to scenarios such as cloud workload, data analysis, content analysis, and hotspot objects.
- SFS Turbo volumes: Create SFS Turbo volumes and mount them to a container path. SFS Turbo volumes are fast, on-demand, and scalable, which makes them suitable for DevOps, containerized microservices, and enterprise office applications.
Storage FAQs
- What Are the Differences Among CCE Storage Classes in Terms of Persistent Storage and Multi-node Mounting?
- Can I Add a Node Without a 100 GB Data Disk?
- Can I Restore an EVS Disk Used as a Persistent Volume in a CCE Cluster After the Disk Is Deleted or Expires?
- What Should I Do If the Host Cannot Be Found When Files Need to Be Uploaded to OBS During the Access to the CCE Service from a Public Network?
- How Many Nodes (ECSs) Can an SFS File System Be Mounted to?
- How Can I Achieve Compatibility Between ExtendPathMode and Kubernetes client-go?
- What Should I Do If a Storage Volume Fails to be Created?
- Can CCE PVCs Detect Underlying Storage Faults?
Feedback
Was this page helpful?
Provide feedbackFor any further questions, feel free to contact us through the chatbot.
Chatbotmore