Use a static OSS volume

Background

OSS is a secure, cost-effective, high-capacity, and highly reliable cloud storage service. It is ideal for storing data that is rarely modified after being written, as well as unstructured data such as images, audio, and video files. For more information, see Storage overview.

OSS volume clients

OSS volumes use a Filesystem in Userspace (FUSE) client to mount object storage as a local file system. Compared to traditional local storage and block storage, OSS volumes have some POSIX compatibility limitations. Alibaba Cloud Container Compute Service (ACS) currently supports the following OSS volume clients.

• If you are unsure about the read/write model of your workload, we recommend using ossfs 1.0. It offers better POSIX compatibility and ensures greater operational stability for your services.

• For scenarios where read and write operations can be separated, such as when reads and writes do not occur simultaneously or target different files (for example, saving checkpoints or persistent logging), we recommend using separate volumes. For example, mount a read-only path using an ossfs 2.0 volume and a write path using an ossfs 1.0 volume.

POSIX API support

The following table compares the POSIX API support of ossfs 1.0 and ossfs 2.0.

Performance benchmark

ossfs 2.0 delivers significant performance improvements over ossfs 1.0 in sequential read/write operations and high-concurrency small-file reads.

• Sequential write performance: In single-threaded, large-object sequential write scenarios, ossfs 2.0 achieves nearly 18 times the bandwidth of ossfs 1.0.

• Sequential read performance: In both single-threaded and multi-threaded (4 threads) large-object sequential read scenarios, ossfs 2.0 achieves over 3 times the bandwidth of ossfs 1.0.

• Concurrent small object read performance: In high-concurrency (128 threads) small-object read scenarios, ossfs 2.0 achieves over 20 times the bandwidth of ossfs 1.0.

If the read/write performance, such as latency or throughput, does not meet your expectations, see Best practices for tuning the performance of OSS volumes.

Prerequisites

The managed-csiprovisioner component is installed in the ACS cluster.

Notes

• ACK supports only OSS static volumes, not dynamic volumes.

• Random or append writes to a file create a new file locally and then re-upload it to the OSS server. Due to the nature of object storage, note the following:

  • Rename operations for files and directories are not atomic.

  • Avoid concurrent writes or operations such as compression and decompression directly in the mount directory.

    Important

    For concurrent writes, you must coordinate client behavior. ACK does not guarantee against data or metadata inconsistencies caused by these operations.

Other limitations include:

• Hard links are not supported.

• You cannot mount buckets that use the Archive Storage, Cold Archive Storage, or Deep Cold Archive Storage classes.

• By default, the readdir operation on ossfs 1.0 volumes sends numerous HeadObject requests to retrieve extended information for all objects in a directory, which can degrade overall ossfs performance in directories with many files. If your workload is not sensitive to file attributes such as permissions, you can enable the -o readdir_optimize parameter to improve performance. For more information, see readdir optimization.

Create an OSS bucket and get details

1. Create an OSS bucket.

   1. Log in to the OSS console. In the left navigation pane, click Buckets.

   2. Click Create Bucket.

   3. In the Create Bucket panel, configure the required parameters and click Create.

      The following table describes the key parameters. For more information, see Create buckets.

      Parameter	Description
      Bucket Name	Enter a custom name. The bucket name must be globally unique in OSS and cannot be changed after creation. Follow the formatting requirements displayed in the UI.
      Region	Select Specific Region and choose the same region as your ACS cluster. This allows pods in the cluster to access the bucket over the internal network.

2. (Optional) To mount a subdirectory from an OSS bucket, create it first.

   1. On the Buckets page, click the name of the target bucket.

   2. On the bucket details page, in the left navigation pane, choose Object Management > Objects.

   3. Click Create Directory to create directories in the bucket as needed.

3. Get the endpoint of the OSS bucket.

   1. On the Buckets page, click the name of the target bucket.

   2. On the bucket details page, click the Overview tab. In the Port section, copy the appropriate endpoint.

      • If the OSS bucket and the ACS cluster are in the same region, copy the internal endpoint.

      • If the OSS bucket is not region-specific or is in a different region from the ACS cluster, copy the public endpoint.

4. Get an AccessKey ID and an AccessKey Secret to access OSS. For more information, see Obtain an AccessKey pair.

   Note

   If you need to mount an OSS bucket that belongs to another Alibaba Cloud account, you must get the AccessKey pair from that account.

Mount an OSS volume

Verify OSS shared storage and persistent storage

The Deployment created in the preceding example contains two pods. Both pods mount the same OSS bucket. You can verify shared storage and persistent storage as follows:

• To verify shared storage, create a file in one pod and then check that it is visible in the other pod.

• To verify persistent storage, restart the Deployment and then check if the original data is still accessible from a new pod.

1. Get the pod information.

   kubectl get pod | grep oss-test

   Sample output:

   oss-test-****-***a   1/1     Running   0          40s
   oss-test-****-***b   1/1     Running   0          40s

2. Verify shared storage.

   1. Create a file in one of the pods.

      This example uses the pod named oss-test-****-***a.

      kubectl exec oss-test-****-***a -- touch /data/test.txt

   2. Check for the file in the other pod.

      This example uses the pod named oss-test-****-***b.

      kubectl exec oss-test-****-***b -- ls /data

      This output confirms that the test.txt file is shared.

      test.txt

3. Verify persistent storage.

   1. Restart the Deployment.

      kubectl rollout restart deploy oss-test

   2. Check the pod status and wait for the new pods to enter the Running state.

      kubectl get pod | grep oss-test

      Sample output:

      oss-test-****-***c   1/1     Running   0          67s
      oss-test-****-***d   1/1     Running   0          49s

   3. In one of the new pods, check if the data in the file system still exists.

      This example uses the pod named oss-test-****-***c.

      kubectl exec oss-test-****-***c -- ls /data

      This output confirms that the data in the OSS bucket persists and is accessible from the new pod's mount directory.

      test.txt