Container Compute Service:Mount a statically provisioned OSS volume

Background information

OSS is a secure, cost-effective, high-capacity, and highly reliable cloud storage service provided by Alibaba Cloud. OSS is suitable for storing unstructured data that is not frequently modified, such as images, audio files, and video files. For more information, see Storage overview.

OSS volume clients

OSS volumes can be mounted locally as a file system using a client based on Filesystem in Userspace (FUSE). Compared to traditional local storage and block storage, FUSE-based clients have some limitations in terms of POSIX compatibility. ACS supports the following OSS volume clients.

• If you are unsure about the read and write model of your application, use ossfs 1.0. ossfs 1.0 offers better POSIX compatibility and ensures stable application operations.

• For scenarios where read and write operations can be separated, such as when read and write operations are not performed at the same time or are performed on different files (for example, for breakpoint saving or persistent log saving), you can use different volumes. For example, you can use an ossfs 2.0 volume to mount a read-only path and an ossfs 1.0 volume to mount a write path.

POSIX API support

The following table describes the support for common POSIX APIs that are provided by ossfs 1.0 and ossfs 2.0.

Performance benchmarks

ossfs 2.0 provides significant performance improvements over ossfs 1.0 in sequential reads and writes and in concurrent reads of small files.

• Sequential write performance: In single-threaded sequential write scenarios for large files, ossfs 2.0 increases bandwidth by nearly 18 times compared to ossfs 1.0.

• Sequential read performance

  • In single-threaded sequential read scenarios for large files, ossfs 2.0 increases bandwidth by about 8.5 times compared to ossfs 1.0.

  • In multi-threaded (4 threads) sequential read scenarios for large files, ossfs 2.0 increases bandwidth by more than 5 times compared to ossfs 1.0.

• Concurrent small file read performance: In high-concurrency (128 threads) scenarios for reading small files, ossfs 2.0 increases bandwidth by more than 280 times compared to ossfs 1.0.

If the read and write performance, such as latency and throughput, does not meet your requirements, see Best practices for optimizing the performance of OSS volumes.

Prerequisites

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

Usage notes

• ACS supports only statically provisioned OSS volumes. Dynamically provisioned OSS volumes are not supported.

• Random or append writes involve creating a new file locally and re-uploading it to the OSS server. Because of the storage characteristics of OSS, note the following:

  • The rename operation for files and folders is not atomic.

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

    Important

    In multi-write scenarios, you must coordinate the behavior of each client. ACS does not guarantee data consistency for metadata or data issues caused by write operations.

In addition, note the following limitations:

• Hard links are not supported.

• You cannot mount buckets with a StorageClass of Archive Storage, Cold Archive, or Deep Cold Archive.

• For ossfs 1.0 volumes, the readdir operation sends many headObject requests by default to obtain extended information about all objects in the path. When the destination path contains many files, the overall performance of ossfs may be affected. If file permissions and other properties are not critical in your read and write scenarios, you can enable the -o readdir_optimize parameter to optimize performance. For more information, see New readdir optimization feature.

Create an OSS bucket and obtain the bucket information

1. Create an OSS bucket.

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

   2. Click Create Bucket.

   3. In the panel that appears, configure the parameters for the OSS bucket 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 name must be globally unique within OSS and cannot be changed after the bucket is created. For more information about the format requirements, see the on-screen instructions.
      Region	Select Region-specific and select the region where the ACS cluster resides. This allows pods in the ACS cluster to access the OSS bucket over the internal network.

2. (Optional) To mount a subdirectory of the OSS bucket, you can create the subdirectory.

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

   2. In the navigation pane on the left of the bucket details page, choose Files > Objects.

   3. Click Create Directory to create the required directories in the OSS bucket.

3. Obtain the endpoint of the OSS bucket.

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

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

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

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

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

   Note

   To mount an OSS bucket that belongs to another Alibaba Cloud account, you must obtain the AccessKey pair from that account.

Mount an OSS volume

Verify that the OSS volume can share and persist data

The deployment that you created provisions two pods. The same OSS bucket is mounted to both pods. You can use the following methods to verify that the OSS volume can be used to share and persist data:

• Create a file in one pod and check whether the file can be accessed from the other pod. If the file can be accessed, data sharing is enabled.

• Recreate the deployment. Access the OSS volume from a new pod to check whether the original data still exists in the OSS bucket. If the data still exists, data persistence is enabled.

1. View 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 the shared storage.

   1. Create a file in one of the pods.

      In this example, the pod named oss-test-****-***a is used:

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

   2. View the file from the other pod.

      In this example, the pod named oss-test-****-***b is used:

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

      The following output shows that the new file test.txt is shared.

      test.txt

3. Verify that data persists after the pods are recreated.

   1. Delete and then recreate the deployment.

      kubectl rollout restart deploy oss-test

   2. View the pods and wait for the new pods to be created.

      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. From a new pod, check whether the data in the file system still exists.

      In this example, the pod named oss-test-c*** is used:

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

      The following output shows that the data in the OSS bucket still exists and can be retrieved from the mount directory in the new pod.

      test.txt