FAQ about OSS volumes

• Why do I fail to mount an OSS volume?

• Why does the directory in an OSS volume that is mounted to a container become unavailable after the cluster that runs the pod is upgraded?

• Why does it require a long time to mount an OSS volume?

Why do I fail to mount an OSS volume?

Symptom:

Your attempt to mount an OSS volume failed.

Cause:

• The AccessKey pair that you used is invalid.

• The endpoint of the OSS bucket to be mounted is inaccessible.

• The operating system of the node is neither CentOS 7 nor Alibaba Cloud Linux 2.

Solution:

• Use a valid AccessKey pair.

• Make sure that the endpoint of the OSS bucket to be mounted is accessible.

• Temporary solution: Download the latest version of the ossfs in the node manually, and delete the pod to tragger Object Storage Service (OSS) volumes to remount.

  Important

  Each time the FlexVolume pod restarts, it reverts ossfs to the original version. This does not affect already mounted services. To fix this issue, we recommend that you upgrade from FlexVolume to Container Storage Interface (CSI) first, then upgrade the operating system of the node. For more information, see Upgrade from FlexVolume to CSI.

Why does the directory in an OSS volume that is mounted to a container become unavailable after the cluster that runs the pod is upgraded?

Symptom:

The directory in an OSS volume that is mounted to a container becomes unavailable after the cluster that runs the pod is upgraded.

Cause:

After the cluster is upgraded, kubelet and the container network are restarted, which cause the OSSFS process to restart. As a result, the mapping between the host and the container directory becomes invalid.

Solution:

Restart the container or recreate the pod to which the OSS volume is mounted. You can configure the health check feature to automate the restart of containers or pods.

For more information about how to use OSS, see OSS volume overview.

Why does it require a long time to mount an OSS volume?

Symptom:

It requires a long time to mount an OSS volume.

Cause:

If the securityContext.fsgroup parameter is set in the application template, kubelet performs the chmod or chown operation after the volume is mounted, which increases the time consumption.

Solution:

• If the securityContext.fsgroup parameter is set in the application template, delete the fsgroup parameter in the securityContext section.

• If you want to configure the user ID (UID) and mode of the files in the mounted directory, you can manually mount the OSS bucket to an Elastic Compute Service (ECS) instance. You can then perform chown and chmod operations through a CLI and provision the OSS volume through the FlexVolume plug-in. For more information about how to provision OSS volumes through FlexVolume, see Mount a statically provisioned OSS volume.

• For clusters of Kubernetes 1.20 or later, you can set the fsGroupChangePolicy parameter to OnRootMismatch. This way, the chmod or chown operation is performed only when the pod that uses the volume is first started. For more information, see Set the security context for a container.